SOLID w praktyce

5
Krolik napisał(a):

Zawsze znajdzie się taki ficzer, którego dodanie będzie wymagało modyfikacji istniejącego kodu.

Tak, to prawda, zawsze znajdzie się. Byle nie było to regułą.

I niby dlaczego zmiana istniejącego kodu miałaby być gorsza niż dopisanie nowego kodu?

Bo łatwiej napisać nową małą klasę/metodę niż kolejnego ifa w drabince w linii 7435, a przy okazji będzie to bezpieczniejsze dla już zaimplementowanych ficzerów.

Zwłaszcza jeśli z powodu chęci zachowania otwartości skomplikowany został istniejący kod. Wyglada to trochę jak promocja w markecie. Zapłać więcej teraz za dwie sztuki, z których jednej teraz nie potrzebujesz, ale może przyda się później.

Ja tak szczerze chciałbym zobaczyć to skomplikowanie przez stosowanie dobrych praktyk. Widziałem już sporo skomplikowanego kodu, ale jego skomplikowanie wynikało z uwielbienia do pisania długich procedur pełnych skoków warunkowych, żadnego SOLIDa nikt nigdy nie próbował implementować.

Dla mnie O stoi w jawnej sprzeczności z YAGNI, więc jest podobna sytuacja co z S. Musisz przewidywać co się prawdopodobnie zmieni i jakie nowe ficzery będą na pewno potrzebne.

Nie sądzę:

  • Tego, że będą różne ficzery nie trzeba przewidywać, bo jest to pewne, więc na poziomie logiki aplikacji już można zacząć używać np. CQS. Mamy OCP, nie łamiemy YAGNI.
  • W momencie, gdy dochodzi nowy sposób realizowania jakiejś logiki, możemy wydzielić wspólny interfejs dla starego i nowego sposobu. Znowu mamy OCP, nie łamiemy YAGNI.

Bo robienie na zapas wcale nie jest dobre

Oczywiście, że nie. Na szczęście żadna zasada nie mówi, aby robić rzeczy na zapas.

jarekr000000 napisał(a):

Proponuję w takim razie:
DLID
czyli Do not put all code in a single method + L I D . I będzię dużo jaśniejsze niż jakieś mętne SRP czy OC.

Jestem za. Masz siłę przebicia, możesz to zacząć promować, zobaczymy jak społeczność przyjmie.

0

Interpretacja tych skrótów nie ma sensu, bo wykładnia jest już dawno zasugerowana przez samego autora, czyli Roberta C. Martina, choćby w jego wykładach dostępnych na yt.

4

Wujek Bob ostatnio na Twitterze:

The Single Responsibility Principle (SRP): Gather together those things that change for the same reasons and at the same times. Separate those things that change for different reasons or at different times.

The Open-Closed Principle (OCP): Separate modules that frequently change from modules that change less frequently with a layer of abstraction.

The Liskov Substitution Principle (LSP): The implementation of an interface must never violate the contract between that interface and its users.

The Interface Segregation Principle (ISP): Don’t depend on things you don’t need.

The Dependency Inversion Principle (DIP): Lower level policies should depend on higher level policies.

1
Michał Kuliński napisał(a):

Wujek Bob ostatnio na Twitterze:

The Single Responsibility Principle (SRP): Gather together those things that change for the same reasons and at the same times. Separate those things that change for different reasons or at different times.

Nie kupuję tego. Przykładowo mogę pomieszać logikę z IO razem ze sobą beż żadnej separacji czy abstrakcji. I taki kod za każdym razem będzie się zmieniał razem.

The Open-Closed Principle (OCP): Separate modules that frequently change from modules that change less frequently with a layer of abstraction.

I dalej zamiast konkretów skupiamy się na wróżbiarstwie. Pisząc kod nie wiem jak często będzie się zmieniał

5
slsy napisał(a):

The Open-Closed Principle (OCP): Separate modules that frequently change from modules that change less frequently with a layer of abstraction.

I dalej zamiast konkretów skupiamy się na wróżbiarstwie. Pisząc kod nie wiem jak często będzie się zmieniał

Ten cały temat jest trochę to D... bo o ile te zasady można zdefiniować jednym zdaniem to potem potrzeba cały rozdział książki żeby to skomentować. I tak właśnie skomentował w którejś ze swoich książek Wujek Bob. Że nie chodzi tu o wróżniarstwo tylko o predykcję (progrmozowanie):

  • Jeśli moduł zmieniał się często w przeszłości to prawdopodobnie będzie zmianiał się nadal czesto
  • Jeśli moduł nie zmieniał się czesto w przeszłości to na razie zakładamy że nie będzie się często zmieniał w przyszłości

Oczywiście nasze założenia mogą byc błędne - np zmieni się główny klient czy inwestor i zostaną zaproponowane zupełnie inne funkcje systemu, wjadą nowi architekci legacy kodu i będą narzekać kto napisał to g'wno. Prowadzi to mnie do spostrzeżenia że nie można napisać kodu dobrego pernamentnie, może on być tylko dobry na daną chwilę :(

0
slsy napisał(a):
Michał Kuliński napisał(a):

Wujek Bob ostatnio na Twitterze:

The Single Responsibility Principle (SRP): Gather together those things that change for the same reasons and at the same times. Separate those things that change for different reasons or at different times.

Nie kupuję tego. Przykładowo mogę pomieszać logikę z IO razem ze sobą beż żadnej separacji czy abstrakcji. I taki kod za każdym razem będzie się zmieniał razem.

Ale powinieneś je odseparować.

The Open-Closed Principle (OCP): Separate modules that frequently change from modules that change less frequently with a layer of abstraction.

I dalej zamiast konkretów skupiamy się na wróżbiarstwie. Pisząc kod nie wiem jak często będzie się zmieniał

Nie musisz wiedzieć jak często.

Wystarczy że oddzielisz od siebie moduły, które podejrzewasz że mogą zmieniać się niezależnie.

4
slsy napisał(a):

Nie kupuję tego. Przykładowo mogę pomieszać logikę z IO razem ze sobą beż żadnej separacji czy abstrakcji. I taki kod za każdym razem będzie się zmieniał razem.

Oczywiście, że możesz, przecież nie ma żadnego zakazu. Kod i tak będzie świadczył o autorze kodu, nie o autorze zasad.

I dalej zamiast konkretów skupiamy się na wróżbiarstwie. Pisząc kod nie wiem jak często będzie się zmieniał

Nie wróżbiarstwo tylko oparta na doświadczeniu hipoteza. No, ale oczywiście tu jest problem, bo nie każdy posiada doświadczenie, a nawet jeśli posiada, to nie każdy potrafi wnioskować.

KamilAdam napisał(a):

Oczywiście nasze założenia mogą byc błędne - np zmieni się główny klient czy inwestor i zostaną zaproponowane zupełnie inne funkcje systemu, wjadą nowi architekci legacy kodu i będą narzekać kto napisał to g'wno. Prowadzi to mnie do spostrzeżenia że nie można napisać kodu dobrego pernamentnie, może on być tylko dobry na daną chwilę :(

Może być dobry na dużo dłużej niż dana chwila.

A programowanie to branża wymagająca twórczego myślenia i zdrowego rozsądku, to nie jest miejsce dla ludzi, którzy wymagają dokładnych instrukcji postępowania w każdej możliwej sytuacji, bo takich zwyczajnie nie da się stworzyć.

0
Riddle napisał(a):

Ale powinieneś je odseparować.

somekind napisał(a):

Oczywiście, że możesz, przecież nie ma żadnego zakazu. Kod i tak będzie świadczył o autorze kodu, nie o autorze zasad.

Wspaniały poziom dyskusji. Staram się sprowadzić do absurdu "nową" definicję wujka Boba na temat tego czym jest SRP. To jakie jest moje zdanie jest bez znaczenia.

somekind napisał(a):
slsy napisał(a):

Nie wróżbiarstwo tylko oparta na doświadczeniu hipoteza. No, ale oczywiście tu jest problem, bo nie każdy posiada doświadczenie, a nawet jeśli posiada, to nie każdy potrafi wnioskować.

Moje doświadczenie jest takie, że trzeba znaleźć balans pomiędzy abstrakcją a narzutem kognitywnym budowanym przez tą abstrakcję. Open abstrakcję mogę wrzucić w każde miejsce. Nawet tam, gdzie nie ma to sensu (i często taka błędna abstrakcja sprawia, że kod jest bardziej closed niż open dla konkretnej sytuacji).

somekind napisał(a):
slsy napisał(a):

Nie kupuję tego. Przykładowo mogę pomieszać logikę z IO razem ze sobą beż żadnej separacji czy abstrakcji. I taki kod za każdym razem będzie się zmieniał razem.
A programowanie to branża wymagająca twórczego myślenia i zdrowego rozsądku, to nie jest miejsce dla ludzi, którzy wymagają dokładnych instrukcji postępowania w każdej możliwej sytuacji, bo takich zwyczajnie nie da się stworzyć.

Zgadzam się. Dlatego nie podoba mi się definicja software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification" bo ja to widzę jako ma być rozszerzalnie i ch*j. Ta definicja nie prowokuje do twórczego myślenia i zdrowego rozsądku. Według mnie ta zasada powinna brzmieć bardziej według własnego doświadczenia warto czynić kod otwartym na rozszerzenia a zamkniętym na modyfikację jeśli uznamy, że potencjalne zalety będą większe niż wady

2
slsy napisał(a):

Zgadzam się. Dlatego nie podoba mi się definicja software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification" bo ja to widzę jako ma być rozszerzalnie i ch*j. Ta definicja nie prowokuje do twórczego myślenia i zdrowego rozsądku. Według mnie ta zasada powinna brzmieć bardziej według własnego doświadczenia warto czynić kod otwartym na rozszerzenia a zamkniętym na modyfikację jeśli uznamy, że potencjalne zalety będą większe niż wady

To jakiego słowa byś użył zamiast "should"?

Nikt nie mówi że ma być rozszerzalne i chuj. Nikt też tak nie uważa i nie ma tego na myśli kiedy przywołuję O/C. Myśle że ogromna większość ludzi kiedy mówi o O/C ma na myśli, to co napisałeś: według własnego doświadczenia warto czynić kod otwartym na rozszerzenia a zamkniętym na modyfikację jeśli uznamy, że potencjalne zalety będą większe niż wady.

3
slsy napisał(a):

Wspaniały poziom dyskusji. Staram się sprowadzić do absurdu "nową" definicję wujka Boba na temat tego czym jest SRP. To jakie jest moje zdanie jest bez znaczenia.

Nie chcę się czepiać, ale sprowadzanie do absurdu to nie jest jakieś wybitne dyskutowanie. :)

Moje doświadczenie jest takie, że trzeba znaleźć balans pomiędzy abstrakcją a narzutem kognitywnym budowanym przez tą abstrakcję.

Niewątpliwie, tylko w sumie w czym rzecz? Przecież żadna zasada nie mówi, że abstrakcje są obowiązkowe wszędzie.
Zresztą, należałoby najpierw zdefiniować abstrakcję, a z moich obserwacji wynika, że to może być niezły ubaw.

Open abstrakcję mogę wrzucić w każde miejsce. Nawet tam, gdzie nie ma to sensu (i często taka błędna abstrakcja sprawia, że kod jest bardziej closed niż open dla konkretnej sytuacji).

Jak najbardziej, każdego narzędzia można użyć źle.
Na szczęście bez wydzielania abstrakcji jest jeszcze gorzej.

Zgadzam się. Dlatego nie podoba mi się definicja software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification" bo ja to widzę jako ma być rozszerzalnie i ch*j. Ta definicja nie prowokuje do twórczego myślenia i zdrowego rozsądku.

Ale to naprawdę nie jest branża dla ludzi, którzy potrzebują specjalnego zaproszenia do myślenia.

Według mnie ta zasada powinna brzmieć bardziej według własnego doświadczenia warto czynić kod otwartym na rozszerzenia a zamkniętym na modyfikację jeśli uznamy, że potencjalne zalety będą większe niż wady

Te części, które dodałeś są w domyśle, i dotyczą wszystkiego. Jeśli ktoś bierze jakąś zasadę, ideę, technologię, framework, bibliotekę, wzorzec czy cokolwiek, i używa bezmyślnie, to straci czas i zapewne stworzy coś, czego nie będzie dało się rozwijać.

1 użytkowników online, w tym zalogowanych: 0, gości: 1