[blog] Zasady SOLID w praktyce

Question

Pora na kolejny post na blogu, po tygodniowej przerwie

Tym razem na temat zasad SOLID

Link do posta => https://wp.me/paEPwh-1a

Zacząłem też serie na blogu (uniwersalny programista), do której ten post należy => https://wp.me/paEPwh-1f

Piszcie gdyby coś było niezrozumiałe lub słabo wytłumaczone, post prawdopodobnie będzie się zmieniał z czasem, będą pojawiać się linki do innych postów itd

Comments

Szczerze, to jak dla mnie przykład z dyskiem google w OCP jest trochę chaotyczny i nie za bardzo wiem co chciałeś przekazać :v

Answer 1

Strasznie brakuje przykładów kodu – wpis bez nich wydaje się suchy.

Dodatkowo opis LSP wydaje mi się mocno niejasny. Chodzi wszak o to, by implementacje danego interfejsu były ze sobą spójne – nie ma konieczności wchodzenia w tak zagmatwane szczegóły. Przedstawiona w przykładzie metoda Run implementowana na interfejsie IAnimal jest IMO przykładem łamania zasady ISP (ogólny interfejs zawiera specjalistyczną metodę). W LSP raczej chodzi bardziej w drugą stronę: klasa potomna implementuje interfejs w niekompatybilny sposób (np zwraca inny rodzaj danych niż bazowy interfejs).

Z kolei w ISP zastanowiłbym się, czy na pewno dobrze jest rozszerzać poszczególne interfejsy? Osobiście raczej komponowałbym kilka różnych interfejsów zamiast robił ich hierarchię.

Answer 2

Warto też zwrócić uwagę na to co docelowo oznacza SRP. W Czystym kodzie pierwsze zdanie mówi:

Zasada pojedynczej odpowiedzialności (SRP) zakłada, że klasa lub moduł powinny mieć jeden
i tylko jeden powód do zmiany. Zasada ta zarówno definiuje odpowiedzialność, jak i daje wskazówki
odnośnie do wielkości klas. Klasy powinny mieć jedną odpowiedzialność — jeden powód do zmiany

Dodatkowo w kolejnej pozycji Martina Czysta Architektura, podkreślone jest to w ten sposób:

... (SRP), jest chyba najsłabiej zrozumiała. Prawdopodobnie wynika to z tego, że ma ona trochę niewłaściwą nazwę. Programiści, słysząc tę nazwę, od razu zakładają, że każdy z modułów powinien wykonywać tylko jedno zadanie.