Podstawowe 5 zasad związanych z programowaniem obiektowym.
Zasady zostały zaproponowane na początku lat 2000 przez Roberta C. Martina.
SOLID to nazwa utworzona z pierwszych liter angielskich nazw 5 zasad:
S – single responsibility (zasada pojedynczej
odpowiedzialności)
O – open-close (zasada otwarte – zamknięte)
L – Liskov substitution (zasada podstawiania)
I – interface segregation (zasada segregacji interfejsów)
D – dependency inversion (zasada odwrócenia zależności)
Poniżej po krótce opisano ww. zasady.
Single responsibility
Nigdy nie powinno być więcej niż jednego
powodu do modyfikacji klasy. Klasa powinna być koherentna i posiadać
pojedynczą odpowiedzialność. Klasy powinny być specjalizowane. Klasy posiadające takie cechy są bardziej stabilne, tj. rzadziej zmieniane, przez co są prostsze w utrzymaniu.
Open-close
Elementy systemu takie
jak klasy, funkcje powinny być otwarte na rozszerzanie ale bez modyfikacji ich
kodu źródłowego.
Liskov subsitution
principle
Jeżeli S jest podtypem T to obiekt T może
być zastąpiony innym obiektem dziedziczącym po S bez zmiany pożądanych
funkcjonalności programu.
Zgodnie z tą zasadą nie powinno się zatem tworzyć metod, które realizują specyficzne zachowanie w zależności od typu obiektu, jak np.
public void method(S o) {
if (o instacneof T ) {
…
}
Ponieważ instanceof powoduje, że jeżeli dodamy inny obiekt
dziedziczący po S to najprawdopodobniej trzeba będzie zmienić metodę method.
Interface segregation principle
Klient nie powinien być zależny od metod interfejsu, których
nie używa. Interfejsy zawierające dużą liczbę metod powinny być podzielone na
mniejsze. Tak aby dany klient korzystał z interfejsu (ze wszystkich metod).
System powinien być decoupled, łatwiejszy w refactorowaniu.
Dependency inversion
W tradycyjnym podejściu klasy (logika) wyższego poziomu
bezpośrednio korzysta z logiki (klas) niższego poziomu. Ogranicza się w ten
sposób wykorzystanie logiki (klas) wyższego poziomu, gdyż są ściśle związane z
implementacją (logiką) niższego poziomu.
Zgodnie z zasadą odwrócenia zależności to logika wyższego
poziomu nie powinna zależeć od logiki niższego poziomu. W tym celu wprowadza
się elementy abstrakcji (klasy abstrakcyjne/interfejsy) w taki sposób, że klasy
wyższego poziomu korzystają z abstrakcji, a klasy niższego poziomu implementują
abstrakcję.
Rys 1. Podejście
tradycyjne
Rys 2. Podejście zgodne z zasadą odwróconej zależności
