Ile zasad ma wzorzec projektowy
Categories:
Najwcześniejsze zasady wzorców projektowych miały tylko 5 zasad, czyli SOLID:
Zasada pojedynczej odpowiedzialności (Single Responsibility Principle, SRP): klasa powinna mieć tylko jeden powód do zmiany, czyli klasa powinna mieć tylko jedno obowiązanie.Zasada otwarte/zamknięte (Open/Closed Principle, OCP): podmioty programowe (klasy, moduły, funkcje itp.) powinny być otwarte na rozszerzenia, a zamknięte na modyfikacje, czyli zmiany powinny być realizowane przez rozszerzanie, a nie poprzez modyfikację istniejącego kodu.Zasada podstawienia Liskova (Liskov Substitution Principle, LSP): typy podrzędne muszą być w stanie zastąpić swoje typy bazowe, czyli klasy pochodne muszą być w stanie zastąpić swoje klasy bazowe bez wpływu na poprawność programu.Zasada segregacji interfejsów (Interface Segregation Principle, ISP): nie należy zmuszać klientów do zależności od interfejsów, których nie używają. Należy podzielić duże interfejsy na mniejsze i bardziej konkretne interfejsy, aby klienci musieli znać tylko metody, których potrzebują.Zasada odwrócenia zależności (Dependency Inversion Principle, DIP): moduły wysokiego poziomu nie powinny zależeć od modułów niskiego poziomu, oba powinny zależeć od abstrakcji. Abstrakcje nie powinny zależeć od szczegółów implementacji, a szczegóły implementacji powinny zależeć od abstrakcji.
Później dodano dwie zasady, które są bardziej szczegółowe i bardziej kierujące. Możemy zauważyć z wyjaśnień zasad, że SOLID opisuje co należy zrobić, a dodane później zasady opisują co należy zrobić jako pierwsze/najlepiej.
Zasada ponownego wykorzystania kompozycji/ agregacji (Composition/Aggregation Reuse Principle, CARP): należy preferować kompozycję (kompozycję) i agregację obiektów zamiast dziedziczenia w celu ponownego wykorzystania kodu.Prawo Demeter (Law of Demeter, LoD): obiekt powinien wiedzieć o innych obiektach jak najmniej, czyli obiekt powinien wiedzieć jak najmniej o strukturze wewnętrznej i szczegółach implementacji innych obiektów.
Oprócz powyższych zasad istnieją również inne zasady projektowe, choć nie są one tak powszechnie znane jak te, które zostały wcześniej wspomniane, ale również mają istotne znaczenie dla projektowania i architektury oprogramowania. Później zaproponowane zasady są nieco zbędne, przynajmniej uważam, że nie są sprzeczne z intuicją i nie wymagają głębokiego zastanowienia się.
Zasada minimalnej wiedzy (Principle of Least Knowledge, PoLK): znana również jako rozszerzenie prawa Demeter, twierdzi, że obiekt powinien jak najmniej wiedzieć o innych obiektach. Ta zasada wywodzi się z “zasady minimalnej komunikacji” zaproponowanej w 1987 roku przez Patricię Lago i Koosa Vissera.Zasada stabilnej zależności (Stable Dependencies Principle, SDP): ta zasada twierdzi, że projekt oprogramowania powinien zapewniać, że stabilne komponenty nie zależą od niestabilnych komponentów, czyli stabilniejsze komponenty powinny mniej zależeć od mniej stabilnych komponentów. Myśl ta pochodzi z dogłębnych badań nad relacjami między komponentami w systemach oprogramowania.Zasada stabilnej abstrakcji (Stable Abstraction Principle, SAP): w odpowiedzi na zasadę stabilnej zależności, ta zasada kieruje dopasowaniem abstrakcji do stabilności, czyli stabilne komponenty powinny być abstrakcyjne, a niestabilne komponenty powinny być konkretne. Ta zasada pomaga zapewnić stabilność i elastyczność systemu oprogramowania.