Dzień dobry. Dzisiaj natknąłem się na ciekawy materiał, moim zdaniem przydatny, lecz natknąłem się tam na pewne stwierdzenie, które nieco obala Moje dotychczasowe pojmowanie obiektowośći. Fakt, materiał dość stary bo z 2012 roku, ale wątpie że coś się od tej pory zmieniło, a może?
(dokładnie od tej minuty od której się otworzy)
Chętnie poznam Wasze doświadczenia na ten temat.
Troszkę go poniosło :) nie wszystko co mówi trzeba traktować jako pewnik.
Java jest w rozkroku między programowaniem proceduralnym (utils) a funkcyjnym (streams).
Gdzieś pośrodku jest OOP.
W zasadzie to w jednym projekcie można mieszać te podejścia.
W kilku domenach rzeczywiście OOP może być armatą na komary, przykładowo rdzeń systemu operacyjnego czy programy i skrypty narzędziowe do 1000 linii, ale mówienie ogólnie, że to jest bullshit uważam za skrót myślowy.
Jeden Rabin powie tak drugi Rabin powie nie. Z jednej strony masz ludzi od SoA, z bezstanowymi serwisami operujacymi na DTO/strukturach danych a z drugiej ludzi od DDD i obiektowego modelowania dziedziny. Ja osobiście zalecam zdrowy rozsądek zamiast podejścia ideologicznego.
koles gada straszne bzdury momentami.
kazda, nawet najlepsza idea moze zostac zle uzyta jesli brakuje wiedzy, umiejetnosci i doswiadczenia.
mam nadzieje ze to tylko takie gadanie pod publiczke, bo jesli rzeczywiscie kolesiowi 20 lat zajelo odkrycie ze bezmysne dziedziczenie to nie jest sposob na dobrej jakosci soft to ja dziekuje za takie autorytety
Dziedziczenie jest jedną z cech OOP, przez co Seliga cały ten paradygmat nazwał bullshitem, ale nie chodziło mu o to, że wszystkie cechy OOP są bullshitem. Powiedział "dlaczego dziedziczenie jest błędem?!" oraz "interfejsy są kluczowe". Chodziło mu o to, że kompozycja ma wiele zalet w stosunku do dziedziczenia.
abstrahując od OOP - to ja bym chciał, żeby więcej ludzi myślało tak jak on mówi na talku - że dla niego rzeczy o których mówi są to podstawy, abecadło. Problem z dzisiejszymi programistami jest taki, że ludzie tylko klepią kody, a nie myślą głębiej jak coś działa pod spodem, nie znają podstaw programowania. A to powoduje bardzo słabe rozwiązania w rezultacie, jeśli siądzie taki klepacz, dla którego programowanie to tylko wykucie API na pamięć.
Co do OOP to w zasadzie bardzo mało osób programuje we właściwym OOP. Od jakiegoś czasu modnie jest hejtować OOP, ale problem jest taki, że ludzie nigdy się nie nauczyli pisać obiektowo, tj. w odpowiedni sposób.
Nie wiem jak to co mówi ma do postawionej tezy. Człowiek raczej podkreśla ile programiści wiedzą o mechanizmy, które dostaje z nowoczesnymi językami. Na takiej zasadzie każdy paradygmat i język programowania to bullshit, bo nie zwalnia z dobrej znajomości działania narzędzi, którymi się posługuje.
@Shalom jeżeli coś jest bullshitem to dla mnie właśnie DDD (poza samym podejściem do tworzenia oprogramowania), które jest niczym innym jak okrojonym OOP. Właściwe OOP to encapsulation i message passing i @LukeJL ma racje, bo mało kto tak programuje.
Seliga użył poteżnego skrótu myślowego: OOP to dziedziczenie, które faktycznie jest nadużywane, w miejscach, w których powinna być użyta kompozycja. Dlatego padły te słowa ze OOP to bullshit.
Desu napisał(a):
Seliga użył poteżnego skrótu myślowego: OOP to dziedziczenie, które faktycznie jest nadużywane, w miejscach, w których powinna być użyta kompozycja. Dlatego padły te słowa ze OOP to bullshit.
dla mnie to bardziej sobie wymyslil (albo zaadoptowal od innych mowcow) wroga i bohatersko z nim walczy ;) chyba kazdy srednio rozgarniety programista po paru miesiacach praktyki zaczyna zdawac sobie sprawe ze tutorialowe przyklady z konikami dziedziczacymi po abstract ssaku nijak sie maja do realnych projektow. rownie dobrze moglby powiedziec 'smerfy to bs, tak naprawde komunizm jest zly' :D
imo zero wartosci w takich wypowiedziach, poza tanimi kontrowersjami
Ja lubię to wystąpienie, ale oczywiście jest ono przerysowane, i na dodatek jest już trochę przestarzałe. To jest perspektywa z roku 2012, a od tego czasu w javie naprawdę dużo się wydarzyło.Pewne rzeczy dzisiaj wydają się nam oczywiste.
Poza tym, według mnie, on się odnosił do swojego doświadczenia, programisty zaczynającego od C++. Trzeba pamiętać, że kilkanaście lat temu, javowcy to byli głównie ludzie, którzy przechodzili z C++, więc można domniemywać, że odejście od myślenia java++, na stosowanie rozwiązań typowo javowych zajęło ludziom trochę czasu.
tdudzik
jeżeli coś jest bullshitem to dla mnie właśnie DDD (poza samym podejściem do tworzenia oprogramowania),
które jest niczym innym jak okrojonym OOP. Właściwe OOP to encapsulation i message passing
Trochę jak ten cytat z Alana Kaya - Object-oriented programming to me means only messaging, encapsulating and hiding state, and extreme late-binding of all things. :)
I do mnie to przemawia - komunikaty, enkapsulacja i dynamizm :)
i @LukeJL ma racje, bo mało kto tak programuje.
W ogóle to dochodzi do paradoksów typu zwolennicy Reduxa, którzy hejtują OOP (i uważają się za lepszych, bo piszą funkcyjnie, i gardzą wszystkim co obiektowe), nie zauważając, że sam Redux opiera się na klasycznych zasadach OOP (np. przesyłanie "akcji" w Redux to coś, co w Smalltalku było już kilkadziesiąt lat temu, tylko, że nazywało się to "message" a nie "action". Sama idea, żeby enkapsulować zmianę stanu jak to robi Redux to też w zasadzie jedna z klasycznych idei obiektówki - w klasycznym OOP wysyłasz "komunikat" do obiektu, i obiekt sam "zmienia swój stan" - czyli to, co robi Redux, a co się wydaje ludziom jakoś super innowacyjne tylko dlatego, że są czyste funkcje zamiast obiektów i że korzysta się z niemutowalnych struktur danych.
Innymi słowy Redux to taka emulacja obiektówki, tyle, że w funkcyjny sposób i to ludziom myli w głowie - wiele osób myśli, że jak mają napisane function zamiast class to już to nie ma nic wspólnego z OOP. I odwrotnie. Że wystarczy zrobić coś na klasach, a będzie to obiektowe (podczas gdy przecież można zrobić klasę i programować np. proceduralnie).
Temat krytyki OOPu już podejmowao na tym forum, ale skończyło się jak zawsze - zaeloci tego paradygmatu zakrzyczeli temat
Czy programowanie obiektowe to najgorszy paradygmat programowania jaki kiedykolwiek wymyślono?
Przekazywanie wiadomości jest podstawą https://en.wikipedia.org/wiki/Actor_model Enkapsulacja i ukrywanie stanu są natomiast obecne zarówno w powszechnie rozumianym OOP-ie jak i Actor modelu. Jeżeli więc założymy że "prawdziwy" OOP też opiera się głównie na przekazywaniu wiadomości (a dziedziczenie to mało nieistotna cecha) to będzie miał zbyt dużo wspólnego z Actor modelem, by stosować obie kategorie powszechnie.
Późne wiązanie ma natomiast zbyt dużo interpretacji by opierać na tym pojęciu jakieś skomplikowane wnioski. Gdyby Alan Kay sprecyzował co rozumie poprzez późne wiązanie to można by wtedy konkretnie polemizować.
Utarło się, że w OOPie główną cechą jest enkapsulacja i dziedziczenie (przy czym nikt nie twierdzi, że im głębiej tym lepiej), natomiast przesyłanie wiadomości to co najwyżej dodatek. Nie widzę sensu by stosować odmienne interpretacje terminu OOP nawet jeśli sam jego autor protestuje. Jeśli ktoś ceni ideę przesyłania wiadomości między odizolowanymi obiektami to niech mówi o Actor modelu.
Wibowit napisał(a):
Utarło się, że w OOPie główną cechą jest enkapsulacja i dziedziczenie (przy czym nikt nie twierdzi, że im głębiej tym lepiej), natomiast przesyłanie
Enkapsulacja jako wyróżnik OOP? IMHO nie ma w tym żadnej unikatowości, jak ktoś na siłę chce związać enkapsulację z OOP wyjdzie zbyt inkluzywna definicja. Dziedziczenie, jeśli tak to czego? Tu dochodzimy do klas i obiektów. Wśród zowlenników OOPu panuje jakaś mania unikania jak ognia stosowania właśnie pojęcia obiektu i klasy. To taka forma chciwości, żeby jak najwiecej zagarnąć pod swój paradygmat i wbić dumnie flagę zwycięzcy a tak powstały kopiec? Jakby maniacy programowania funkcyjnego pod definicję swego paradygmatu stosowali równie szeroką defiicję, to byśmy w zasadzie mogli pod nią podciągnąś assemblera jako jezyk w którym w zasadzie da się programować funkcyjnie.
Napisałem "enkapsulacja i dziedziczenie" - to jest koniunkcja, a nie alternatywa. Wytłumacz mi w takim razie czym różni się OOP od Actor modelu.
Jakby maniacy programowania funkcyjnego pod definicję swego paradygmatu stosowali równie szeroką defiicję, to byśmy w zasadzie mogli pod nią podciągnąś assemblera jako jezyk w którym w zasadzie da się programować funkcyjnie.
Programowanie funkcyjne opiera się na niemutowalności czyli w zasadzie na braku efektów ubocznych. Dzięki temu na kodzie funkcyjnym można przeprowadzać podobne redukcje co na równaniach matematycznych. Ciężko byłoby takie coś zaimplementować w czystym asemblerze, bo np zwykła instrukcja powoduje efekt uboczny. W kodzie czysto funkcyjnym istnieją tylko stałe, nie ma żadnych zmiennych.
OOP to sprawdzone i działające rozwiązanie zapakowane w jedną paczkę.
Tak w assemblerze da się programować OOP, funkcyjnie i co tam wymyślisz.
OOP leczy raka i jest stosowane nagminnie.
Pokaż mi ten kod funkcyjny w asemblerze.
Dla ułatwienia podam ci kod w C++ który nie jest funkcyjny:
int x = 5;
x++; // tutaj zmieniamy zawartość pola, więc powodujemy skutek uboczny, który w programowaniu funkcyjnym jest zakazany
Wibowit napisał(a):
Dla ułatwienia podam ci kod w C++ który nie jest funkcyjny:
int x = 5; x++; // tutaj zmieniamy zawartość pola, więc powodujemy skutek uboczny, który w programowaniu funkcyjnym jest zakazany
Wystarczy tego nie używać i wtedy się nie złamie zasady :)
Jakie proste rozwiązanie, a jakie skuteczne.
Zaraz pewnie usłyszysz jakieś krzyki, ale ponowię prośbę: podaj jakiś funkcyjny kod asemblerowy.