Encapsulate what may change, czyli Ukrywaj zmieniające się rzeczy
Zasada mówi, aby ukrywać zmieniające się rzeczy pod stabilnym interfejsem.
Przykłady:
Bilety: Ukrycie warunku np. czy bilet jest ważny w oddzielnej metodzie.
Zwierzęta: Zwierzęta (Pies, Kot) dają głos. Tworzymy klasę, która sprawia, że wszystkie zwierzęta (ZwierzecyKoncert) dają głos. Ma ona metodę, w której sprawdza, jakiego typu jest dane zwierze i wtedy daje odpowiedni głos.
Możemy implementację dawania głosu przenieść do klas Pies i Kot oraz stworzyć interfejs IZwierzęDajęceGłos. Nasze zwierzęta implementują ten interfejs, a klasa odpowiedzialna za dawanie głosu przez wszystkie zwierzęta tylko iteruje po liście zwierząt i woła na nich metodę DajGłos. Jeżeli dodamy nowe zwierzę, to jedynie dodamy nową klasę, a nie będziemy musieli zmieniać takich klas, jak ZwierzecyKoncert.
Zalety
- Mniej miejsc w kodzie trzeba zmodyfikować podczas wprowadzania zmiany.
- Klienci uzależnieni są od abstrakcji, a nie od szczegółów implementacyjnych (zasada Odwrócenia zależności).
- Łatwiejsze testowanie.
- Łatwiejsze utrzymanie.
Wady
- Należy tworzyć abstrakcje.
Wszystkie posty związane z mini projektem: Poznaj zasady SOLID i OOP:
[catlist name=”projekt-poznaj-zasady-solid-i-oop” pagination=yes orderby=date order=asc author=no numberposts=100]Źródła
Obraz główny
Materiały
- https://devcave.pl/notatnik-juniora/zasady-projektowania-kodu
- https://medium.com/@iamprabal/encapsulation-4f5392d172a3
- https://pl.cs.jhu.edu/oose/lectures/design-principles.shtml
Subskrybuj!