Dzisiaj powiem Ci, czym jest SOLID w programowaniu, oraz skąd się wzięła taka nazwa.

Na wstępie..

Każdy programista na samym początku, który się dopiero uczy, nie bardzo zwraca uwagę na jakość kodu. Wynika to z tego, że jest nowy w tym zagadnieniu i jeszcze nie za bardzo wie co i jak. Poza tym, że jest nowy, to bardzo jest dla niego ważne, żeby po prostu się uczyć i zdobywać nową wiedzę i stale ją pogłębiać.

Przychodzi moment, w którym po jakimś czasie programista wraca do swojego wcześniejszego kodu, i nie bardzo rozumie, o co w nim chodzi. Z odpowiedzią przychodzi SOLID.

Czym jest SOLID?

SOLID to pięć podstawowych założeń programowania obiektowego:

  • Zasada pojedynczej odpowiedzialności (ang. Single-Responsibility Principle – SRP),
  • Zasada otwarte – zamknięte (ang. Open/Closed Principle – OCP),
  • Zasada podstawiania Liskov (ang. Liskov Substitution Principle – LSP),
  • Zasada segregacji interfejsów (ang. Interface Segregation Principle – ISP),
  • Zasada odwracania zależności (ang. Dependency Inversion Principle – DIP).

W łatwy sposób można zobaczyć, że pierwsze litery ze słówek angielskich tworzą właśnie nazwę SOLID.

Zasada pojedynczej odpowiedzialności

Zasada ta mówi, że Klasa powinna mieć tylko jedną odpowiedzialność, czyli nigdy nie powinien istnieć więcej, niż jeden powód do modyfikacji klasy.

Zasada otwarte-zamknięte

Zasada ta mów, że klasy powinny być otwarte na rozszerzenia i zamknięte na modyfikacje.

Otwarte na rozszerzenia, czyli musi być prosty sposób, na rozbudowę zachowań modułu.

Zamknięte na modyfikację, czyli rozbudowa modułu nie może być rozbudowana w taki sposób, że spowoduje zmianę istniejącego już kodu źródłowego.

Zasada podstawiania Liskov

Zasada ta mówi, że funkcje, które używają wskaźników lub referencji do klas bazowych, muszą być w stanie używać również obiektów klas dziedziczących po klasach bazowych, bez dokładnej znajomości tych obiektów.

Zasada segregacji interfejsów

Zasada ta mówi, że lepiej mieć kilka dedykowanych interfejsów, niż jeden ogólny.

Jeżeli posiadasz jeden, ale rozbudowany interfejs, lepiej podzielić go na kilka mniejszych. Dzięki temu w łatwy sposób odnajdziesz potrzebny Ci interfejs oraz zachowasz porządek.

Zasada odwrócenia zależności

Zasada ta mówi, że moduły wysokopoziomowe nie powinny zależeć od modułów niskopoziomowych — zależność między nimi powinny wynikać z abstrakcji  (pisany kod nie powinien być uzależniony od konkretnej klasy).