• Najnowsze pytania
  • Bez odpowiedzi
  • Zadaj pytanie
  • Kategorie
  • Tagi
  • Zdobyte punkty
  • Ekipa ninja
  • IRC
  • FAQ
  • Regulamin
  • Książki warte uwagi

Solid - Zasada segregacji interfejsów

Aruba Cloud - Virtual Private Server VPS
0 głosów
412 wizyt
pytanie zadane 17 grudnia 2019 w Nasze projekty przez cSharpKazik Użytkownik (840 p.)
Cześć

 Chciałem się podzielić nowym artykułem na blogu. Może i tutaj kogoś zainteresuje. Tym razem o kolejnej z zasad SOLID - Interface Segregation Principle (ISP).

https://www.modestprogrammer.pl/solid-interface-segregation-principle-isp-wszystko-co-powinienes-wiedziec-o-zasadzie-segregacji-interfejsow

1 odpowiedź

+1 głos
odpowiedź 22 grudnia 2019 przez RafalS VIP (122,820 p.)
edycja 22 grudnia 2019 przez RafalS

Duży plus za omawianie zasad SOLID, ale przykłady trochę zbyt przesadzone.

Analizując przykłady, można by wysnuć wniosek, że skoro interfejsy mają być małe, to najlepiej niech zawsze mają tylko jedną metodę. Hmm, skoro to takie proste i mechaniczne, to czemu na internecie jest tak dużo artykułów o ISP? Fakt, czasem tak się da (np. Runnable) i możemy otwierać szampana, bo piszemy SOLIDny kod bez większego wysiłku. Niestety w większości przypadków nie ma tak łatwo i tego typu interfejsy będą strasznie na siłę. Tak jak IWork i IEat. Wybacz :P

Brakło mi podkreślenia, że w tym wszystkich chodzi o dobre zaprojektowanie abstrakcji i jest to naprawdę trudne. Jeśli źle ją zaprojektujesz, to potem na siłę rozbijasz interfejsy na mniejsze, żeby spełnić jakąś tam zasadę. Kiedy jednocześnie inna zasada mówi, że powinieneś maksymalizować spójność (cohesion) ¯\_(ツ)_/¯

Correct abstraction is the key to Interface Segregation Principle

ISP pozwoli Ci określić czy kod jest czysty, czy nie, ale nie za bardzo mówi jak tę mityczną czystość osiągnąć. Tutaj masz świetny artykuł, który porusza właśnie ten aspekt zasady ISP:

This principle comes naturally when you start decomposing your problem space with identifying major roles that take part in your domain. And it’s never a mechanical action. No principle can automatically lead you to the correct object model.

So ISP is a poor guidance when designing software, but an excellent indicator of whether it’s healthy or not. Don’t think about ISP when designing your software. Think about whether your abstractions are reusable and composable, and whether your objects are encapsulated and cohesive.

komentarz 22 grudnia 2019 przez tkz Nałogowiec (42,020 p.)
A mi zawsze brakuje "to tylko reguły, do których MOŻESZ, ale nie musisz się stosować" i to prawie przy każdym artykule związanym z clean code. Większość piszących jest na poziomie juniora, wszędzie wcisnę solida, drya, czy kisa. Brakuje mi zdań przysłowiowych seniorów, którzy potrafią podważyć te zasady.

Podobne pytania

0 głosów
1 odpowiedź 352 wizyt
0 głosów
1 odpowiedź 1,551 wizyt
pytanie zadane 10 października 2019 w Java przez magicznyukf Początkujący (260 p.)
+1 głos
1 odpowiedź 135 wizyt
pytanie zadane 10 maja 2024 w C# przez ross Nowicjusz (180 p.)

93,335 zapytań

142,331 odpowiedzi

322,415 komentarzy

62,670 pasjonatów

Motyw:

Akcja Pajacyk

Pajacyk od wielu lat dożywia dzieci. Pomóż klikając w zielony brzuszek na stronie. Dziękujemy! ♡

Oto polecana książka warta uwagi.
Pełną listę książek znajdziesz tutaj

Wprowadzenie do ITsec, tom 1 Wprowadzenie do ITsec, tom 2

Można już zamawiać dwa tomy książek o ITsec pt. "Wprowadzenie do bezpieczeństwa IT" - mamy dla Was kod: pasja (użyjcie go w koszyku), dzięki któremu uzyskamy aż 15% zniżki! Dziękujemy ekipie Sekuraka za fajny rabat dla naszej Społeczności!

...