Co sądzisz o OOP?

Ogromnie Obrzydliwy Paradygmat

Propsy za przemyślaną ankietę 👍🏻

Ja nigdy nie rozumiem o co chodzi z tym OOP.

W C++ dodali struktury tak, że metody są przyczepione do struktury i nie trzeba szukać.
Ja lubię OOP nie wiem czy o to chodzi, ale dobrze jest jak masz MemoryManagment i po prostu jakaś klasa odpowiada za to, lubię struktrualnie pisać, ale jak jest kod ładnie upakowany edytor umie podpowiadać bo jak są struktury to nie umie, ale od c++ struktura === klasa, a na poziomie assemblera to i tak zawsze było tym samym, nigdy nie było różnicy tylko łatwiej idzie tym zarządzać.

W C++ struktura i klasa czyli obiekt jak się utworzy z tej klasy jest tym samym, edytor czyli language server umie podpowiadać dobrze jak wie, że dane są ze sobą ściśle powiązane czyli jak w obiekcie.
W C++ struktura też może mieć metody jak w obiekcie czyli edytor możę łatwo przewidywać jakie funkcje dla danej struktury możesz użyć.

.GodOfCode. napisał(a):

language server umie podpowiadać dobrze jak wie, że dane są ze sobą ściśle powiązane czyli jak w obiekcie.

Language server to protokoł, a nie coś absolutnego. Jeśli istniejąca do danego języka implementacja language servera jest słaba, to można zrobić lepszą.

W C++ struktura też może mieć metody jak w obiekcie czyli edytor możę łatwo przewidywać jakie funkcje dla danej struktury możesz użyć.

Tutaj trzeba spojrzeć szerzej. To, o czym piszesz, to ograniczenia toolingu, a nie paradygmatu.

Pisząc w C++ jesteś ograniczony składnią C++, która wywiera wpływ na to, jak to jest dalej parsowane i jak dobry masz tooling. Być może w innym, bardziej statycznie typowanym, języku będziesz mieć lepszy tooling.

Chyba, że mówisz po prostu o tym, że klasa jest przestrzenią nazw i dając foo. już wiadomo, że trzeba podpowiedzieć coś związanego z foo. a nie totalnie wszystko. Ale... dla mnie to jest zagadnienie poboczne do całego paradygmatu. W programowaniu proceduralnym też możesz mieć przestrzenie nazw.

Czy DDD jest oparte na OOP? DDD też nie lubimy?

krsp napisał(a):

Czy DDD jest oparte na OOP? DDD też nie lubimy?

DDD to dopiero naprawdę nie lubimy, OOP przy tym to pestka.

krsp napisał(a):

Czy DDD jest oparte na OOP?

Nie. DDD to zestaw wzorców i praktyk, nie implementacji. Strategiczne DDD nie ma nic wspólnego z kodem. W taktycznym DDD nie ma znaczenia w jakim paradygmacie piszesz agregaty, value objecty czy encje. Jak poszukasz to znajdziesz przykłady implementacji DDD w językach funkcyjnych, bo DDD to sposób myślenia o architekturze aplikacji, nie konkretnej technologii czy metodyce programowania.

Po co wymyślać coś nowego skoro klienci i tak kupią więcej RAMu, żeby program mógł przerzucać ogromnymi obiektami xd.

Czitels napisał(a):

Po co wymyślać coś nowego skoro klienci i tak kupią więcej RAMu, żeby program mógł przerzucać ogromnymi obiektami xd.

Jeśli jakoś przespałeś ostatnie kilka lat to mały update - obecnie rzadko kiedy klienci kupują RAM. Wynajmują sobie, a nawet to my im wynajmujemy - żeby nie musieli się martwić.
1.5 terabajta wystarczy każdemu.

W Javie mam wrażenie iż nigdy OOP nie pyknął. JEE i a później Spring promowały anemiczny model dziedziny, encje i serwisy, później encje i serwisy bezstanowe. Z OOP ma to tylko tyle wspólnego iż serwisy mają często interfejs. Jakby w Javie zakazano dziedziczyć po klasach to pewnie by w 75% projektów nie zauważyli. A przecież od razu widać iż encje i serwisy to już prawie, w zasadzie rekordy i modułu z funkcjami. A więc enterprisowym projektom javowym bliżej do FP niż do OOP. Może jakbym został C#powcem to bym zrozumiał OOP, ale tak to nie mialem potrzeby

UPDATE w javie jedyne OOP jakie spotkałem to to iż trzeba umieć recytować SOLID na rekrutacjach. Nie wiem po co, ale tech liderzy Javy lubią słuchać recytacji SOLID

OOP to najbardziej wpływowy zbiór konceptów dot. modelowania fragmentów świata rzeczywistego za pomocą języków programowania.

Umożliwił on przez ostatnie dekady milionom programistów wykonanie cyfrowej transformacji i przeniesienie wielu procesów w świat komputerów m.in ze względu na swoją prostotę i łatwość mapowania konceptów rzeczywistych z ich cyfrowym modelem (oczywiście w 99% uproszczonym modelem).

OOP jak każdy inny paradygmat może być różnie interpretowany, dlatego widzimy różnice w OOPie pomiędzy różnymi językami programowania implementującymi w różnym stopniu ten paradygmat (np. C++owy friend).

Czy krytyka OOP jest zasadna? uważam że nie do końca, OOP ma swoje wady np. zbyt duże pchanie się w koncepty dziedziczenia którymi łatwo sobie zrobić krzywdę, jednakże koniec końców wyszedł na PLUS dla świata.

Nagonka na OOP bardziej wygląda tak, że kilku hipsterów naczytało się na 4p dwóch czy trzech pozytywnych postów o innych paradygmatach, o których zapomnieli 2 flaszki po zaliczonej kartkówce z "Paradygmatów programowania" w koledżu, ale teraz chcą się pobrandzlować :D

Zacznijmy od tego że dwadzieścia osób kiedy mówi o OOP to ma na myśli różne rzeczy. Geneza , zaszłośc historyczne, osobiste uprzedzenia , dopowiedzenia.

Rozmowa o tym bez jakichś konkretnych określeń o czym mowa - nie ma sensu.

Riddle napisał(a):

Rozmowa o tym bez jakichś konkretnych określeń o czym mowa - nie ma sensu.

A teraz skandujemy - Definicja, definicja, definicja!

Z takimi tematami jest jak z magia. Magik przybywa do firmy aby prawic prawdy objawione, wszyscy kiwaja glowami, a po szkoleniu wracamy do tego, co bylo.

KamilAdam napisał(a):

Riddle napisał(a):

Rozmowa o tym bez jakichś konkretnych określeń o czym mowa - nie ma sensu.

A teraz skandujemy - Definicja, definicja, definicja!

Nie chodzi mi o definicję, tylko o jakieś przekonanie że mówimy o tym samym.

Wyobrażam sobie że jak ktoś używa określenia "OOP", to zależnie od swojej wiedzy, umiejętności, i tego się uczył może mieć na myśli, paradygmat, ale może ten paradygmat rozumieć różnorako, np.:

• Może to rozumieć tak, że po prostu otwiera projekt, widzi same klasy i myśli: "o, to jest OOP"
• Może to rozumieć jak Robert Martin, że OOP to jest "dyscyplina nałożona na niebezpośredni transfer kontroli"
• Może mieć w głowie slogany: enkapsulacja, dziedziczenie, polimorfizm
• Może to rozumieć przez pryzmat języków Java i C# gdzie (przynajmniej we wczesnych wersjach) kod dało się tylko pisać jako członek klasy
• Może po prostu woleć pisać class niż function, i twierdzi że to jest OOP
• Może myśleć o milionie wzorców, dekoratory, kompozyt, etc.
• Może na to patrzeć przez pryzmat tych dziwnych relacji is-a, has-a
• Może utożsamia OOP z interfejsami z javy które potem poszły na inne języki (i twierdzi że jak jest interface to jest to polimorfizm, a duck-typing już polimorfizmem nie jest).
• Jeszcze inni mogą myśleć że OOP jest tylko wtedy kiedy wystąpi słowo class w kodzie, a jeśli zrobimy np funkcje w JS która zwraca dictinoary z domknięciami to już obiektem nie jest (bo jest function zamiat class).
• Może do tego podchodzić niskopoziomowo, i rozumieć to tak że obiekt to jest cokolwiek co żyje na stercie.
• Może na to patrzeć że dziedziczenie da się załatwić strukturami, a enkapsulację funkcjami, więc jedyne co wnosi OOP "nowego" to jest polimorfizm (z tą różnicą że polimorfizm da się też ogarnąć anonimowymi funkcjami które zacierają granice między obiektem i funkcją).

Nie mówiąc o tym że ktoś może mieć milion uprzedzeń i naleciałości. Ja osobiście uważam że tylko ostatnia pozycja jest prawdziwa, a pozostałe nie; ale to jest moja opinia. Inni mogą mieć inne.

Więc moim zdaniem ta dyskusja nie ma sensu, bez sprecyzowania o "które" OOP chodzi. Określenie OOP jest bardzo popularne, i ludzie bardzo łatwo lubią podpinać swoje przekonania pod taki popularny banner.

dr.hard napisał(a):

Z takimi tematami jest jak z magia. Magik przybywa do firmy aby prawic prawdy objawione, wszyscy kiwaja glowami, a po szkoleniu wracamy do tego, co bylo.

To jest dość życiowe xd Szczególnie na tych wszystkich szkoleniach z wzorców, wielowątkowości itd.

OOP to rozmyte podejście, które w sumie nie oznacza nic przez to, że OOP jest wszędzie. Idąc od najbardziej (według mnie) oczywistości do bardziej kontrowersyjnych:

• OOP to paradygmat, który ułatwia łatwe łączenie kodu z danymi. Takie coś da się osiągnąć w każdym języku. Najlepszym przykładem są generyczne struktury danych, które mają złożony stan wewnętrzny, który musi być modyfikowany i czytany w określony sposób. Niezależnie od paradygmatu czy to imperatywny czy funkcyjny: enkapsulacja i wyznaczone funkcje do czytania/modyfikowania to konieczność
• OOP to paradygmat, który pozwala na jakikolwiek polimorfizm pod postacią jakiegoś interfejsu. Takie coś mamy w praktycznie każdym nowoczesnym języku. Haskell pozwala na statyczny polimorfizm. Dobrym kontr przykładem jest C, który pozwala na polimorfizm dynamiczny (poprzez strukturę zawierającą wskaźniki do funkcji), ale jest to nie wygodne, więc to może być argument, że C nie jest OOP
• OOP to paradygmat z enkapsulacją, Enkapsulacja IMO jest dobra dla dowolnego bytu czy to klasa, struktura czy pojedyncza funkcja, więc odrzucam ten argument
• OOP to paradygmat, która ma dynamiczny polimorfizm. Argumentem przeciwnym jest to, że możemy bardzo łatwo zamienić taki dynamiczny polimorfizm na statyczny i według mnie nie stracimy magii OOP. Dobrym przykładem jest Rust, gdzie bardzo łatwo żonglować jednym i drugim rodzajem według potrzeb
• OOP to język, który ma klasy. Dobrym kont przykładem jest Go, gdzie metody i interfejsy możemy podpiąc pod każdy typ. Choć najczęściej są tą rzeczywiście struktury, to da się napisać kod, wyglądający jak OOP, używać polimorfizmu i nie
• OOP to paradygmat, który ma dziedziczenie. Według mnie to nie prawda, bo każdy przykład dziedziczenia można zamienić na interfejs + kompozycja (punkt 2), gdzie popularnym stwierdzeniem jest to, że taka konstrukcja jest po prostu lepsza z wielu różnych powodów: większa rozszerzalność, lepsza enkapsulacja, bardziej eleganckie z uwagi na użycie mniejszej ilości ficzerów języka
• OOP to paradygmat, który means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. Mało języków wspiera taki paradygmat, bo extreme late-binding i messaging sprawiają, że taka implementacja jest wolna i dynamicznie typowana a w dzisiejszych czasach bardzo kładziemy na wydajność i statyczną poprawność programu

Moja opinia: zgadzam się w 100% tylko z dwoma pierwszymi punktami. Niestety (albo stety) każdy nowoczesny język według tej wykładni jest OOP.

Wydaje mi się, że język, które ewoluuje zgodnie z tradycją OOP jest OOP cokolwiek to miałoby znaczyć. Ewolucja w każdej dziedzinie nie wyklucza radykalnych zmian, które mogą sprawić, że następca jest dalej od oryginału niż mogłoby się to wydawać na pierwszy rzut oka. Pies i delfin są dużo bardziej zgodni genetycznie, ale delfin swoim stylem życia i przystowaniem bardziej przypomina rybę z uwagi na to jak zadziałała ewolucja w tym konkretnym przypadku

WeiXiao napisał(a):

OOP to najbardziej wpływowy zbiór konceptów dot. modelowania fragmentów świata rzeczywistego

Skończyłem czytać w tym miejscu.

Satanistyczny Awatar napisał(a):

WeiXiao napisał(a):

OOP to najbardziej wpływowy zbiór konceptów dot. modelowania fragmentów świata rzeczywistego

Skończyłem czytać w tym miejscu.

cuz? paradygmat zbiera do kupy koncepty, te koncepty są implementowane przez języki jako takie "basic primitives", które następnie są używane do modelowania problemów/fragmentów świata przez programistów.

Allegro/ebay, uber, tinder, stock market, facebook, etc... To wszystko to koncepty/procesy/zjawiska które zostały w jakimś stopniu przeniesione z świata rzeczywistego do komputera, poprzez ich zamodelowanie.

Piękna sprawa i tyle. Nie mielibyście gdzie narzekać gdy nie OOP.

Co to do (...) jest OOP? To jedno z najbardziej rozmytych określeń w programowaniu, każdy rozumie przez nie co innego. Chyba OOP jest jeszcze bardziej wieloznaczne niz FP, a już samo FP, wbrew pozorom, ma wiele defnicji.

MOIM ZDANIEM najbardziej użyteczna definicja OOP byłaby chyba taka: Jest to paradygmat zdefiniowany przez klasyków takich jak Martin, Fowler, Feathers, Beck, Cohn, etc, i ich książki takie jak Clean Code, Clean Architecture, Working Effectively with Legacy Code, etc. Im bliżej jesteśmy zaleceń zawartych w tych książkach, tym bardziej OOP jest nasz kod.

Wydaje mi się, że taka definicja byłaby dostatecznie blisko tego, co większość ludzi intuicyjnie rozumie przez OOP.

@YetAnohterone

czemu akurat ich? to jakiś contest influencerów i ewangelistów? :D

WeiXiao napisał(a):

@YetAnohterone

czemu akurat ich? to jakiś contest influencerów i ewangelistów? :D

Bo wydaje mi się, że ludzie zazwyczaj własnie od nich czerpią pomysły, jak powinien wyglądać kod OOP. Z kolei pomysły inne niż te przedstawiane przez przeze mnie wymienionych influencerów zazwyczaj nie są uważane za OOP. Na przykład clean architecture jest powszechnie uważany za OOP, podczas gdy konkurencyjny vertical slice już raczej nie jest uważany za OOP i raczej jest po części na fali oporu przeciwko OOP.

Zresztą influencerzy przeze mnie wymienieni chyba stworzyli wspólnie dość spójną 'szkołę' programowania, swego czasu cytowali się wzajemnie dość sporo.

Again nie chodziło mi o definicję, która z jakiegoś teoretycznego, purystycznego punktu widzenia byłaby najsensowniejsza. Ile raczej o to, jak można w maks kilku zdaniach streścić, co wydaje mi się, że ludzie zazwyczaj za OOP uważają. A wydaje mi się, że ludzie za OOP uważają to, co jest w tamtych książkach.

YetAnohterone napisał(a):

Zresztą influencerzy przeze mnie wymienieni chyba stworzyli wspólnie dość spójną 'szkołę' programowania, swego czasu cytowali się wzajemnie dość sporo.

Usilowalem sluchac / ogladac krajowych influencerow branzowych. Jedni uzywaja takiego jezyka ktorego nie da sie zwyczajnie sluchac. Drudzy robia z siebie guru po to aby sprzedawac szkolenia dla ulicy czy chodzic po firmach i mowic z wiezy jak rozwiazac rozne problemy bez wnikania w detale ktore badz co badz maja spore znaczenie.

OOP jest jak im pasuje. Jak im nie pasuje to wtedy nie jest OOP.