Konkurs Nie SOLID-nie. Podsumowanie.

K

Słowem wstępu

Stało się, zakończyłem właśnie konkurs na blogu, związany z całą serią postów dotyczących zasad SOLID i w ramach tego postu, publikuję odpowiedzi/komentarze które były warunkiem udziału w konkursie. Publikuję również moje przemyślenia względem tych właśnie komentarzy.
Myślę, że to będzie bardzo dobre podsumowanie całej serii „Nie SOLID-nie”, jak i samego konkursu.

Seria postów

  1. Nie SOLID-nie #01: Single Responsibility Principle
  2. Nie SOLID-nie #02: Open Close Principle
  3. Nie SOLID-nie #03: Liskov Substitution Principle
  4. Nie SOLID-nie #04: Interface Segregation Principle
  5. Nie SOLID-nie #05: Dependency Inversion Principle

Komentarze

  • Sprawa 1: Nie znam nazwisk, więc pozwólcie, że będę się posługiwał imionami…
  • Sprawa 2: Komentarze są posortowane „by date”…

Krzysiek 2 kwietnia 2019
Dla mnie najważniejsza jest literka S . A dlaczego ? Bo jest prosta i dosyć łatwo ja zacząć stosować w praktyce, a korzyści sa bardzo duże.
Gdyby każdy początkujący programista już od startu jej przestrzegał, może dałoby się uniknąć kilku ośmiotysię2czników 😉

Zgadzam się. SRP jest prosta, rzekłbym nawet, że najprostsza do wdrożenia. Zarówno na poziomie klasy jak i na innym poziomie abstrakcji, czy to modułu, czy metody.

Kamil 4 kwietnia 2019
Jak dla mnie oczywiście SRP, bo:
– kod staję się czytelny, prostszy do zrozumienia
– łatwiej go przetestować, zmniejsza ryzyko powstania błędów
– wymusza trzymania się jednej warstwy abstrakcji.

Coś jest na rzeczy, bo to już druga osoba która zwraca uwagę na tę zasadę. Z pierwszym podpunktem się niekoniecznie zgadzam, tzn. widziałem klasy zgodne z SRP, a jednocześnie z tak zagmatwanym kodem że „hej”…
Za to bardzo się zgadzam z podpunktem drugim. Jak najbardziej! SRP ułatwia testowanie w ramach najbardziej popularnej jednostki testu jakim jest klasa.

Nie wiem  czy dobrze rozumiem ostatni podpunkt, ale tak. Rozszerzenie reguły SRP na warstwy aplikacji, niejako powoduje, że każda z nich, w klasycznym podejściu, „ogarnia” coraz to wyższą warstwę abstrakcji i wymusza na programiście, nie mieszanie ich.

Bartosz 14 kwietnia 2019 o 12:20
Ja niedawno zacząłem zgłębiać dobre praktyki programowania, tak też trafiłem na ten wpis. Długo myślałem,
jaka zasada jest najważniejsza i raczej cięzko wybrać jedną – wszystkie wydają się ważne i niejako,
ze sobą połączone – często trzymanie się jednej implikuje wprowadzenie pozostałych. Myślę,
że warto mieć z tyłu głowy wszystkie zasady jednak to co mi pomaga to skupienie się na zasadzie Open Closed – powoduje to,
że program od razu projektuje w inny sposób, często wymusza to stosowanie wzorców projektowych oraz pozostałych zasad,
których wprowadzenie nie wymaga już większej modyfikacji w kodzie.

Nie mniej, nie więcej.

Nic dodać, nic ująć.

Nie trzeba stosować wszystkich zasad SOLID, ale wystarczy dobrze sprawę przemyśleć i się okazuje, że one nie tylko się „wspierają”, ale również wymuszają dobre praktyki przy projektowaniu kodu.

I rzeczywiście, chcąc dostosować się do zasady Open Closed Principle, często uciekamy się do stosowania wzorców projektowych.

Lukasz 14 kwietnia 2019 o 16:02
Osobiście uważam, że najważniejszą z zasad SOLID jest Dependency Inversion Principle. Poza oczywistą zaletą z jej stosowania,
którą jest łączenie modułów projektowanej aplikacji za pomocą interfejsów, pozwala na tworzenie łatwo testowanego kodu,
gdyż wszystkie zależności danego modułu, w miarę potrzeby mogą zostać zastąpione odpowiednio skonfigurowanymi mockami.

Czyli krótko mówiąc – Loose coupling.

Pozwala na odseparowanie od siebie nie tylko klas, ale także warstw aplikacji. Bajka. Dzięki temu jesteśmy w stanie budować aplikacje „z klocków”, które są mniej lub bardziej wymienne.

O komentarz pokusił się równierz jeden z naszych sponsorów Jarek Stadnicki. Rzecz jasna nagrody nie dostał (Jarku, to tak nie działa),
ale gwoli ścisłości, publikuję również i jego komentarz…

Jarosław Stadnicki 6 kwietnia 2019 o 21:59
Ja lubię dwa:
* SRP: czystość, krótki kod
* IOC: 2 powody:

  • Mam wszystko gdzieś, jak przyjdą materiały potrzebne do roboty to będę robić, jak nie przyjdą to nie będę robić;
  • Gdy mam klasę, która ma duże zależności, to wiem, że ona ma nic nie robić, tylko rozdzielać zadania po niższych od siebie, nawet nie muszę jej nazywać manager, bo wystarczy spojrzenie na listę zależności które przyjmuje

Jeszcze raz dziękuję sponsorom konkursu Jarkowi Stadnickiemu i Pawłowi Klimczykowi za udostępnienie fajnych nagród

Podsumowanie

Widać jak na dłoni, że pomimo tego, iż różne osoby różnie „czerpią” z SOLIDa, zasady te są tak skonstruowane, aby się wzajemnie wspierać i uzupełniać, aby wymuszać dobre praktyki, które nie tylko poprawiają jakość produktu, ale także zmniejszają koszt tworzenia i utrzymania danego projektu.

Powiedzmy sobie szczerze, gdyby to nie działało i gdyby tak nie było, nikt by w stronę SOLIDa nawet nie spojrzał. My programiści jesteśmy mocno ukierunkowani na optymalizację nie tylko w pracy, ale i w życiu. Tak po prostu mamy (nie generalizuję, po prostu zauważam taką cechę) i nie używalibyśmy, masowo, czegoś co się po prostu nie sprawdza.

Archetyp

Przy okazji, pozwolę sobie zaapelować do wszystkich juniorów, lub seniorów którzy mają wpływ na juniorów.

UCZCIE SIEBIE, UCZCIE ICH. UCZCIE PODSTAW JUŻ NA STARCIE

…a zasady SOLID można w zupełności uznać za podstawy. Zawsze aktualne, zawsze się sprawdzają. Można powiedzieć, że są archetypem programowania!

Tak samo zasady DRY, YAGNI czy KISS.

Oczywiście, wszystko z dozą zdrowego rozsądku. No właśnie, jeśli nie znasz tych zasad to gdzie zdrowy rozsądek? Chodzi o to, że trudno ocenić czy posługujesz się najbardziej optymalnym sposobem myślenia, skoro nie znasz alternatywy.

Ot takie przemyślenia o SOLIDzie i znaczeniu tych zasad dla nas i dla projektu.

Piszcie SOLID-nie

Piszcie tak, aby „weszło Wam to w krew”, abyście nawet nie zauważali, że stosujecie się do tych zasad.Nie rozwiąże to Waszych wszystkich problemów, ale na pewno uwolni od wielu z nich.

Ja sam od jakiegoś czasu staram się właśnie tak postępować i ciągle uczę się tej sztuki.

A Ty co sądzisz?

Jak zwykle. Zachęcam do komentowania i udostępniania moich treści gdzie popadnie. W końcu – „nie ważne jak mówią, ważne żeby mówili” – (żart 😉 ).

Cześć i czołem!



Photo by dylan nolte on Unsplash

About the author

2 komentarze

  • Pozwolę dodać sobie mały komentarz.

    Uncle Bob tworząc oprogramowanie do drukarek sprytnie zauważył, że niektóre kawałki kodu da się zgrabnie wyodrębnić. Nie robił refaktoryzacji „bo trzeba robić”. On, mowiąc kolokwialnie, „przestał ogarniać” duża ilość kodu. Programowanie obiektowe ma cztery fundamenty: abstrakcja, dziedziczenie, polimorfizm i enkapsulacja. Na nich Uncle Bob oparł zbiór zasad roboczo nazwanych SOLDI. Do spółki z Michaelem Feathersem (napisał Working Efficiently with Legacy Code) stwierdzili, że przestawienie literek I i D zrobi solidną nazwę – stąd mamy SOLID. Ważne by pamiętać, że oni nie wymyślili zasad samych w sobie, ale po spotkaniu się wyżej opisanym problemem (drukarki) zrobili komplementarny zbiór.

    Zasady SOLID uczą przede wszystkim programowania komponentowego. Mamy komponenty komunikujące się przez interfejsy. Jest to dość dobrze przenaszalne na świat mikroserwisów. Z drugiej strony nie wpasowują się w programowanie funkcjonalne czy wielowątkowe. Tak więc każdy może jeszcze zapisać się annałach programowania 🙂

    • Mądrego, zawsze miło posłuchać.
      Dzięki za komentarz! Zwłaszcza, że wnosi wiedzę którą nie wszędzie da się wysznupać.
      Co do samego SOLIDa i wpasowania go w paradygmat obiektowy, jak się nad tym zastanowić, faktycznie bardzo ładnie się to wszystko składa do kupy.

By Patryk

Autor serwisu

Patryk

Społecznościowe

Instagram

Newsletter



Historycznie

Tagi