Principii SOLID în practică

Publicat la https://blogs.devforum.ro/princpii-solid-in-practica/

[…]
Ori clasa noastră are cel puțin două motive să se schimbe:

  1. Dacă vrem să schimbăm modul în care sunt procesatele datele
  2. Dacă vrem să schimbăm markup-ul tooltip-urilor;

Apoi, OCP zice că un obiect ar trebui să fie deschis pentru extensie, închis pentru modificare. Ori noi, dacă vrem să adăugăm un stil nou, trebuie să edităm clasa.

Și, în cele din urmă, observi că style2 afișează markup, pe când celelalte metode returnează markup-ul? Nu sunt foarte sigur, dar cred că asta încalcă și LSP un pic. […]

7 Likes
  public function getAttribute($attribute) {
    $this->processData();
    return $this->data[$attribute] ?? '';
  }

$this->processData(); nu are ce sa caute acolo, principala responsabilitate a obiectului este sa returneze ceva nu sa proceseze.

Trebuie sa te gandesti ca daca iti spun sa-mi dai o carte din biblioteca nu te pui sa aranjezi toate cartile pe raft si sa le sortezi samd.

In final o sa ai $this->tooltip->processData()->getAttribute('title') in felul acesta poti sa stergi si din processData()

    if($this->dataIsProcessed) {
      return;
    }
    $this->dataIsProcessed = true;

rezultand intr-un obiect mai compact.

In rest e un start foarte bun @iamntz .

8 Likes

Eu sunt de-a dreptul compulsiv în privinţa asta, nu accept sub nicio formă ca funcţiile mele “get()” să facă modificări în datele obiectului. Când programez în C++, atributul const e obligatoriu la metodele de tip “get”.

BTW, exemplul cu cartea nu e foarte potrivit, ăla nu e un “get()”, e mai degrabă un “take()”, care presupune în mod automat şi o procesare (eliminarea itemului din colecţie şi reconectarea nodurilor next şi prev a obiectelor rămase, dacă vorbim de un double-linked list).

2 Likes

Ironia este următoarea: am vrut să păstrez ceva logică în clasa Tooltip pentru a arăta că separ responsabilitățile (markup vs date), dar nu am observat că păstrând acea apelare continui să încalc SRP :smiley:

2 Likes