Kod żeby był bezawaryjny i łątwy do rozwijania to powinien być solidnie napisany. Aby taki był to trzeba zrozumieć i stosować zasady SOLID. Zapraszam do krótkiej analizy podstawowych założeń programowania obiektowego.
SOLID
S -Single responsibility principle - Zasada jednej odpowiedzialności. Klasa powinna mieć tylko jedną odpowiedzialność (nigdy nie powinien istnieć więcej niż jeden powód do modyfikacji klasy). Czyli powinna umieć wykonać pojedyńcze działanie, stosunkowo małej obszerności. Jeżeli klasa ma wykonać kilka akcji to powinna zlecić niektóre z nich innym klasom. Klasa posiadająca pojedyńczą odpowiedzillność zazwyczaj jest bardzo prosta i mała. Łatko ją jednostkowo przetestować. Przykładem odpowiedzialności klasy może być filtrowanie danych, modyfikowanie danych, zmiana niewielu powiązanych aktrybutów. Jeżeli jakaś klasa będzie wykonywać więcej niż jedną z tych odpowiedzialności stanie się skomplikowana i może sprawiać w przyszłości problemy z rozwijaniem tej funkcjonalności.
O -Open/closed principle - Zasada otwarte-zamknięte. Klasy (encje) powinny być otwarte na rozszerzenia i zamknięte na modyfikacje. Ta zasada jest powiązana z powższą. Jeżeli zmienią się wymaganie co do działania danej funkcjonalności to łatwiej jest rozszeżyć funkcjonalność klasy np. przez oddanie zależności spełniającej wymagany interface, niż zmienianie klasy bazowej. Jeżeli klasa bazowa będzie realizować jedną odpowiedzialność i oddelegowywać inne odpowiedzialności do innych obiektów. To wystarczy podmienić pojedyńczy obiekt, który powinien być wstrzykiwany do obiektu bazowaego. Wtedy obiekt bazowy jest zamkniety na modyfikację bo nie trzeba go modyfikować, a otwarty na rozszerzanie bo rozszeża się funkcjonalność klasy przez wstrzykiwanie bardziej zaawansowanych zależności.
I -Interface segregation principle - Zasada segregacji interfejsów. Wiele dedykowanych interfejsów jest lepsze niż jeden ogólny. Użycie tej zasady pozwoli na zachowanie zasady Open/closed. Jeżeli wszystkie zależności obiektu będą miały własny interfejs to w bardzo łatwy sposób będzie można je podmienić. Wtedy klasa bazowa ma pewność, że w klasie otrzymanej jako zależność istnieją potrzebne metody.
D -Dependency inversion principle - Zasada odwrócenia zależności. Wysokopoziomowe moduły nie powinny zależeć od modułów niskopoziomowych - zależności między nimi powinny wynikać z abstrakcji. Przykładem użycia tej zasady jest PDO. Nie ważne jakiej bazy danych używasz, masz jednakowy zestaw metod, które możesz używać. W tym wypadku twój kod jest modułem wysokopoziomowym, a baza danych niskopoziomowym. Jeżeli twój kod będzie dostawał np. w konstruktorze klasę o wybranym interfejsie to przestaje zależeć od tego czy klasa wstrzykiwana używa bazy danych MySQL czy Postgresql.
Zachowanie wszystkich zasad jest trudne ale pozwala na zachowanie czystego kodu. Taki kod jest łatwiejszy do utrzymania i testowania. Niestety trudniejsza jest konfiguracja takich obiektów, do których należy wstrzyknąć wiele zależności. Ale każda zależność jest jak klocek. I gdy będzie potrzebna zmiana to wymienimy tylko jeden klocek i wszystko będzie poprawnie działać.
Polecam wielokrotne przemyślenie poniższych zasad. Polecam także PHP Challenge vol.7 w którym zaczynamy powoli omawiać zasady z przykładami.
Tagi: Nauka programowania, SOLID,
