Wątek przeniesiony 2024-01-04 19:48 z PHP przez Riddle.
Cześć, ostatnio gdy udostępniłem film o tym co zmieniło się w PHP otrzymałem wiele ciekawych komentarzy, więc wracam z nowym materiałem.
Tym razem mięso, które może się przydać osobą, które programują a potem, jak czasem ja, nie są w stanie nic zrozumieć ze swojego kodu po kilku latach 
Jak to naprawić?
Świetnie może w tym pomóc programowanie abstrakcyjne i właśnie o tym zrobiłem nowy film - co sądzicie o takim podejściu do „samo tłumaczącego się kodu”?
Wole pierwotną wersję, bo wiem, że cholera wie co robi ten kod. Tutaj widać, że mamy jakieś Sample::create, które robi obiekt, które ma jedyną rolę tj. przypisanie $sample->deep_analitics = true wobec czego ten cały kod można wyrzucić.
Wszystkie decyzje np. dlaczego logika w serwisie a nie w controllerze albo użycie interfejsów powinny być dobrze opisane, bo jak ktoś się zainspiruje tym filmem to nie będzie wiedział po co tak ma robić i ostatecznie będzie podejmował gorsze decyzje niż bez tej wiedzy
To fakt, dlatego warto znać te podstawy i podejmować decyzje właściwe dla projektu.
Weź też pod uwagę, że to pierwsza faza refaktoryzacji, natomiast kod z wysokim couplingiem - masz rację - czasem może być uzasadniony...
Gorzej jeśli później będziesz chciał podjąć inną decyzję, a już się nie da.
Wow! Niezły materiał w sumie.
Pierwszą połowe, jak oglądałem to aż się zdziwiłem, bo faktycznie do pierwszej połowy nie ma się do czego przyczepić. Ta wstawka z "Znasz SOLID? A pokaż kod" Na prawde niezłe. Śmiechłem 
. Można powiedzieć że ta "teoria", czyli czym jest abstrakcja, etc. to masz 10/10 (a to rzadkość u mnie, że tak wysoką ocenę tam 
).
Ale do drugiej połowy już się przyczepię trochę.
Co na plus:
getGraph() i getBsvGraph() są git.Co na minus:
Mam wrażenie że trochę za mało wysiłku było włożone w znalezienie dobrych nazw dla funkcji. Wydzielanie metod dlatego jest takie pomocne, bo Ty, jako pisacz kodu, wkładasz wysiłek w nazwanie metod i przekazanie informacji, tak żeby czytający sam tego nie musiał robić.
readSampleFile() spoko, ale jak ja bym zobaczył readSampleFile() to pomyślałbym że to wczytuje treść pliku jako string. Ta metoda jednak zwraca listę linijek w pliku (bo ma explode()), więc moim zdaniem powinna się nazywać readSampleFileLines() albo po prostu readFileLines().getSamplesList() ma się nazywać "samples list"? Czym się różni "samples list" od po prostu "samples"?SampleProcessorService? Powiedziałbym że abstrakcja powinna dotyczyć też nazw, i jak ja widzę nazwę SampleProcessorService to nie mam zielonego pojęcia co ta klasa robi. Rozumiem, że to jest chęć dopasowania się do jakiejś tam konwencji, ale moim zdaniem to jest słabe. Patrząc na pierwszą wersję kodu, to ja nazwałbym tą klasę po prostu Sample albo Samples. Jakie nowe informacje przekazujesz dodając do nazwy klasy słowo Processor albo Service?getResult() mi nic nie mówi. Wydzielenie tej metody było dobre. Zgadzam się z Tobą. Ale moim zdaniem nazwa konkretna getResult() raczej nie.Co znowu na plus:
Co znowu na minus:
Jeszcze moja osobista bolączka - ja nie cierpie wydzielać interfejsów "po to żeby były". Bo YAGNI. Wydzielenie interfejsu jest łatwe, i nie ma nic złego w tym żeby użyć konkretnej klasy która robi fetcha po HTTP bezpośrednio w klasie. Jak zajdzie potrzeba podmianki implementacji, to wtedy się doda ten interfejs. No chyba że stosujesz Dependency Inversion, i dodajesz interfejs jako punkt styku dwóch modułów - tylko wtedy trzeba to po bożemu podzielić na dwa hermetyczne moduły.
Tyle ode mnie. Materiał bardzo fajny.
W sumie to co tu wymieniłem to są drobne uwagi, które nie psują przekazu całości - a całość (jak rozumiem), jest oddzielenie rzeczy ważnych od mniej ważnych. I to moim zdaniem Twój film przekazuje całkiem nieźle. Także za całokształt ja dałbym 8.9/10.
PS: Musiałem słuchać na prędkości 2.0, bo inaczej nie byłem w stanie 
Tak na marginesie tu nie ma abstrakcji.
Abstrakcja jest przeciwieństwem konkretów. Dlatego abstrakcja jest niezależna od modelu, a na filmiku wszystko jest na odwrót (wszystko jest zależne od samples). Jeśli zmienią się wymagania biznesowego to autor tego kodu będzie musiał zmieniać te swoje abstrakcje.
Abstrakcja pomaga kontrolować złożoność i głównymi korzyścią z posiadania abstrakcji jest ukrywanie szczegółów, o których w czasie realizowania zadań nie trzeba myśleć.
Natomiast jakbym miał klasę X która operuje modelem, to musiałbym znać szczegóły jej implementacji inaczej nie miałbym pewności czy zadanie jakie dowożę jest spójne pod kątem wymagań biznesowych.
znowutosamo7 napisał(a):
Tak na marginesie tu nie ma abstrakcji.
Abstrakcja jest przeciwieństwem konkretów. Dlatego abstrakcja jest niezależna od modelu, a na filmiku wszystko jest na odwrót (wszystko jest zależne od samples). Jeśli zmienią się wymagania biznesowego to autor tego kodu będzie musiał zmieniać te swoje abstrakcje.
Abstrakcja pomaga kontrolować złożoność i głównymi korzyścią z posiadania abstrakcji jest ukrywanie szczegółów, o których w czasie realizowania zadań nie trzeba myśleć.
Natomiast jakbym miał klasę X która operuje modelem, to musiałbym znać szczegóły jej implementacji inaczej nie miałbym pewności czy zadanie jakie dowożę jest spójne pod kątem wymagań biznesowych.
Autor filmiku chciał nałożyć abstrakcję np na HTTP i inne takie rzeczy, nie na samples. Więc to co zrobił, owszem jest abstrakcją.
znowutosamo7 napisał(a):
Abstrakcja jest przeciwieństwem konkretów. Dlatego abstrakcja jest niezależna od modelu, a na filmiku wszystko jest na odwrót (wszystko jest zależne od samples). Jeśli zmienią się wymagania biznesowego to autor tego kodu będzie musiał zmieniać te swoje abstrakcje.
Abstrakcja ma definicję i extract method wprowadza abstrakcję pod postacią metody
Tam jest nałożona abstrakcja, wszystko jest pod interfejsami, ale jak zaznaczałem - to jest dopiero pierwsza faza refaktoryzacji…
Zapraszam na następne filmy w których naprawię to, na co zwracasz uwagę, za pomocą pipes&filters 
xD php
Mówicie abstrakcja. Zgadzam się, ale taka abstrakcja to zły przykład, bo przecieka jeśli tylko pojawią się nowe wymagania w projekcie.
Przeciekająca abstrakcja jest gorsza niż brak abstrakcji.
znowutosamo7 napisał(a):
Przeciekająca abstrakcja jest gorsza niż brak abstrakcji.
No nie no. Aż tak to nie.
Zła abstrakcja jest gorsza niż brak abstrakcji - to zgoda. Bo to jest krok w złą stronę (można powiedzieć, że w tył).
Ale przeciekająca abstrakcja, jest lepsza niż brak abstrakcji - to jest krok w dobrą stronę.
Mój feedback będzie bardziej teoretyczny niż praktyczny. Nie uważam że powinieneś go zastosować, a nawet myślę że zastosowanie go mogłoby negatywnie wpłynąć na discoverability twojego contentu, ale
SOLID oraz Clean Code to nie są fundamenty ani computer science, ani software engineeringu.
To po prostu terminy marketingowe Uncle Boba, a ich trafność/jakość jest jaka jest, krytyki nie brakuje,
co w sumie minimalnie potwierdza fakt, iż uznałeś że kilka dekad po ich spisaniu nadal jest potrzeba/luka na rynku aby nagrywać kursy o nich ( ;) )
i teraz, czy warto pchać ludzi w kierunku Boba? a może warto wspomnieć że SOLID itd. to po prostu jego fanaberia, a nie jakieś "prawa"
WeiXiao napisał(a):
SOLID oraz Clean Code to nie są fundamenty ani computer science, ani software engineeringu.
To po prostu terminy marketingowe Uncle Boba, a ich trafność/jakość jest jaka jest, krytyki nie brakuje,
Jakiś argument za tym?
Filmik spoko, jednak to wszystko takie zbyt uzależnione od tego konkretnego przypadku. Pokazujesz tutaj bardzo prostą metodę refaktoru - wydzielać rzeczy do metod, potem do klas.
I taka metoda może działać, sam często tak robię, że zbieram kod i z chaosu coś się zaczyna wyłaniać. Tylko nie wiem, czy jest to powtarzalna recepta. Do tego trzeba mieć wyczucie abstrakcji (bo samo wydzielanie na oślep dużych kawałków kodu do funkcji to jeszcze nie jest tworzenie abstrakcji).
Nie mówię, że nie masz wyczucia abstrakcji, tylko raczej sugeruję, że ktoś, kto obejrzy ten filmik, może po prostu zacząć wydzielać wszystko do metod, ale bez żadnej refleksji, co wydziela i dlaczego (niby racjonalizujesz jakoś swoje decyzje, ale dość powierzchownie). A wydzielanie rzeczy na pałę może mieć różny skutek - może kod będzie lepiej ułożony, ale może się skończyć tym, że będzie po prostu więcej funkcji robiących jakieś dziwne cudy. Taki kod później ciężko się czyta i utrzymuje.
slsy napisał(a):
jak ktoś się zainspiruje tym filmem to nie będzie wiedział po co tak ma robić i ostatecznie będzie podejmował gorsze decyzje niż bez tej wiedzy
Takie mam wrażenie też. Film, jak się domyślam, kierowany jest bardziej do osób początkujących, a takie osoby nie do końca muszą rozumieć intuicyjnie, co wydzielać i kiedy.
Niby wszystko fajnie, ale koniec końców i tak pracuje się z kodem, który czasami "jest jaki jest" z różnych powodów (biznesowych czy umiejętności). Ja np. w pracy mam kod, który ktoś z zewnątrz określiłby jako legacy/spaghetti, ale po zrozumieniu zamysłu/założeń autorów wychodzi na to, że takie podejście ma swoje uzasadnienie. Tak więc wydaje mi się, że porady odnośnie pisania kodu trzeba walidować i czerpać to, co będzie pasować. Tutaj zgodzę się z @Riddle
Jeszcze moja osobista bolączka - ja nie cierpie wydzielać interfejsów "po to żeby były". Bo YAGNI. Wydzielenie interfejsu jest łatwe, i nie ma nic złego w tym żeby użyć konkretnej klasy która robi fetcha po HTTP bezpośrednio w klasie.
Hej.
Odpowiadając na wasze komentarze.
Każdy z was ma rację i myli się jednocześnie - a w szczególności ja.
Bo w IT jak tutaj można wyczytać, albo wyczuć, wbrew pozorom nie ma 0/1 - tylko jest "to zależy". I teraz ten przykład jest dość prostym przykładem jak to powinno działać, ale to nie jest "MUSISZ TAK ZROBIĆ" i nie poleciłbym robienia czegokolwiek bez stawiania "tak, ale".
To jest super że pojawiają się takie komentarze, ale żeby to było jasne - film ma swoje prawa. Czy można rozmawiać dziesiątki godzin o refaktorze i dodawać "tak, ale" - jasne że można, ale tylko zaangażowane w to osoby będą to robić, a reszta "normalsów" sobie pójdzie.
Nie robię tych filmików oczywiście dla fame, tylko po to żeby inspirować juniorów i midów do szerszego myślenia... A seniorów do kwestionowania.
Czy taki refaktor można zrobić inaczej? Tak!
Czy to przecieka jeśli tylko pojawią się nowe wymagania w projekcie? Być może, ale to również dlatego, że mam kolejny odcinek o pipes&filters i musiało być to odpowiednio skondensowane.
Czy SOLID to nie są fundamenty? Znowu - to zależy. Moim zdaniem KAŻDY musi je znać, ale stosownie ich to jest inna bajka i CUPID np. jest fajną odpowiedzią!
Czy to wszystko takie zbyt uzależnione od tego konkretnego przypadku? Tak - bo to jest jeden filmik na youtube, on musi mieć jak w rozprawce "wstęp, rozwinięcie, zakończenie" - niestety inaczej się nie da, żeby miało to sens... Bo ludzie chcą szybko czegoś - takich mamy odbiorców i to dla nich te fimy są robione. Fakt, brakuje w nich szczegółów - ale te zostaną zawsze rozszerzone w następnych odcinkach 
Czy i tak pracuje się z kodem, który czasami "jest jaki jest" z różnych powodów? Oczywiście że tak i to jest kwitesencja tego co napisałem na górze - wszyscy macie rację.
A dlaczego i dla kogo jest ten film?
Dla mnie z przeszłości. Tego Macina co jak naj^^&*ał kodzik w wordpressie który działał to był z niego zadowolony, bo nie wiedział że można o tym myśleć inaczej.
I wiecie co, takich Marcinów jak ja z przeszłości, dzisiaj wchodzących na rynek - jest sporo... Dlatego myślę że to całkiem sensowne, choć nadal - wszyscy macie rację i mylicie się jednocześnie 
Wszystkiego dobrego - idę nagrywać dalej!
Celem abstrakcji nie jest bycie niejasnym, ale stworzenie nowego poziomu semantycznego, na którym można być absolutnie precyzyjnym.
Edsger Dijkstra
Nie wiem na którym etapie tego filmiku uzyskujesz nowy poziom semantyczny czy absolutną precyzję. Jak dla mnie to takiego momentu nie było, bo te metody mogły by się rozjechać, gdyby projekt ruszył z kolejnymi wymaganiami.
Znanym i dobrym przykładem abstrakcji są LINQ, bazy, xpath, regexp, reactjs - wszystkie je również charakteryzuje to, że są oderwane od biznesowych wymagań.
SOLID oraz Clean Code to nie są fundamenty ani computer science, ani software engineeringu.
Nie wiem jaka jest w tym doza marketingu, nie wiem. Sam SOLID jako zbiór 5 wytrychów które pozwalają na szybko ocenić, czy pewne podejścia są dobre, nijakie lub tragiczne to dobre narzędzie. Większość ludzi dająca krzykliwe nagłowki i "OBAJACA SOLID" to swoich blogach, przyjmuje jakaś albo religiją albo patalogiczną interpretacje a opotem udowadnia że to głupie podejscie[tylko tego ze to oni je wybrali nie zauważają]
Przede wszystkim trzeba zapytać czy clean code w php ma sens. To tak jakby zaprosić sprzątaczkę do meliny </trolling>
Byś chociaż pingnął ludzi których cytujesz :P
Nie wiem jaka jest w tym doza marketingu
No taka, że to wręcz branding Boba.
Sam SOLID jako zbiór 5 wytrychów które pozwalają na szybko ocenić
Jakbyś się postarał, to pewnie mógłbyś stworzyć z 10 innych takich "SOLID"owych tworów które również byłyby sensownymi lub nawet lepszymi wskazówkami na to czy kod jest ok. I na pewno takie istnieją, ale po prostu się nie przebiły do mainstreamu.
A co do SOLIDa, Clean Coda itd. - tak jak pisałem, krytyki nie brakuje.
Sam fakt tego że SOLID jest ciągle dyskutowany w necie jedynie potwierdza że nie jest to udana próba sformalizowania tych konceptów.
Oczywiście zrobienie tego perfekcyjnie jest trudne, jednakże jeżeli SOLID jest sprzedawany jako jakiś złoty środek na wyzwania związane z modelowaniem, to może jednak warto go pokrytykować?
(ja post wcześniej)Większość ludzi dająca krzykliwe nagłowki i "OBALAJACA SOLID" to swoich blogach, przyjmuje jakaś albo religiją albo patalogiczną interpretacje a potem udowadnia że to głupie podejscie
(Ty)jednakże jeżeli SOLID jest sprzedawany jako jakiś złoty środek(...) to może jednak warto go pokrytykować.
Trafiony zatopiony. Gapienie się na kod żeby stwierdzić czy zachowa się tak jak chcemy czy nie, jest problemem nie rozstrzygalnym. Wiec każde podejście "rozwiązujące wszystkie problemy" bez ograniczeń lub mocnych kompromisów, jest błędne. Generalnie dyskusja redukująca się, do tego czy SOLID jest tym "złotym środkiem" czy nie, jest z istoty rzeczy jałowa. Głupia teza jest głupia, super nie wiedziałem.
Sam fakt tego że SOLID jest ciągle dyskutowany w necie jedynie potwierdza że nie jest to udana próba sformalizowania tych konceptów.
Ja bym raczej powiedział ze coś musi być na rzeczy, skoro temat nie umarł jako chwilowa moda. Gdyby nie było w tym wartości juz dawno ktoś wyskoczył by z nowym lepszym fremeworkiem intelektualnym, który by solid zastąpił, tylko ze tego nigdzie nie widać.
Ja bym raczej powiedział ze coś musi być na rzeczy, skoro temat nie umarł jako chwilowa moda. Gdyby nie było w tym wartości juz dawno ktoś wyskoczył by z nowym lepszym fremeworkiem intelektualnym, który by solid zastąpił, tylko ze tego nigdzie nie widać.
To wybitnie optymistyczne. Śmiem twierdzić że rzeczywistość jest taka, że takie sobie rozwiązania wystarczą i się utrzymują.
Patrz na języki programowania: C, Javascript, etc.
Spójrz na literki
S - zapytaj 50 programistów, a usłyszysz 20 różnych interpretacji (do tego stopnia że dostało hotfixa - zmiane definicji :D)
L - to po prostu pożyczone koncepty z publikacji Liskovej
I - jest trywialne.
W ogóle oryginalnych pryncypiów Boba było 11
http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
Cały ten SOLID jest słabym fundamentem, bo jest skalany myślą Javową i OOP, więc co najwyżej może być fundamentem do OOP, ale imo to też takie sobie
Ja bym raczej powiedział ze coś musi być na rzeczy, skoro temat nie umarł jako chwilowa moda. Gdyby nie było w tym wartości juz dawno ktoś wyskoczył by z nowym lepszym fremeworkiem intelektualnym, który by solid zastąpił, tylko ze tego nigdzie nie widać.
To wybitnie optymistyczne. Śmiem twierdzić że rzeczywistość jest taka, że takie sobie rozwiązania wystarczą i się utrzymują.
Patrz na języki programowania: C, Javascript, etc.
Java script to świetny przykład potwierdzający moją teze. Js i całe podstawy weba mają wady, js sie adaptuje dodaje strict mode, powstaje cała masa fajerwerków próbujące niwelować te wady, powstają języki jak TS, powstają frameworki jak react, które odcinają sie od czystego html i stawiają na "kontrolki" jak w desctopie, stworzono webAssebbly, które pozwala pisać kod, w innych jezykach niz JS.
Fakty są takie ze dzieje sie wlasnie tak jak napisałem, nawet jeżeli nie można tak po prostu zrezygnować z JS, to potężna ilość wysiłku idzie w to żeby ograniczyć jego wady.
Java script to świetny przykład potwierdzający moją teze. Js i całe podstawy weba mają wady, js sie adaptuje dodaje strict mode, powstaje cała masa fajerwerków próbujące niwelować te wady, powstają języki jak TS, powstają frameworki jak react, które odcinają sie od czystego html i stawiają na "kontrolki" jak w desctopie, stworzono webAssebbly, które pozwala pisać kod, w innych jezykach niz JS
Fakty są takie ze dzieje sie wlasnie tak jak napisałem, nawet jeżeli nie można tak po prostu zrezygnować z JS, to potężna ilość wysiłku idzie w to żeby ograniczyć jego wady
uważasz że takie nieskończone trytytkowanie to coś dobrego? Jasne, nikt nie jest w stanie przewidzieć przyszłości i ciężko się czepiać bo w końcu js umożliwił aby internet wyglądał tak, jak teraz wygląda, jednakże to nie sprawia że jest dobry.
właśnie webassembly to próba uratowania przeglądarek w dobry sposób
uważasz że takie nieskończone trytytkowanie to coś dobrego?
Nigdzie nie napisałem że to coś dobrego, bronie tezy że w przypadku w przypadku rażących błędów, dość szybko i naturalnie pojawiają się alternatywy. I używam JS jako przykładu. W kwestii SOLID takich alternatyw nie widać-a przynajmniej ja nie widzę, ale może źle patrzę i chętnie zmiennie zdanie jak są- a jeśli ich nie widać to znaczy że poruszają własciwe problemu.
Jest alternatywa - olanie tego całego SOLIDa, tyle.
To gadanie jakoby SOLID był potrzebny do "szybkiej oceny czy dane podejście jest okej" jest przereklamowane.
Jeżeli nie masz expa, to SOLIDa i tak nie rozumiesz.
Jeżeli masz expa, to lepiej lub gorzej jesteś w stanie ocenić jakie cechy ma dany kod, i teraz wykonujesz ewaluacje względem wymagań, celu, potrzeb czy czegokolwiek innego.
To gadanie jakoby SOLID był potrzebny do "szybkiej oceny czy dane podejście jest okej" jest przereklamowane.
Złośliwie odpowiadając znowu wracamy do punktu wyjścia czyli krytyki jakieś przereklamowanej karykatury.
Jest alternatywa - olanie tego całego SOLIDa, tyle.
Jeżeli masz expa, to lepiej lub gorzej jesteś w stanie ocenić jakie cechy ma dany kod, i teraz wykonujesz ewaluacje względem wymagań, celu, potrzeb czy czegokolwiek innego.
Odpowiadając nie złośliwie. Mam odczucie, że powodem dla których SOLID jest krytykowany nie sa wartości, czy pomysły które on promuje, tylko to że opisuje pewien wycinek rzeczywistości i nie uwzględnia własnie wymagań, celu, potrzeb itd. redukując proces pisania kodu, do regulek, "RÓB JEDNĄ RZECZ NARAZ". Jest to ułomność, ale ciągle uważam ze te regułki mają wartość i reprezetujać cos prawdziwie urzytecznego.
Podejść masz expa, to lepiej lub gorzej jesteś w stanie ocenić jakie cechy ma dany kod całkowicie rozlatuje sie gdy masz dwóch developerów oboje ocenią kod i obojgu zdarzy się to akurat gorzej. Zbor regułek, które są całkiem prawdziwe, jeśli ich sie nie nad interpretuje za bardzo jest lepszym system, niz walka kogutów.
Zbiór regułek jest dobrym narzędziem, gdy nie masz ekspa i się uczysz.
masz expa, to lepiej lub gorzej jesteś w stanie ocenić jakie cechy ma dany kod
Jak wiesz co robić, to to rób. Zgadzam sie w 100%. Najlepszy system jaki jest, wystarzy wiedzieć co trzeba zrobić a potem robić to. Bez cienia sarkazmu sie zgadzam. Złoty standard.
Problemem jest że Twoja opinia nie sprawdzi sie w każdym innym wypadku.
tylko to że opisuje pewien wycinek rzeczywistości i nie uwzględnia własnie wymagań, celu, potrzeb itd. redukując proces pisania kodu, do regulek, "RÓB JEDNĄ RZECZ NARAZ"
I moim zdaniem trik polega m.in na tym, że jeżeli bierzesz tego SOLIDa, i w nim np. to S które ma wiele interpretacji, to czy faktycznie mamy jedną prostą regułkę, którą ludzie mogą ot tak stosować?
Podejść masz expa, to lepiej lub gorzej jesteś w stanie ocenić jakie cechy ma dany kod całkowicie rozlatuje sie gdy masz dwóch developerów oboje ocenią kod i obojgu zdarzy się to akurat gorzej. Zbor regułek, które są całkiem prawdziwe, jeśli ich sie nie nad interpretuje za bardzo jest lepszym system, niz walka kogutów.
A jeżeli masz dwóch devów którzy inaczej interpretują te same regułki? to masz podobną sytuację. Z tym, że regułek można religijnie bronić, a bez regułek prędzej czy później porównujesz listę wad i zalet
I ja nie neguje wartości regułek, guidelinesów, tipów, a twierdzę że SOLID jako taki zbiór kilku regułek nie jest jakiś szczególnie dobry.
Ba, jak na to jak wiele wysiłku idzie w jego promowanie i wpychanie ludziom nawet na uczelniach (!!!), to jest przereklamowany.
literki S, O oraz I jeszcze się bronią i można je dostrzec w innych dziedzinach (życie codzienne, ustrój państwa itp.)
S - w łazience się oczyszczasz, w kuchni jesz, więc każde pomieszczenie ma pojedynczą odpowiedzialność
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)
I - poszczególne organy państwowe nie mogą wszystkiego, tylko to jest kompetencja Prezydenta, to jest kompetencja Sejmu itp.
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.
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).
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.