Dobre praktyki programowania w CakePHP #3

Tym razem krótka notka…

Zauważyłem, że czasem gdy stosujemy wzorzec MVC, zapominamy* że istnieje coś takiego jak projektowanie i programowanie zorientowane obiektowo.
(*)zakładając, że wcześniej wiedzieliśmy, że coś takiego istnieje – to nie jest takie oczywiste.

Chodzi mi o to, że jak piszesz class, private i extends to jeszcze za mało, żeby powiedzieć iż Twój kod jest obiektowy. Na razie możesz powiedzieć, że masz klasy i metody. Ale dalej możesz mieć bajzel jak bez nich.

Dlatego powstają takie niespodzianki jak metoda getAllComments($postId) w kontrolerze Posts, bo akurat wyświetlając dany post potrzebujesz wyświetlić komentarze. Chwała i tak się należy, bo ktoś umieścił ten fragment w osobnej metodzie. Jednak to jeszcze za mało, żeby nie musieć się kodu wstydzić.

Jeśli przypomnisz sobie podstawy programowania obiektowego ze studiów, czy książki o C++ może taki przykład wyda Ci się znajomy:
– Auto jest obiektem: posiada atrybuty szybkość_maksymalna, ilość_pasażerów oraz metody jedź(), ruszaj(), zatrzymaj_się(), włącz_klimę() ;)
To jest przykład w którym wyjaśnia się czym są obiekty, jak ich używać. Czasem brakuje jednak informacji – prostej odpowiedzi na pytanie:
“Dlaczego klasa Auto nie posiada metody wypij_kawę_w_samochodzie()?”. To już zagadnienie z OODesign.

W przypadku samochodu jest to oczywiste, ale łatwo zapomnieć o tym, kiedy nasze klasy są mniej “dotykalne” i sami je projektujemy, a nie “mapujemy” ze świata rzeczywistego. Dlatego skoro wiemy, że metoda wypij_kawę_w_samochodzie() powinna należeć do klasy Człowiek – to dlaczego każemy klasie Posts znajdować komentarze?

Dochodzę już do sedna: przy projektowaniu aplikacji w CakePHP (i w każdym innym frameworku opartym na MVC lub nie) nie możesz olewać zasad projektowania obiektowego. Nie możesz ignorować problemu przynależenia metod do odpowiednich klas. Dlaczego?

Przykład:
Gdy w kilka osób rozwijacie aplikację i nie mieliście 10tysięcy na wynajęcie architekta, który zaprojektowałby wszystkie klasy i ich metody, to prawdopodobnie rozwijacie architekturę stopniowo. W przypływie twórczości jeden z kolegów umieścił metodę getAllComments() w kontrolerze Posts. Następnie Ty na stronie główniej musisz umieścić ostatnie komentarz. Rzucasz okiem na klasę Comments i widzisz, że brakuje tam metody getAll() (Comments w domyśle) więc ją implementujesz.
W wyniku łamana jest reguła DRY, a co za tym idzie powstaje redundancja w kodzie. Zmniejsza się prostota projektu i rośnie dług techniczny.

Może się wydawać, że to błahy przykład i to jest dobre wrażenie. Jednak jeśli nie myślisz o tym problemie takich kwiatków w projekcie prędzej czy później będziesz miał całą łączkę. Po jakimś czasie łączka zarasta tak bardzo, że nie sposób tam wejść z maczetą, więc zarzucasz projekt, bo nie nadaje się on już do konserwacji.

Zatem zasada numer 3:
Poznaj zasady projektowania obiektowego, i nie wypinaj się na nie podczas programowania

Share Button

One thought on “Dobre praktyki programowania w CakePHP #3

  1. Pingback: Dobre praktyki programowania w CakePHP #4 « webbricks

Leave a Reply

Your email address will not be published. Required fields are marked *