Po co refaktoryzować? Nie można od razu napisać dobrze? Czy słaby kod to zawsze zły kod?

@somekind:

Jeżeli komuś implementacja wzorców sprawia wysiłek; jeżeli zamiast wiedząc, że np. jakieś dane mają być przetwarzane za pomocą różnych algorytmów w zależności od parametru woli walnąć wielką metodę z drabinką ifów zamiast kilka małych klas w strategii, to jest po prostu niesprawnym programistą.

Idealny przykład jak braki w doświadczeniu i jezykach powodują brandzlowanie się wzorcami. Drabinka ifów nie jest alternatywą dla wzorca strategii.
Strategia to bardzo szczególny przypadek higher order function. Walenie jakichkolwiek klas, żeby zrobić coś co jest naturalnym rozwiązaniem w każdym współczesym języku (który dorobił się lambd) to troszkę patologia. W przypadku programowania fp w prawie każdej linijce kodu znajdzie się coś co na siłę można nazwać strategią, ale podkreślanie tego nie ma sensu. Tak, jak nie ma sensu fascynowanie się w każdym zdaniu, że piszemy prozą.

jarekr000000 napisał(a):

Tak, jak nie ma sensu fascynowanie się w każdym zdaniu, że piszemy prozą.

Uważam że podejście nie koduj pisz prozę ma jakiś sens

no właśnmie jest se wielka metoda to zamieniamy ja na ...małe kl;asy? a dlaczego nie na małe metody na początek?

Prawie nikt nie robi od razu wiekich klas i metod (no chyba że patrzymy do hinduskiego kodu). Klasa ma 8000 linii, a metoda 16 parametrów, ale to narastało zwykle latami.
Weź fiksnij to na szybko, tam jest taki wielki warunek, trzeba dorobić nowy case. No i mamy ten nieszczęsny warunek.

• jak ma dwa case to ok.
• Cztery - robi się trochę przykro.
• Osiem - programiści zaczynają mówić, że trzeba by to zrefaktoryzować, bo nie mieści się na ekranie, ale managment nie rozumie czemu dodanie siódmego case'a było proste, a osmego już jest trudne.
• Szesnaście case'ów w ifie - programiści zaczynają się zwalniać, bo poziom szamba jest taki że nie da się oddychać.

Przy którym poziomie szamba/case'ów w ifie należy zacząć sprzątać? Pewnie przy trzecim, a może nawet przy drugim. Jakby od razu było wiadomo że tam będzie 16 różnych algorytmów to by to lepiej zaprojektowano :(

jarekr000000 napisał(a):

Idealny przykład jak braki w doświadczeniu i jezykach powodują brandzlowanie się wzorcami.

To nie było brandzlowanie, po prostu podałem przykład częstej patologii o banalnym rozwiązaniu.

Drabinka ifów nie jest alternatywą dla wzorca strategii.

Oczywiście, że nie. Ale niektórzy tak to piszą, bo się nie brandzlują. Albo może uważają, że programowanie funkcyjne polega na długich funkcjach, nie wiem. :)

Strategia to bardzo szczególny przypadek higher order function. Walenie jakichkolwiek klas, żeby zrobić coś co jest naturalnym rozwiązaniem w każdym współczesym języku (który dorobił się lambd) to troszkę patologia.

Dobrze, i gdzie umieścisz 20 lambd po 30 linijek kodu każda?

W krótszych przypadkach można klas nie robić, ale nadal - przyczepiłeś się nie do tego, co trzeba. No chyba, że chcesz tu i teraz tutaj przyznać, ze pisanie najeżonej ifami metody na 600 linii kodu jest w porządku?
Bo jeśli krytykujesz krytykowanie ifologii i przerośniętych metod, to tak jakbyś to popierał.

@somekind:

Dobrze, i gdzie umieścisz 20 lambd po 30 linijek kodu każda?

W przypdadku dłuższego kodu zamiast lambd można użyć funkcji, a te funkcje można rozbić na mniejsze.
A wszystko to można trzymac w plikach - równiez w wielu małych. Można też w klasach jak mamy jakiś ułomny język co nie umie w funkcje.

@jarekr000000: oczywiście zgodzę się że niektóre języki lepiej wspierają dobre nawyki ale jak dla mnie to czepiasz się teraz szczegółów. Chodzi o to że jak masz eksport do pliku to nie trzeba za kazdym razem robić ifa, tylko możesz mieć funkcje albo klasy które spełniają odpowiedni kontrakt i mieć łatwe rozszerzenie kodu o kolejne formaty. Czy to zrobisz lambda czy nie - idea jest podobna.

Marcin Marcin napisał(a):

Kod ma być zamknięty na zmiany i otwarty na rozszerzenia

A co to oznacza? Bo całkiem niedawno był tu taki poradnik wg. którego oznacza to, że każda publiczna metoda powinna być wirtualna, żeby dało się ja nadpisać ;)

jarekr000000 napisał(a):

W przypdadku dłuższego kodu zamiast lambd można użyć funkcji, a te funkcje można rozbić na mniejsze.
A wszystko to można trzymac w plikach - równiez w wielu małych. Można też w klasach jak mamy jakiś ułomny język co nie umie w funkcje.

No, więc chyba można stwierdzić, że w różnych językach wzorce mogą wyglądać różnie.
A to że w językach obiektowych wzorce używają obiektów, to nie jest efekt mojego brandzlowania i braku doświadczenia, tylko specyfiki tych języków.

Saalin napisał(a):

A co to oznacza? Bo całkiem niedawno był tu taki poradnik wg. którego oznacza to, że każda publiczna metoda powinna być wirtualna, żeby dało się ja nadpisać ;)

No jak dla mnie, to wzorce typu strategia, metoda szablonowa, łańcuch odpowiedzialności są właśnie rozwiązaniami OCP, bo dla nowego przypadku nie trzeba ruszać starego kodu, tylko stworzyć nowy.

KamilAdam napisał(a):

Jakby od razu było wiadomo że tam będzie 16 różnych algorytmów to by to lepiej zaprojektowano :(

Gdyby każde wpisanie 'git init' było analizowane, z pomocą wróżki, czy urośnie z tego coś wielkiego to może inaczej by się od początku szkicowało, sorry: świadomie pisało.

@somekind:

A to że w językach obiektowych wzorce używają obiektów, to nie jest efekt mojego brandzlowania i braku doświadczenia, tylko specyfiki tych języków.

Patrząc z punktu widzenia Java i C# to te języki nie są już od dawna czysto obiektowe. C# chyba od więcej niż 10 lat. Co oznacza, że nie trzeba się gimnastykować i używać pokrętnych rozwiązań na klasach na proste problemy. Zresztą C# ma też zresztą goto i unsafe i też nie trzeba tego wcale używać i robić z C# Basica.
(btw. metoda szablonowa - też higher order function (jak większość wzorców behavioralnych), chain of responsibility - function composition).