Jak zapamiętać zasady SOLID

Zasady Solid pojawiają się na studiach, w artykułach oraz na co drugiej rozmowie kwalifikacyjnej a ja miałem nie pisać o takich rzeczach.

Niestety wszystkie te definicje brzmią archaicznie i są okraszone jakimiś niezrozumiałymi przykładami.

To skutkuje tym, że prawdopodobnie większość programistów nie jest w stanie wymienić zasad SOLID z miejsca, nie mówiąc już o dokładniejszym opisie i zastosowaniu.

W tym artykule podnoszę rękawice i spróbuję przedstawić to w formie możliwej do zapamiętania.

Zasada Jednej Odpowiedzialności

ang: Single Responsibility Principle

Każdy moduł powinien mieć tylko jeden powód do zmian

Jak zapamiętać 🤔

Moduł, klasa, funkcja powinna być powiązana tylko z jednym wymaganiem biznesowym.

Poprawnie

• Moduł wystawiania faktur, zmienia się tylko w przypadku gdy zmienią się wymagania w dziale finansowym
• Klasa VideoPlayer zmienia się tylko w przypadku zmiany wymagań dotyczących odgrywania wideo
• Funkcja saveInvoice zmienia się tylko w przypadku zmiany wymagań odnośnie zapisu faktury

Niepoprawnie

• Moduł wystawiania faktur, zmienia się w przypadku zmian wymagań w dziale finansowym ale także w przypadku zmian wymagań w dziale HR
• Klasa VideoPlayer zmienia się w przypadku zmiany wymagań odgrywania wideo lub zmiany wymagań dotyczących tłumaczenia napisów zawartych w odgrywanym wideo
• Funkcja saveInvoice zmienia się w przypadku zmiany wymagań dotyczących zapisu faktury lub zmiany sposobu liczenia wartości na fakturze

Reguła otwarte-zamknięte

ang: Open-Closed Principle

Element oprogramowania powinien być otwarty na rozbudowę, ale zamknięty na modyfikacje

Jak zapamiętać

Dodawania całkowicie nowej funkcjonalności powinno wymagać minimalnych lub zerowych zmian w istniejącym kodzie.

Poprawnie

• Dodanie nowego odtwarzacza wideo skutkuje napisaniem kodu obsługującego ten player. Nie ma potrzeby edycji kodu odpowiedzialnego za obsługę wideo od strony aplikacji.
• Dodanie nowego mikroserwisu, wymaga napisania kodu mikroserwisu. Nie ma potrzeby zmian w infrastrukturze i warstwie komunikacji pomiędzy serwisami.

Niepoprawnie

• Dodanie nowego odtwarzacza wideo wiąże się z modyfikacją pozostałych odtwarzaczy,
• Dodanie nowego mikroserwisu skutkuje zmianami w warstwie komunikacji pomiędzy mikroserwisami.

Zasada podstawień Liskov

ang: Liskov Subtitution Principle

Oprogramowanie powinno dobrze działać, gdy w miejsce klasy bazowej podstawimy jej którąkolwiek klasę potomną

Zasada ta może się tyczyć klas, REST API i wszystkiego co ma jakiś ustalony interfejs.

Jak zapamiętać

Włożenie typu pochodnego w miejsce typu bazowego nie powinno psuć aplikacji.

Poprawnie

• Klasa spełniająca interfejs, implementuje prawidłowo wszystkie metody interfejsu.
• Serwis łączący się z REST API implementuje endpointy zgodnie z dokumentacją API

Niepoprawnie

• Klasa używana poprzez interfejs nie posiada wszystkich metod zdefiniowanych w interfejsie
• Integracja z REST API wymusza zmiany w logice API

Zasada Rozdzielania Interfejsów

ang: Interface Segregation Principle

Wiele dedykowanych interfejsów jest lepsze niż jeden ogólny

Jak zapamietać

Interfejs jest za duży w przypadku gdy jakiś element nie musi używać wszystkich składowych interfejsu.

Poprawnie

• Klasa YouTubePlayer korzysta z wszystkich metod interfejsu IPlayer

Niepoprawnie

• Klasa YouTubePlayer wykorzystuje metody play i pause z interfejsu IPlayer. Metoda playRandom nie jest wykorzystywana.

Zasada odwrócenia zależności

ang: Dependency Inversion Principle

Wysokopoziomowe moduły nie powinny zależeć od modułów niskopoziomowych – zależności między nimi powinny wynikać z abstrakcji.

Jak zapamietać

Wymiana bazy danych nie powinna skutkować zmianami w logice biznesowej.

Poprawnie

• Zmiana bazy danych z systemu Postgres na MySQL wymaga tylko zmian po stronie adaptera łączącego się z bazą.
• Zamiana YouTubePlayer na VimeoPlayer nie wymaga zmian w kodzie odpowiedzialnym za używanie wideo
• Podmiana mapy z OpenStreet na Google Maps wymaga tylko implementacji klasy obsługującej API mapy.

Nieporawnie

• Zmiana bazy danych z systemu Postgres na MySQL wymaga zmian po stronie klas zapisujących dane o użytkownikach.
• Zamiana YouTubePlayer na VimeoPlayer wymaga zmian w kodzie aplikacji.
• Podmiana mapy z OpenStreet na Google Maps wymaga zmian formacie pola adresu użytkownika.

Podsumowanie

Zasady SOLID nie są tak straszne jak mogłoby się wydawać. Wystarczy, że zapamiętasz poniższe zdania:

• Moduł, klasa, funkcja powinna być powiązana tylko z jednym wymaganiem biznesowym.
• Dodawania całkowicie nowej funkcjonalności powinno wymagać minimalnych lub zerowych zmian w istniejącym kodzie.
• Włożenie typu pochodnego w miejsce typu bazowego nie powinno psuć aplikacji.
• Interfejs jest za duży w przypadku gdy jakiś element nie musi używać wszystkich składowych interfejsu.
• Wymiana bazy danych nie powinna skutkować zmianami w logice biznesowej.

Jeśli znasz bardziej przystępne wytłumaczenie, to odpisz na maila, będę bardzo wdzięczny 😎