Zasady SOLID

Dlaczego to ważne? SOLID to zestaw dobrych praktyk wprowadzony przez Roberta C. Martina (Uncle Bob). Ich stosowanie pozwala uniknąć tzw. “gnijącego kodu” (code rot), czyli sytuacji, w której każda mała zmiana w systemie powoduje lawinę błędów w niepowiązanych miejscach.

1. S – Single Responsibility Principle (Zasada Jednej Odpowiedzialności)

Klasa powinna mieć tylko jeden powód do zmiany.

Oznacza to, że każda klasa powinna odpowiadać za jedną, ściśle określoną funkcjonalność. Jeśli klasa zajmuje się jednocześnie logiką biznesową, zapisem do bazy danych i formatowaniem raportu, to przy zmianie formatu raportu ryzykujemy zepsucie logiki biznesowej.

2. O – Open/Closed Principle (Zasada Otwarte-Zamknięte)

Elementy systemu powinny być otwarte na rozbudowę, ale zamknięte na modyfikacje.

Powinniśmy móc dodawać nowe funkcjonalności bez konieczności edytowania istniejącego, przetestowanego już kodu. Realizuje się to najczęściej poprzez Abstrakcję i interfejsy. Zamiast zmieniać funkcję liczCenę(), dodajemy nową klasę implementującą strategię zniżkową.

3. L – Liskov Substitution Principle (Zasada Podstawienia Liskov)

Obiekty w programie powinny być zastępowalne przez instancje ich typów pochodnych bez wpływu na poprawność programu.

Jeśli klasa Kwadrat dziedziczy po klasie Prostokąt, to każda funkcja oczekująca prostokąta powinna działać poprawnie po otrzymaniu kwadratu. Jeśli tak nie jest (bo np. zmiana szerokości kwadratu wymusza zmianę wysokości), to dziedziczenie zostało użyte błędnie.

4. I – Interface Segregation Principle (Zasada Segregacji Interfejsów)

Użytkownik nie powinien być zmuszany do polegania na metodach, których nie używa.

Lepiej stworzyć wiele mniejszych, specyficznych interfejsów niż jeden gigantyczny “interfejs ogólny”. Jeśli urządzenie wielofunkcyjne implementuje interfejs Maszyna, który ma metody drukuj(), skanuj() i faksuj(), to zwykła drukarka nie powinna być zmuszana do posiadania (pustej) metody faksuj().

5. D – Dependency Inversion Principle (Zasada Odwrócenia Zależności)

Wysokopoziomowe moduły nie powinny zależeć od modułów niskopoziomowych. Oba powinny zależeć od abstrakcji.

Zasada ta mówi, że logika biznesowa nie powinna zależeć od konkretnych narzędzi (np. konkretnej bazy danych). Powinna zależeć od interfejsu bazy danych. Dzięki temu możemy wymienić SQL na MongoDB bez konieczności przepisywania logiki aplikacji.

Korzyści ze stosowania SOLID

  1. Łatwiejsze testowanie: Małe, wyspecjalizowane klasy o wiele łatwiej objąć testami jednostkowymi.
  2. Mniejszy dług techniczny: Kod jest bardziej czytelny i przewidywalny.
  3. Szybszy rozwój: Dodawanie nowych funkcji rzadziej powoduje błędy w regresji.
  4. Lepsza praca zespołowa: Modularność pozwala wielu programistom pracować nad różnymi częściami systemu bez konfliktów.

SOLID w oczach Analityka Systemowego

Mimo że SOLID brzmi jak pojęcie czysto techniczne, ma ogromne znaczenie dla analityka:

  • Projektowanie komponentów: Pomaga w definiowaniu granic modułów na diagramach pakietów.
  • Weryfikacja wymagań: Pozwala zrozumieć, dlaczego programiści proszą o rozbicie jednego “wielkiego” zadania na mniejsze składowe.
  • Analiza wpływu: Jeśli system jest zbudowany zgodnie z SOLID, analityk może łatwiej oszacować koszty zmiany, bo jej wpływ będzie lokalny, a nie globalny.

Podsumowanie

Zasady SOLID to nie są sztywne reguły, których trzeba trzymać się fanatycznie, ale drogowskazy prowadzące do profesjonalnego oprogramowania. Ich zrozumienie pozwala na płynniejszą komunikację między biznesem a deweloperami oraz gwarantuje, że system będzie w stanie ewoluować wraz ze zmieniającymi się potrzebami rynku.

Powiązane pojęcia:

Kliknij w pojęcie, aby przejść do jego definicji w słowniku