(Anty)wzorce projektowe

@slsy: Różnica pomiędzy TemplateMethod, a Strategy, to tylko tyle, że w pierwszym przypadku dziedziczymy po klasie abstrakcyjnej i implementujemy jedną metodę, w drugim musimy "jakoś" zaimplementować cały interface, np. na 30 metod. Najprościej pewnie skorzystać sobie z wrappera. Czy uważasz, że pisanie wrappera w stylu:

public void doSomething(int i){
  return underlying.doSomething(i);
}

z wyjątkiem tej jednej metody, gdzie trzeba będzie zrobić coś w stylu:

public void doSomething(int i){
  return i+1;
}

jest lepsze niż dziedziczenie po jakiejś klasie, o której wiadomo, ze została napisana po to, żeby po niej dziedziczyć i nadpisanie tej konkretnej metody nie wiąże się z żadnym ryzykiem? Tak, wiem, że w niektórych językach jest delegowanie (fajne), w innych jest np. DynamicProxy (mniej fajne).

Saalin napisał(a):

MuadibAtrides napisał(a):

Z mojego doświadczenia:

• brak znajomości przez zespół i programistów więcej niż 1 paradygmatu / języka
• brak czytania oficjalnych dokumentacji frameworków / bibliotek / języka gdy ktoś musi się przestawić do danej rzeczy
• brak stosowania OOP i strukturyzowania kodu
• brak stosowania dziedziczenia
• wciskanie na siłę wszędzie tam gdzie nie trzeba FP
• brak dbania o warstwę danych - logikę można bardzo łatwo zaorać i przepisać w krótkim czasie, ale jak ktoś ma dziwnie ułożone dane, nie otypowane, nie mające sensu do problemu - to potem trzeba robić wokół tego fikołki, a najczęściej wystarczy dobrze zaprojektować sobie dane do przetwarzania
• brak spójności, słabe nazwy zmiennych
• brak refactoringu tam gdzie to się to przydaje i upraszczanie rzeczy

Od kiedy brak czytania dokumentacji to wzorzec? Idziemy nieubłaganie w kierunku "Programistycznych WTFów" (to kolejny post w tym tonie) , a tematem były wzorce, czyli coś co zostało przyjęte przez społeczność z aprobatą, było umyślnie używane, a okazuje się nie być tak dobre po czasie (jak Active Record choćby).

@Saalin inni komentujący ten temat spotkali się z ludźmi co robili antywzorce lub z wzorców antywzorce - ja natomiast miałem N przypadków, gdzie w danej bibliotece / języku / frameworku było w dokumentacji (której przeczytanie zajmuje max 2-3h) jak zrobić XYZ zamiast tego ludzie kombinowali i robili jakieś potworki. Akurat miałem dużo przypadków, gdzie dużo koszmarów / antywzorców programistycznych powstało z braku chęci czytania dokumentacji :/

Np.
Dla GWT zamiast owrapować przez JSNI javascript do klas Javowych aby pisać kod w javie i się komunikować między obiektami JavaScript <-> Java, ludzie dodawali globalne zmienne w window, które służyły do komunikacji lub kolejki doczepiane do window, lub bezpośrednie referencje do obiektów i próba ich hakowania przez wywoływanie funkcji. Takie skrypty były jeszcze dodawane na "lewo" zamiast prawidłowo przez plik konfiguracyjny XML frameworka GWT, zgodnie z dokumentacją.

Później takie fikołki powodują, że ludzie szukają te rzeczy, walczą z globalnymi obiektami i grafami zależności, bo komuś nie chciało się przeczytać dokumentacji.

Po prostu jak w memie "6h debugowania może zaoszczędzić Tobie 5 min czytania dokumentacji".

Moim zdaniem nie trzeba być programistą XYZ, żeby wiedzieć, że jak siadam do czegoś nowego jak nowy język i framework wypadałoby sprawdzić dokumentację / internety aby spradzić jak to się robi poprawnie w danym języku.

Chyba też na mikroblogu ktoś wrzucił ostatnio kod z Pythona, gdzie lista w zdefiniowanym domyślnym argumencie się mutuje i hejt na Pythona - znowu ten sam problem, Python tłumaczy swoje decyzje projektowe i czemu coś działa, ale trzeba sięgnąć do prawilnego źródła jakim jest tutorial 1-3h z Pythona w Pythonie a nie szukać na lewych hinduskich stronach.

projektowanie kodu opartego o dziedziczenie jest dla mnie sztuką dla sztuki i tworzeniem szumu, który ostatecznie utrudnia rozumowanie o kodzie

Czyli np. na zasadę DRY też masz wywalone? Bo między innymi dzięki dziedziczeniu, możemy użyć tej samej metody w różnych miejscach obiektach.
Według mnie Ty chyba nie rozumiesz do czego służy dziedziczenie po prostu i jakie daje korzyści @slsy.

Napisałem to Ja programista php, co to niby taki słaby język, ale przynajmniej rozumiem po co jest dziedziczenie, podstawa oop.

@omenomn2:

Czyli np. na zasadę DRY też masz wywalone? Bo między innymi dzięki dziedziczeniu, możemy użyć tej samej metody w różnych miejscach obiektach.

A może uważa że wady przewyższają korzyści? ;)

A może uważa że wady przewyższają korzyści? ;)

Dziedziczenie nie ma wad, a już na pewno nie stosunku do programowania funkcyjnego, którego pewnie autor jest fanem.

@omenomn2:

a już na pewno nie stosunku do programowania funkcyjnego, którego pewnie autor jest fanem.

Co sprawia że tak uważasz?

Przecież oop to ewolucja programowania funkcyjnego.
To tak jakbyś mówił, że samoloty są gówniane, bo trzeba nadal jeździć konno, albo chodzić na piechotę.

Ten wątek faktycznie miał chyba w zamiarze obnażenie słabych praktyk, a ostatecznie słabe praktyki są w nim wychwalane.
A wzorce i oop to shit.

omenomn2 napisał(a):

Przecież oop to ewolucja programowania funkcyjnego.

Dobry trolling nie jest zły :D

A co może najpierw było oop, a później weszło funkcyjne?
Raczej nie, więc tak, oop to następca, ewolucja funkcyjności.
Jak dla kogoś oop jest słabe to rozmowa jest bez sensu, bo tak jak mówię, to jakby negować samoloty, samochody itp. czyli ogólnie rozwój.

omenomn2 napisał(a):

A co może najpierw było oop, a później weszło funkcyjne?

Ogólnie to były takie dwa niezależne światy które dopiero od ok 1518 lat powoli merdzują się w mainstreamie, czyli mniej więcej od pojawienia się Scali. Niby wcześniej był Ocaml, ale w tym przecież nikt nie programuje :D

Miby wcześniej C# i C++ miały alementy funkcyjności, ale o tym nie mówiło się głośno żeby nie straszyć programistów C# i C++ :P

Przecież większość języków najpierw była proceduralna to co mówisz to jest jakaś odwrócona rzeczywistość.

https://pl.wikipedia.org/wiki/Obiektowy_j%C4%99zyk_programowania

Języki C++ i Perl, pierwotnie przeznaczone głównie do programowania proceduralnego, zostały wzbogacone o elementy obiektowości; wraz z rozwojem i wzrostem znaczenia tych języków były one wykorzystywane do zadań coraz bardziej zgodnych z paradygmatem programowania obiektowego.

A co ma do tego proceduralność?

Java, C# i Haskell nigdy nie były proceduralne. Java i C# od razu były obiektowe, a Haskell - funkcyjny

To, że proceduralność to jest używanie samych funkcji (nie obiektów, programowanie funkcyjne), a obiektowe zaczęło wchodzić później.
język C - https://pl.wikipedia.org/wiki/C_(j%C4%99zyk_programowania)
język C++ - https://pl.wikipedia.org/wiki/C%2B%2B

C++ – język programowania ogólnego przeznaczenia. Język został zaprojektowany przez Bjarne Stroustrupa jako rozszerzenie języka C o obiektowe mechanizmy abstrakcji danych i silną statyczną kontrolę typów. Zachowanie zgodności z językiem C na poziomie kodu źródłowego pozostaje jednym z podstawowych celów projektowych kolejnych standardów języka

O obiektowe mechanizmy, czyli jeżyk C zewoluował do C++, którym jest już obiektowość.

Ale co ma proceduralność do programowania funkcyjnego? To że język jest proceduralny nie znaczy jeszcze że język jest funkcyjny. Co więcej w świecie programowania funkcyjnego to właśnie programowanie proceduralne jest czesto przedstawiane jako odwrotność programowanai funkcyjnego. Trzymając się terminologii ze świata programowania funkcyjnego to:

• programowanie proceduralne to wykonywanie efektów (programowanie imperatywne)
• programowanie funkcyjne to zwracanie wartości (programowanie deklaratywne)

Aha, dobra, rypło mi się z proceduralnym programowaniem :p

Tak z ciekawości zapytam. Czy znacie jakiś produkt, który jest używany i jest napisany w 100% funkcyjnie? :)
Pisząc produkt mam na myśli coś co używa końcowy użytkownik.

.andy napisał(a):

Tak z ciekawości zapytam. Czy znacie jakiś produkt, który jest używany i jest napisany w 100% funkcyjnie? :)

Pytasz o to czy istnieje jakaś aplikacja napisana w Haskellu która zarabia na siebie czy ZIO wystarczy. Bo jak ZIO starczy to wołam @stivens . A do Haskella można w zasadzie zawołać @jarekr000000

Kurcze, jest nawet dedykowany portal do szukania funkcyjnej pracy https://functional.works-hub.com/ o_0"

W haskellu napisano jedną dobrą rzecz https://github.com/rainbyte/frag

Poza tym jest używany w bankach, fintechach - cały Standard Chartered podobno na tym stoi (ale nie byłem w środku). Z tym, że to banki i pieniądze - więc to już nie są dobre rzeczy.

Z bardzo złych rzeczy to pandoc, elm, purescript czyli kolejne narzędzia do gnębienia programistów.

@jarekr000000: ale tam jest w 100% kod napisany funkcyjnie? :)

@.andy: masz kod źródłowy - szukaj

.andy napisał(a):

ale tam jest w 100% kod napisany funkcyjnie? :)

Czy kod w Haskellu może być niefunkcyjny? Czy robienie cały czas IO i IO.Unsafe jest niefunkcyjne? To trochę już podchodzi pod pytanie filozoficzne :D JDG napisał że każdy użycie modany jest niefunkcyjne. Ktoś to na 4p odpowiedział mi że monada jest funkcyjnym zapisem niefunkcyjnego (imperatywnego) kodu (czy jakoś tak to było)

Z drugiej strony można odbić piłeczkę - Czy istnieje kod w 100% obiektowy?

Może nie, ale z tego co widzę, to to wychwalane funkcyjne programowanie, jakoś niespecjalnie ma wiele projektów dużych, ciekawych napisane :)

@KamilAdam:

Z drugiej strony można odbić piłeczkę - Czy istnieje kod w 100% obiektowy?

Świetne pytanie! :)

Ja swoje zadałem aby właśnie ktoś napisał coś takiego jak ty napisałeś ;) Moim zdaniem (a się nie znam :P) one się uzupełniają i przeplatają ;)

chyba proceduralne się przeplata z obiektowym, a nie funkcyjne, przynajmniej w php.
W Vuejs composition api, to jest programowanie funkcyjne jeśli dobrze rozumiem i tu faktycznie się przeplata.

@.andy: nic się nie przeplata

Co najwyżej - kod funkcyjny czasem sięga do niskopoziomowych bibliotek (dokładnie tak jak java w jvm), które są napisane różnie - przeważnie imperatywnie. Bo czy obiektowo, czy nie nie ma żadnego znaczenia. Haskell po prostu wywołuje funkcję native (ffi). W większości są to funkcje systemowe lub wrappery (opengl) w C.

W scali można przeplatac obiektowe z funkcyjnym, ale nie trzeba. W sumie często wykorzystuje się składnie scali pochodzącą z "czasów obiektowych", ale programowaniem obiektowym bym tego nie nazwał. Pomijam ludzi, którzy specjalnie pisza niefunkcyjnie w scali.

W ogóle programowanie obiektowe to nie jest przeciwieństwo funkcyjnego. Przeciwieństwo funkcyjnego to imperatywne - lambda calculus vs turing machine.
A programowanie obiektowe? to po prostu jakiś tam szczegół w podklasie imperatywnego.

(btw. wiem, że John De Goes się z tym przeciwieństwem wprost nie zgadzał w jakimś twicie, ale IMO czasem coś palnie, a czasem jedzie w marketing - np. opowieści o łączeniu w ZIO porogramowania obiektowego z funkcyjnym to dla mnie czysty marketing).

.andy napisał(a):

@jarekr000000: ale tam jest w 100% kod napisany funkcyjnie? :)

W ogole skad to parcie na 100%? Jak bedzie 95% + 5% imperatywnej optymalizacji (bo np. trzeba efektywnie graf zbudowac a potem cos ciezkiego obliczeniowo z nim zrobic) to co?

Swoja droga nie jestem frontendowcem ale AFAIK React jest funkcyjny ('not strictly'). A to znaczy ze wiekszosc uzytkownikow internetu w mniejszym lub wiekszym stopniu korzysta z FP softu.

@stivens:

W ogole skad to parcie na 100%?

No bo tutaj trochę taki kult FP panuje i tak z ciekawości chciałbym wiedzieć, czy da się tylko w taki sposób tworzyć oprogramowanie. No bo skoro to podejście jest najlepsze i zjada inne, to powinno się tak dać?

A to znaczy ze wiekszosc uzytkownikow internetu w mniejszym lub wiekszym stopniu korzysta z FP softu.

No ale jest też coś na backendzie nie? :)

Największą przeszkodą w podejściu FP jest potrzeba myślenia i projektowania przed napisaniem kodu. Inaczej wychodzi kupa większa niż w przypadku OOP czy programowania imperatywnego. Ktoś musi w końcu zaprojektować niezbędne abstrakcje i DSLe żeby na nich oprzeć faktyczny biznesowy kod. Przynajmniej ja odniosłem takie wrażenie czytając książki do FP.

W programowaniu obiektowym można stosować podejście alternatywne: "na pałę", które przy paradygmacie OOP czasami potrafi zwrócić przyzwoite wyniki. Myślenie w kategorii obiektów jest dla ludzi po prostu prostsze i bardziej naturalne, co sprawia że można uzyskać przyzwoity kod bez nadmiernego skupiania się na dizajnie.

Na naszej polskiej ziemi natomiast FP ma inne problemy:

• Praktycznie nie występuje na uczelniach (góra 1 semestr)
• Brak materiałów o pisaniu aplikacji biznesowych w czystym FP
• Poza Scalą i F# pozostałe języki mają małe i zamknięte społeczności (Reszta typu Reason czy Elixir to nisze^2)
• Prawie żadna firma tak nie pisze więc ludzie nie mają gdzie zdobyć doświadczenia, również wybór dziwnego języka często oznacza mniejsze zarobki na rynku pracy

Ja myśle że FP fanatycy powinni zacząć od skupienia się na uczelniach. Przykładowo nie wiem dlaczego uczelnia traci czas na naukę takiej np. Javy zamiast uczyć Skali i wielu paradygmatów na raz. W końcu znając bardziej zaawansowany język łatno nauczyć się tego bardziej prymitywnego. Tyle że u nas przy oderwaniu przemysł - świat akademicki, to nawet nie ma jak tego typu przesłania przekazać dla wykładowców...

IMO dążenie do 100% FP czy OOP źle się kończy (o ile w ogóle się udaje).

W Javie niby masz OOP, ale od tego są bardzo popularne wyjątki:

• klasy XxxUtils
• adnotacje
• kod low-latency (np. tablice zamiast list, pamięć no-GC)

W FP IMO możesz zrobić kawałek systemu, ale nie całość.
@jarekr000000 pracuje z jakimiś aplikacjami w Haskellu, może napisze jak duże one są. Jakie wspierają interfejsy, formaty, protokoły, maszyny. Jakie mają latency.

Zresztą nawet w matematyce już jakiś czas temu zarzucono funkcje jako jedyne rozwiązanie (patrz funkcje niedeterministyczne - IFS, iteracyjne - Mandelbrot, sklejane, QC itd).
FP goni za czymś co u źródła jest już outdated.