Zasady dobrego programisty

Don’t Repeat Yourself (DRY) – nie powtarzaj się

Jest to jedna z najważniejszych zasad i powinniśmy traktować ją bardzo poważnie. Objawia się ona nie tylko powielaniem tego samego kodu i używanie metody Copy&Paste.

Single-Responsibility Principle (SRP) – zasada pojedynczej odpowiedzialności

Żadna klasa nie może być modyfikowana z więcej niż jednego powodu.

Jeśli jesteśmy w stanie wyobrazi sobie więcej niż jeden bodziec skłaniający programistę do zmiany klasy, mamy do czynienia z klasą rozciągającą się na więcej niż jeden obszar odpowiedzialności.*

Open/Close Principle (OCP) – zasada otwarte-zamknięte

Składniki oprogramowania (klasy, moduły, funkcje itp.) powinny być otwarte na rozbudowę, ale zamknięte dla modyfikacji.

Na początku może wydawać się to sprzeczne bo jak mamy wprowadzać zmiany skoro nie możemy modyfikować kodu. Odpowiedzią jest abstrakcja. W świecie obiektowym abstrakcje mają postać abstrakcyjnych klas bazowych, a grupa niezwiązanych, możliwych zastosowań jest reprezentowana przez klasy pochodne.
Moduł, który wykorzystuje abstrakcje, może być zamknięty dla modyfikacji, ponieważ jego działanie jest uzależnione właśnie od tej abstrakcji. Dzięki temu mamy możliwość rozszerzania tego modułu bez potrzeby modyfikacji jego kodu.

Liskov Substitution Principle (LSP) – zasada podstawień Liskov

Musi istnieć możliwość zastępowania typów bazowych ich podtypami.

Znaczenie tej zasady staje się oczywiste, kiedy rozważymy konsekwencje jej naruszenia. Przypuśćmy, że dysponujemy funkcją f, która otrzymuje za pośrednictwem swojego parametru referencję do pewnej klasy bazowej B. Załóżmy także, że przekazanie na wejściu funkcji referencji do klasy D (potomnej względem klasy B) powoduje błędne działanie tej funkcji. W takim przypadku klasa D narusza zasadę podstawienia Liskov (LSP). Oznacza to, że klasa D jest wrażliwa w kontekście funkcji f.
Prostym przykładem naruszenia tej zasady jest weryfikacja typów za pomocą instrukcji if-else

Dependecy-Inversion Principle (DIP) – zasada odwracania zależności

Moduły wysokopoziomowe nie powinny zależeć od modułów niskopoziomowych. Obie grupy modułów powinny zależeć od abstrakcji.

Abstrakcje nie powinny zależeć od szczegółowych rozwiązań. To szczegółowe rozwiązania powinny zależeć od abstrakcji.

Interface Segregation Principle (ISP) – zasada segregacji interfejsów

Ma na celu wyeliminowanie nieporęcznych “grubych” interfejsów. Do tej grupy zaliczamy nadmiernie rozbudowane i niespójne interfejsy klas. Innymi słowy, interfejsy takich klas należy dzielić na mniejsze grupy metod. Każda taka grupa odpowiada za obsługę innego zbioru klientów. Oznacza to, że część klientów będzie korzystała z jednej grypy metod, podczas gdy pozostałe aplikacje klienckie będą korzystały z pozostałych grup metod.

Zasada skautów: Pozostaw obóz czyściejszym, niż go zastałeś.

(Staraj się pozostawić ten świat nieco lepszym niż go zastałeś)

*Stosowanie reguł jest błędem, jeśli nie znajdujemy uzasadnienia w sytuacji faktycznej. O osi zmian możemy mówić wtedy i tylko wtedy, gdy odpowiednie zmiany mają miejsce.

Bibliografia:

  • Agile Programowanie zminne, Robert C. Martin, Micah Martin
  • Czysty kod, Robert C. Martin