kolejna wizyta w świecie wzorców

Zapewne już trochę kodu mieliście okazję stworzyć odkąd pisałem o dekoratorze. Mam nadzieję, że przez ten czas mieliście możliwość go wypróbować i sprawdzić jak daje radę w świecie prawdziwych problemów. Następnym wzorcem, z którym spróbujemy się zmierzyć będzie wizytator.Muszę uczciwie się przyznać, że moje pierwsze z nim spotkanie, gdy wertowałem strony Wzorców Projektowych to nie była miłość od pierwszego wejrzenia i trochę czasu musiało minąć zanim w pełni doceniłem korzyści płynące z jego wykorzystania. Ale jak tak w ogóle ten wizytator wygląda? Gdzie i po co się go stosuje?Wierzę, że na te pytania uda mi się odpowiedzieć w poniższych akapitach.Czytaj więcej »

Zapewne już nie raz mieliście okazję przeczytać stwierdzenie, że bardzo istotne jest to, aby w kodzie do nazywania klas domenowych wykorzystywać, te (nazwy) których używa nasz klient. Wielu z Was uznaje to za oczywistość, wielu dodaje jakieś "ale", są tacy, którzy twierdzą, że przecież klient i tak nie wie czego chce, to po ci się przejmować. Oczywiście są też tacy, którzy sami się takimi "pierdołami" nie mają czasu przejmować, bo przecież "kod jest do napisania".Nie powiem, że się nie da i Wasz projekt bez takiego odwzorowania nie ma szans na powodzenie, bo to nie jest prawda. Przynajmniej nie w każdym przypadku. Są jednak projekty odpowiednio duże bądź skomplikowane, gdzie ten brak spójności potrafi zauważalnie wpłynąć na tempo produkcji kodu oraz na jego jakość. Niestety, jeżeli się "nie dogadamy", to nawet mimo naszych najszczerszych chęci i przy wykorzystaniu najlepszych technik i praktyk nie unikniemy błędów.Czytaj więcej »

One of my favorite PHP interview questions, is: what is Type Hinting and why it’s important? Putting definition in one sentence, Type Hinting is a way to define type of parameter in function signature and it’s a sine qua non to leverage polymorphism. Because of dynamic typing in PHP, parameters don’t need to have type used. Also, by type here, I mean complex types (class, abstract class, interface, array, closure), not primitives like integer or double. So given the fact, that Type Hinting is optional and we don’t need to specify types of parameters passed to the method – why bother? Answer is easy: well prepared method signatures defines your model and are part of the “contract” that your code reveals to its consumers. It also prevents many silly errors and keeps codebase clean and coherent.

Now, if we all agree that Type Hinting is the way to go, what should we put in method signatures? We have few options: concrete class, base class or an interface. It all depends on situation. The most flexible way is the interface, because it’s small definition of object behavior and one class can implement multiple interfaces. Moreover, interfaces can be very easily mocked (by both mock tools, like Mockery or by mocks written by hand). All those adds up into great flexibility

Other option is to set class as type hint. You’re limited to this class instances and their descendants. Having multi-tier hierarchy graph, it’s often good idea to use a class in hierarchy near the root or even abstract class, which gives us possibility to apply method to whole graph of inheritance.

The least flexible way is to set a concrete class (near to final or not ever extended in current sytem). In such case you limit method only to serve for such objects, which is understandable, when method does a specific job.

Three options were presented above (interface, base class and concrete class). There’s one more, very important thing, that need to be kept in mind. Although PHP allows you to call methods outside the type that is defined for the method, you should never do that! It can lead to some bizarre errors and brakes Liskov Substitution Principle. Simply said: if you use a type in method’s signature, then it should rely only on this type, not it’s descendants (even we know about their existence), so you can substitute give type with new subclass without altering method body.

Have a look at possible violation of Liskov Substitution Principle:

class UserRepository extends \Doctrine\ORM\EntityRepository
{
    public function findActiveUsers()
    {
        // do some query to retrieve the result
        return $activeUserCollection;
    }
}

// .. 

public function notifyActiveUsers(EntityRepository $repo)
{
    if ($repo instanceof UserRepository) {
         $usersCollection = $repo->findActiveUsers();
    } elseif ($repo instanceof ManagersRepository) {
         // .. do someting else
     }
    // do something with $usersCollection
}

As we can see, type hinted method notifyActiveUsers internally relies on specific extension of EntityRepository. This breaks LSP and leads to unreadable model. Even worse situation can be following:

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

a zaczęło się to tak...

Jak każdy (a przynajmniej mam taką nadzieję) zespół ludzi pracujący nad tym samym kodem, i w naszym projekcie istnieje dokument ze standardami kodowania. Co jakiś czas wprowadzamy drobne modyfikacje, bo refaktoryzować można (i powinno się) nie tylko kod :) Dzisiaj ten właśnie dokument przeglądał jeden z moich kolegów i natknął się na jedną z moich notatek/uwag w tym dokumencie, którą odrobinę przeredagowaną (niestety użyłem skrótów myślowych pisząc ją :) zamieszczam poniżej:Jeżeli posiadasz klasę abstrakcyjną z metodą publiczną, która jest rozszerzana przez kilka klas nie implementujących tego samego interfejsu, to wiedz, że coś się dzieje. Dobra, samo stwierdzenie może nie być zbyt oczywiste, ale wierzę, że po krótkich wyjaśnieniach dojdziecie nie tylko do wniosku, że ma to sens, ale co więcej, że sami już tą zasadę w kodzie stosujecie.Jakby na to nie patrzeć, jest całkiem naturalna :)Czytaj więcej »

kolejna seria za nami

Następna seria wpisów skończona. Mam nadzieję, że udało mi się przedstawić omawiane zasady w jasny i zrozumiały sposób. Dzisiaj jedynie krótki wpis, w którym chciałem zebrać linki do opublikowanych postów. Zdaję sobie sprawę, że spis treści zazwyczaj jest na początku, ale mam nadzieję, że mi wybaczycie tą ekstrawagancję :) O zasadach SOLID jeszcze z pewnością nie raz napiszę, a jeżeli w między czasie będziecie mieli jakieś pytania lub wątpliwości to czekam na komentarze, może uda mi się coś więcej rozjaśnić, a może sam się czegoś nowego nauczę :) A w międzyczasie zapraszam do czytania wpisów związanych z kolejną serią - tym razem temat długo przeze mnie pomijany, czyli wzorce projektowe.Mam nadzieję, że po ponad trzech latach jestem już wystarczająco przygotowany :)Czytaj więcej »

poodwracane?

Zacznijmy od definicji: Moduły wysokiego poziomu nie powinny zależeć od modułów niskiego poziomu. Jedne i drugie powinny być zależne od pewnych abstrakcji. Niby proste, ale żeby usunąć wszelkie niejasności to pozwolę sobie na rozwinięcie.Czytaj więcej »

segregacja interfejsów czyli co?

Czyli: Klasa udostępnia tylko te interfejsy, które są niezbędne do zrealizowania konkretnej operacji. [link] albo: Klasy nie powinny być zmuszane do zależności od metod, których nie używają. [link] no chyba, że tak: Klasa powinna udostępniać drobnoziarniste interfejsy dostosowane do potrzeb jej klienta. Czyli, że klienci nie powinni mieć dostępu do metod których nie używają. [link] I są to tylko niektóre z definicji, które udało mi się znaleźć w internecie po bardzo krótkich poszukiwaniach. I oczywiście pomimo tego, że brzmią odrobine inaczej, to sprowdzają się one do tego samego.Czytaj więcej »