Kategoria: Principles

"Dochodzenie do mistrzostwa wymaga dwóch elementów: wiedzy i pracy." - Robert C. Martin

odwrócenia zależności

Zasada odwrócenia zależności

W myśl zasady odwrócenia zależności wszystkie zależności powinny w jak największym stopniu zależeć od abstrakcji, a nie od konkretnego typu. A więc klasa wysokiego poziomu nie powinna zależeć od klasy niskiego poziomu, ale obydwie klasy powinny zależeć od abstrakcji. Moduły (klasy) wysokiego poziomu najczęściej są odpowiedzialne za ważne decyzje strategiczne i modele danej aplikacji. Dlatego…
Przeczytaj więcej

Zasada segregacji interfejsów

Zasada segregacji interfejsów

Zasada segregacji interfejsów głosi, że interfejsy powinny być małe i konkretne, tak by klasy nie implementowały metod, których nie potrzebują. Zasada ta ma w szczególności za zadanie wyeliminowanie nieporęcznych, niepotrzebnie rozbudowanych interfejsów. Każdy interfejs zgodnie z tą zasadą powinien zostać podzielony na mniejsze grupy metod. Przedstawiony poniżej program dla automatu z kawą łamie zasadę ISP,…
Przeczytaj więcej

Liskov

Zasada podstawienia Liskov

Zasada podstawienia Liskov mówi nam, że w miejscu klasy bazowej można użyć dowolnej klasy pochodnej, a więc zgodność interfejsu oraz wszystkich metod musi być zachowana. Zasada ta jest zgodna z zasadą otwarte/zamknięte, gdyż klasa pochodna nie ma wpływu na zachowanie klasy nadrzędnej. Oznacza to, że klasy pochodne muszą być substytucyjne w stosunku do klas bazowych.

Zasada otwarte/zamknięte

Zasada otwarte/zamknięte

Według zasady otwarte/zamknięte każda klasa powinna być otwarta na rozbudowę, ale zamknięta na modyfikacje. Klasy powinny być pisane tak, aby na każdym etapie rozwoju aplikacji istniała możliwość ich rozszerzenia. Rozszerzenie takiej klasy powinno być przeprowadzone bez konieczności wprowadzania modyfikacji już w istniejącej części kodu.

Zasada pojedynczej odpowiedzialności single responsibility principle

Zasada pojedynczej odpowiedzialności

Zasada pojedynczej odpowiedzialności głosi, że każda klasa powinna być odpowiedzialna za jedną konkretną rzecz. Oznacza to mniej więcej, że nie powinien istnieć więcej niż jeden powód do modyfikacji danej klasy.