Zasady SOLID

Zasady SOLID są dla programistów, jak dekalog dla chrześcijan. Każdy POWINIEN znać, ale nie każdy rozumie, a jedynie garstka stosuje. Mnemonik SOLID został opublikowany przez Roberta C. Martina już jakiś czas temu, ale o większości zasad już wcześniej ktoś wspominał. Nie pora i miejsce na rozpisywanie się nad historią, (będzie oddzielny artykuł). W inżynierii oprogramowania, zwanej przez pragmatycznych programistów, rzeczywistością, zasady SOLID oznaczają podstawowy zestaw prawd objawionych na temat wytwarzania oprogramowania. Celowo piszę wytwarzania, bo w ten proces osobiście zaliczam etapy, przez niektórych nazywane projektowaniem oprogramowania i kodowaniem. Poniżej rozwinięcie mnemonika Wujka Boba, opatrzonego moim komentarzem.

S – Single responsibility principle

Zasada pojedynczej odpowiedzialności, zgodnie z którą klasa powinna mieć tylko jedną odpowiedzialność. Jak w swoim kodzie masz klasę Raport, w której jest metoda odpowiedzialna za generowanie raportu, a obok niej metoda odpowiedzialna za drukowanie raportu, to cytując klasyka „wiedz, że coś się dzieje”.

O – Open/Close principle

Zasada otwarte-zamknięte. W IT jedyną, rzeczą stałą są zmiany. Jeżeli w projekcie, w którym programujesz zmienią się wymagania, a tu nagle i zupełnie niespodziewanie, trzeba przepisać 79,609 % kodu jaki już powstał, to wiedź, że coś się dzieje. Kod powinien być zamknięty na zmiany, ale otwarty na modyfikacje.

L- Liskov substitution principle

Zasada podstawienia Liskov. Każdy kwadrat jest prostokątem, ale nie każdy prostokąt jest kwadratem i o ile zrozumiałym jest posiadanie przez klasę Prostokąt metod UstawSzerokość i UstawDługość to jeżeli, zgodnie z definicją, klasa Kwadrat powinna dziedziczyć po klasie Prostokąt, to zgodnie z prawidłami matematyki metoda UstawDługość powinna w Kwadracie modyfikować zarówno wysokość jak i szerokość. Taka sytuacja sprawie, że nie mamy możliwość pełnego kontrolowania stanu obiektu klasy Kwadrat i to jest właśnie naruszenie zasady podstawienia Liskov.

I – Interface segregation principle

Zasada segregacji interfejsów. Mamy klasę DrukarkaRaportów, która jest bardzo kulturalną klasą, dobrze wychowaną i z dobrego domu, która wie co to pojedyncza odpowiedzialność, więc obiekt takiej klasy ma metodę DrukujRaport, która to metoda przyjmuje obiekt klasy Raport, ponieważ klasa jest bardzo kulturalną, nie wnika co klasa Raport ma w sobie, po za niezbędnym minimum do wydrukowania raportu. Proste.

D – Dependency inversion principle

Zasada odwracania zależności. Moduły wysokopoziomowe nie powinny zależeć od modułów niskopoziomowych, wszelkie zależności powinny wynikać z abstrakcji. Tak przynajmniej mówi Wikipedia na ten temat. Zadaniem architekta (tego od budownictwa) jest projektowanie domów, taki architekt nie powinien wnikać jakimi narzędziami hydraulik wykona instalację, którą zaprojektował architekt. Każdy ma swój wkład w powstaniu instalacji i każdy ma odpowiednie ku temu narzędzia.

Tak w wielkim, mało programistycznym skrócie wyglądają zasady SOLID. Wydaje się proste i zrozumiałe, ale w programowaniu bywa różnie. Nie zawsze każdy fragment kodu musi spełniać wszystkie zasady SOLID. Są to wytyczne, a nie nakazy. Jest to mapa pokazująca drogę a nie sama droga.

Jest to pierwszy artykuł z serii Zasady SOLID, w kolejnej osłonie pojawi się mięso programistyczne, w którym przedstawię jak wygląda implementacja zawierająca zasadę pojedynczej odpowiedzialności.

Kamil Jóźwiak

Nazywam się Kamil Jóźwiak i jestem programistą w firmie Sii, specjalizuję się w technologi .Net. W codziennej pracy staram się łączyć wzorce, style architektoniczne, ale przedewszystkim zdrowy rozsądek. Miłośnik czystego kodu i automatyzacji wszystkiego co się da zaatomatyzować.

Zobacz też:
Klątwa wiedzy to trudność w wyobrażeniu sobie, jak to jest,…