LukeJL napisał(a):

Natomiast z L jest problem, że trochę nie pasuje. To jest już dość szczegółowa (choć zdroworozsądkowa) zasada dotycząca typowania w OOP (chyba, że ją zbyt wąsko rozumiem).

A to dziwne, ja tego zupełnie tego tak nie widzę. Jak dla mnie ISP i LSP to są dwie strony tej samej monety (tzn. od abstrakcji do szczegółu, i od szczegółu do abstrakcji).

Widzę to tak, że:

  • "interfejs nie powinien mieć nadmiarowych części implementacji" (LSP) - nadmiarowy tutaj to znaczy taki którego nie można do końca spełnić (i przez to nie można użyć tej klasy wszędzie tam gdzie ten interfejs jest przyjmowany)
  • "implementacja nie powinna mieć nadmiarowych części interfejsów" (ISP) - nadmiarowy tutaj znaczy że za dużo jest wpakowane do jednego interfejsu (bo np dwie klasy używają części wspólnych dwóch interfejsów, i przez to ta część wspólna powinna być wydzielona do trzeciego)
LukeJL napisał(a):

Pytanie, jakie mi się nasuwa, to na ile te literki były wymyślone po przemyśleniu, a na ile po prostu dopasowane po to, żeby skrót ładnie brzmiał SOLID i dzięki temu ładnie mogło to zdobyć popularność. Bo przecież SOID czy SOI brzmiało by gorzej. Ew. SOLD fajnie by brzmiało. Ew. zamiast O można by było podstawić np. E jak extension i pomyśleć, co można z tego by zrobić. Ale też nic sensownego. Ogólnie gość chyba po prostu siedział nad tymi zasadami i wybierał z tych 11 zasad takie, żeby ułożyć dobry skrót.

Też byłem ciekaw skąd to się wzięło, i zrobiłem research, moge Ci powiedzieć od razu że zbiór był wymyślony najpierw, i początkowo chyba DI było pierwsze. Dopiero po paru latach ktoś powiedział "ej, bo kolejność można zamienić żeby brzmiało SOLID" i tak już zostało (Robert Martin uważał że DI było fundamentalne).

LukeJL napisał(a):

S - w łazience się oczyszczasz, w kuchni jesz, więc każde pomieszczenie ma pojedynczą odpowiedzialność

Niby tak, ale to jest ciężka analogia bo w łazience możesz też brać prysznic, myć zęby, suszyć włosy.

Ale jest na to silver-lighting - jak stosujesz pozostałe zasady SOLID, to to "SRP" dostaje się praktycznie za darmo. Kiedy programuję jakąś apkę, stosuję continuous refactoring, staram się trzymać niektórych wzoróców, staram się mieć odpowiedni poziom couplingu (z preferencją na mniejszy), oraz pozostałe praktyki, to jakoś ta pojedyncza odpowiedzialnośc wychodzi mi "sama z siebie".

LukeJL napisał(a):

O - łatwiej jest rozbudować np. mebel przykręcając coś tylko niż rozkręcając wszystko i składać od nowa (więc taki mebel jest otwarty na rozszerzenia, ale zamknięty na modyfikacje)

O - mi się bardzo wpasowuje we wzorce - decorator, compozyt, strategia. Dzięki nim wszystkim możemy osiągnąć Open/Close.

LukeJL napisał(a):

co do D, to sposób jej sformułowania jest dość dziki, ale jak się zastanowić, to po prostu dążenie do uogólniania i myślenia abstrakcyjnego. Żeby programując opierać się na abstrakcjach. Trochę jak w matmie.

Ja lubię analogię Roberta Martina, i mam na to dwa wyjaśnienia:

  • Albo genezę nazwy: czyli "obrócenie kierunku zależności" - chodzi tutaj o to że kierunek przepływu (to jak metody się wołają idzie od A do B) jest odwrotny do kierunku zależności (bo to B ma zależność do A), stąd "odwrócenie zależności". Można wywołać coś na co się nie ma zależności - bardzo fajna rzecz.
  • Albo prostsza definicja - po prostu plugin. Każdy jeden plugin nie ważne do czego spełnia DI.