Wyobraź sobie, że piszesz mniej lub bardziej rozbudowany program wykorzystując paradygmat obiektowy. Twoja aplikacja powstaje przy użyciu wielu klas i zależności. W którymś momencie pojawia się błąd lub chcesz po prostu rozbudować swoje dzieło o nowe funkcjonalności. Okazuje się, że w obu przypadkach, aby dokonać zmian, musisz poświęcić sporą ilość czasu na zrozumienie własnego kodu oraz na jego modyfikacje w wielu miejscach – zarówno całych klas, jak i powiązań między nimi. Co więcej, wiele zależności wymaga zakodowania od nowa, a to oczywiście także zwiększa czasochłonność Twojej pracy i być może nawet stopień skomplikowania kodu.
W celu zmniejszenia prawdopodobieństwa wystąpienia takich bądź podobnych sytuacji, pewien amerykański programista o nazwisku Robert Cecil Martin (znany również jako Uncle Bob) sformułował 5 zasad dobrych praktyk określanych akronimem SOLID.
Czym jest SOLID?
W skład SOLID wchodzą następujące zasady:
- Single Responsibility Principle (SRP) — Zasada pojedynczej odpowiedzialności – klasa powinna mieć tylko jedną odpowiedzialność.
- Open/Closed Principle (OCP) — Zasada otwarte-zamknięte – klasy powinny być otwarte na rozszerzenia, a zamknięte na modyfikacje
- Liskov Substitution Principle (LSP) — Zasada podstawienia Liskov – typy pochodne muszą całkowicie zastępować typy podstawowe.
- Interface Segregation Principle (ISP) — Zasada segregacji interfejsów – wiele dedykowanych interfejsów jest lepsze niż jeden ogólny
- Dependency Inversion Principle (DIP) — Zasada odwracania zależności – wysokopoziomowe moduły nie powinny zależeć od modułów niskopoziomowych – zależności między nimi powinny wynikać z abstrakcji.
Więcej o „SOLIDnym” programowaniu dowiecie z pięciu artykułów poświęconych każdej zasadzie z osobna, do których linki znajdziecie powyżej 🌐. Miłej lektury 🙂.
0 komentarzy