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.

Share on Facebook0Share on Google+0Tweet about this on Twitter0Share on LinkedIn0

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ć.

  • Radosław Chudzik

    Bardzo fajny art! Przydałby się jakiś krótki przykład odnoście dependency inversion.
    Fajnie, że masz zamiar napisać coś o pojedynczej odpowiedzialności bo tego nigdy za wiele!

    • Dzięki za miłe słowa. Co do przykładów odnośnie odwracania zależności to już niebawem będzie programistyczne mięso 😀 Co do pojedynczej odpowiedzialności to się zgadam, nigdy nie za wiele.

  • Dobry przykład oby tak dalej.

  • Czym sie roznia zmiany od modyfikacji🤐

    • Kamil Jóźwiak

      Na pierwszy rzut oka niczym 🙂

      Zapewne pytasz o zasadę open/close, a tu sprawa wygląda następująco: masz kod, który musi być przygotowany do zmiany sposobu działania.
      Kod powinien być zamknięty na zmiany, ale otwarty na modyfikacje.
      Weźmy na tepetę zapis danych. Jak napiszesz metodę Save(Foo), która zapisuje do pliku xyz.txt na dysku D to zadziała, ale masz pozamiatane. Przyjdzie Ci zmienić sposób zapisu na zapis do bazy danych to musisz wszystko kompilować itd itp.
      Wystarczy stworzyć sobie interfejs np. ISaveManager, do tego jakiś kontener i możesz zmieniać sposób zapisu nawet, bez konieczności restartu aplikacji.
      Możesz modyfikować, ale nie nie musisz nic zmieniać.

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