Czy OOP jest trudne, ponieważ nie jest naturalne?

86

Często można usłyszeć, że OOP naturalnie odpowiada temu, jak ludzie myślą o świecie. Ale zdecydowanie nie zgodziłbym się z tym stwierdzeniem: my (lub przynajmniej ja) konceptualizujemy świat w kategoriach relacji między rzeczami, które napotykamy, ale OOP koncentruje się na projektowaniu poszczególnych klas i ich hierarchii.

Zauważ, że w życiu codziennym relacje i działania istnieją głównie między obiektami, które byłyby instancjami niepowiązanych klas w OOP. Przykładami takich relacji są: „mój ekran jest na stole”; „Ja (człowiek) siedzę na krześle”; „samochód jest w drodze”; „Piszę na klawiaturze”; „ekspres do kawy gotuje wodę”, „tekst jest wyświetlany w oknie terminala”.

Myślimy w kategoriach czasowników dwuwartościowych (czasami trójwartościowych, jak na przykład w „Dałem ci kwiaty”), gdzie czasownik jest działaniem (relacją), która działa na dwóch obiektach w celu uzyskania pewnego wyniku / działania. Skupić się na działaniu, a dwa (lub trzy) [gramatyczne] obiekty mają jednakową wagę.

Porównaj to z OOP, gdzie najpierw musisz znaleźć jeden obiekt (rzeczownik) i powiedzieć mu, aby wykonał jakąś akcję na innym obiekcie. Sposób myślenia jest przenoszony z czynności / czasowników działających na rzeczownikach na rzeczowniki działające na rzeczownikach - to tak, jakby wszystko mówiono głosem pasywnym lub zwrotnym, np. „Tekst jest wyświetlany w oknie terminala”. A może „tekst rysuje się w oknie terminala”.

Nie tylko skupiono się na rzeczownikach, ale także na jednym z rzeczowników (nazwijmy to podmiotem gramatycznym) przypisuje się większą „wagę” niż drugiemu (obiektowi gramatycznemu). Dlatego należy zdecydować, czy powiesz terminalWindow.show (someText) czy someText.show (terminalWindow). Ale po co obciążać ludzi tak trywialnymi decyzjami bez żadnych konsekwencji operacyjnych, skoro naprawdę oznacza się show (terminalWindow, someText)? [Konsekwencje są nieistotne operacyjnie - w obu przypadkach tekst jest wyświetlany w oknie terminala - ale mogą być bardzo poważne w projektowaniu hierarchii klas, a „zły” wybór może prowadzić do zawiłego i trudnego do utrzymania kodu.]

Dlatego argumentowałbym, że główny nurt robienia OOP (oparty na klasach, single-dispatch) jest trudny, ponieważ JEST NIENATURALNY i nie odpowiada poglądom ludzi na temat świata. Ogólne metody CLOS są bliżej mojego sposobu myślenia, ale niestety nie jest to powszechne podejście.

Biorąc pod uwagę te problemy, w jaki sposób / dlaczego tak się stało, że obecnie popularny sposób wykonywania OOP stał się tak popularny? Co można zrobić, aby zdetronizować to?

zvrba
źródło
OOP służy do „programowania”, jest przeznaczony dla kompilatorów. nie jest to sposób na modelowanie realnego świata w jakikolwiek sposób. Podczas nauczania OOP często używa się przykładów ze świata rzeczywistego, takich jak klasa zwierząt i klasa prostokątna, ale są to tylko przykłady upraszczające koncepcje. Niestety język programowania i paradygmaty „dzieją się” w sposób nie ewolucyjny i nienaukowy. Z nielicznymi wyjątkami proces projektowania języka jest zwykle dzieckiem, na które zgaduje niewiele osób!
NoChance,
3
Nie zgodziłbym się z twierdzeniem, że „OOP koncentruje się na projektowaniu poszczególnych klas i ich hierarchii”. od czasu maybie jest to centrum pewnych implementacji OOP, ale na przykład odkryłem, że dynamiczne języki OOP zwykle nie mają dużych hierarchii, a nawet klas. Cóż, definicja OOP może się zmienić w przyszłości, jest próba zmiany nawet obiektu 1 wcook.blogspot.com/2012/07/proposal-for-simplified-modern.html
Azder
1
OOP identyfikuje obiekty w systemie i konstruuje klasy na podstawie tych obiektów. Nie na odwrót. Dlatego też nie zgadzam się z „celem OOP jest projektowanie poszczególnych klas i ich hierarchii”.
Radu Murzea,
1
Myślę, że jest to pytanie bardzo subiektywne i pełne dziwnych założeń na temat OOP i tego, czym jest „prawdziwy świat” i jak ludzie myślą o problemach. I w końcu pyta nawet: „Co można zrobić, aby zdetronizować to?” co naprawdę pokazuje, że PO ma bardzo silną opinię na ten temat. Jeśli jesteś „religijny” w kwestii paradygmatów programowania, myślę, że nie potrzebujesz żadnych odpowiedzi ... już wiesz, co chcesz usłyszeć. Gdybym wiedział o tym pytaniu, kiedy zostało zadane po raz pierwszy, prawdopodobnie głosowałbym za jego zamknięciem ...
Simon Lehmann,

Odpowiedzi:

97

OOP jest nienaturalny w przypadku niektórych problemów. To jest proceduralne. To jest funkcjonalne. Myślę, że OOP ma dwa problemy, które naprawdę sprawiają, że wydaje się to trudne.

  1. Niektórzy zachowują się, jakby to był Jedyny Prawdziwy Sposób Programowania, a wszystkie inne paradygmaty są błędne. IMHO wszyscy powinni używać języka multiparadygmatu i wybrać najlepszy paradygmat dla podproblemu, nad którym aktualnie pracują. Niektóre części kodu będą miały styl OO. Niektóre będą funkcjonalne. Niektóre będą miały prosty styl proceduralny. Z doświadczenia staje się oczywiste, jaki paradygmat jest najlepszy do czego:

    za. OO jest na ogół najlepszy, gdy masz zachowania silnie powiązane ze stanem, w którym działają, a dokładna natura stanu jest szczegółem implementacji, ale jego istnienia nie można łatwo oderwać. Przykład: klasy kolekcji.

    b. Proceduralne jest najlepsze, gdy masz wiele zachowań, które nie są ściśle powiązane z żadnymi konkretnymi danymi. Na przykład może działają na prymitywnych typach danych. Najłatwiej jest tutaj myśleć o zachowaniu i danych jako o osobnych podmiotach. Przykład: kod numeryczny.

    do. Funkcjonalność jest najlepsza, gdy masz coś, co dość łatwo jest napisać deklaratywnie, tak że istnienie dowolnego stanu jest szczegółem implementacji, który można łatwo oderwać. Przykład: Mapuj / zmniejsz równoległość.

  2. OOP ogólnie pokazuje swoją przydatność w dużych projektach, w których dobrze zamknięte dobrze fragmenty kodu są naprawdę konieczne. Nie zdarza się to zbyt często w projektach dla początkujących.

dsimcha
źródło
4
Myślę, że ważną kwestią w tym pytaniu nie było to, czy OOP jest naturalne, ale czy główne podejście do OOP jest najbardziej naturalnym podejściem OOP. (W każdym razie dobra odpowiedź.)
Giorgio
11
„OOP ogólnie pokazuje swoją przydatność w dużych projektach, w których bardzo dobrze zamknięte są dobrze zakodowane fragmenty kodu.”: Ale to nie jest konkretna właściwość OOP, ponieważ istnieją dobre koncepcje modułów również dla imperatywnych, funkcjonalnych, ... języków programowania .
Giorgio
2
OOP jest naprawdę na innej osi niż proceduralna / funkcjonalna; zajmuje się tym, jak organizować i hermetyzować kod, a nie jak opisywać operacje. ( Zawsze współpracujesz z OOP z paradygmatem wykonania. Tak, istnieją OOP + języki funkcjonalne.)
Donal Fellows
1
Czy nie można powiedzieć, że OOP to tylko pudełka, w które wkładamy rzeczy proceduralne?
Erik Reppen,
W OOP nadal możesz pisać metody. Co sprawia, że ​​OOP jest słabszy niż programowanie proceduralne?
Mert Akcakaya
48

IMHO to kwestia osobistego gustu i sposobów myślenia. Nie mam większego problemu z OO.

My (lub przynajmniej ja) konceptualizujemy świat w kategoriach relacji między rzeczami, które napotykamy, ale OOP koncentruje się na projektowaniu poszczególnych klas i ich hierarchii.

IMHO to nie do końca tak, chociaż może to być powszechne postrzeganie. Alan Kay, wynalazca terminu OO, zawsze podkreślał wiadomości przesyłane między obiektami, a nie same obiekty. A wiadomości, przynajmniej dla mnie, oznaczają relacje.

Zauważ, że w życiu codziennym relacje i działania istnieją głównie między obiektami, które byłyby instancjami niepowiązanych klas w OOP.

Jeśli istnieje związek między obiektami, to są one powiązane zgodnie z definicją. W OO można wyrazić to za pomocą powiązania / agregacji / użycia między dwiema klasami.

Myślimy w kategoriach czasowników dwuwartościowych (czasami trójwartościowych, jak na przykład w „Dałem ci kwiaty”), gdzie czasownik jest działaniem (relacją), która działa na dwóch obiektach w celu uzyskania pewnego wyniku / działania. Nacisk kładziony jest na działanie, a dwa (lub trzy) [gramatyczne] obiekty mają równe znaczenie.

Ale nadal mają swoje dobrze zdefiniowane role w kontekście: temat, przedmiot, działanie itp. „Dałem ci kwiaty” lub „Dałeś mi kwiaty” to nie to samo (nie wspominając już o „Kwiat dał mi”): -)

Porównaj to z OOP, gdzie najpierw musisz znaleźć jeden obiekt (rzeczownik) i powiedzieć mu, aby wykonał jakąś akcję na innym obiekcie. Sposób myślenia jest przenoszony z czynności / czasowników działających na rzeczownikach na rzeczowniki działające na rzeczownikach - to tak, jakby wszystko mówiono głosem pasywnym lub zwrotnym, np. „Tekst jest wyświetlany w oknie terminala”. A może „tekst rysuje się w oknie terminala”.

Nie zgadzam się z tym. IMHO zdanie angielskie „Bill, idź do diabła” brzmi bardziej naturalnie w kodzie programu, jak bill.moveTo(hell)zamiast move(bill, hell). Ten pierwszy jest w rzeczywistości bardziej analogiczny do oryginalnego aktywnego głosu.

Dlatego należy zdecydować, czy powiesz terminalWindow.show (someText) czy someText.show (terminalWindow)

Ponownie, to nie to samo, że poproś terminal o pokazanie tekstu lub poproś o tekst, aby pokazał terminal. IMHO jest całkiem oczywiste, który z nich jest bardziej naturalny.

Biorąc pod uwagę te problemy, w jaki sposób / dlaczego tak się stało, że obecnie popularny sposób wykonywania OOP stał się tak popularny?

Może dlatego, że większość programistów OO widzi OO inaczej niż ty?

Péter Török
źródło
15
+1 za bezpośrednią wzmiankę o wiadomościach między obiektami i ich znaczeniu od Alana Kay
bunglestink
3
@zvrba, rzeczywiście, byli też inni pionierzy OO, ale to nie ma sensu w tej dyskusji. „Najbardziej naturalną rzeczą jest prośba o pokazanie tekstu”. - teraz używasz tego samego pasywnego głosu, który według ciebie jest tak „nienaturalny” w OOP.
Péter Török
5
@zvrba, mówisz „zawsze jest„ agent ”[…] robiąc coś”, ale protestujesz przeciwko podejściu OO polegającemu na identyfikowaniu i nazywaniu tych agentów (obiektów) oraz traktowaniu ich jako obywateli pierwszej klasy w języku . Dla mnie jest to część modelowania problematycznej domeny - i tak musisz to zrobić, po prostu zamapuj wynikowy model domeny na kod w inny sposób, w zależności od tego, czy Twoim językiem jest OO, czy nie.
Péter Török
6
@zvrba, to nie OO per se, ale programista / projektant, który decyduje o rolach i obowiązkach różnych obiektów. Korzystanie z metody OO może dać dobre lub złe modele i projekty domen, podobnie jak użycie noża może dać ci kawałek chleba lub krwawiący palec - nadal nie obwiniamy noża, ponieważ jest to tylko narzędzie. Zauważ też, że koncepcje / obiekty / agenci w modelu są abstrakcjami rzeczy w świecie rzeczywistym i jako takie są zawsze ograniczone i zniekształcone, koncentrując się tylko na określonych „interesujących” aspektach.
Péter Török
6
@ zvrba, samochód rzeczywiście nie uruchamia się z własnej woli - tak jak Carobiekt, gdyby start()ktoś wyraźnie wywołał jego metodę.
Péter Török,
10

Niektórzy programiści uważają OOD za trudny, ponieważ programiści lubią myśleć o tym, jak rozwiązać problem z komputerem, a nie o tym, jak należy go rozwiązać.

... ale OOP koncentruje się na projektowaniu poszczególnych klas i ich hierarchii.

OOD NIE jest o tym. OOD polega na ustaleniu, jak rzeczy się zachowują i wchodzą w interakcje.

Myślimy w kategoriach czasowników dwuwartościowych (czasami trójwartościowych, jak na przykład w „Dałem ci kwiaty”), gdzie czasownik jest działaniem (relacją), która działa na dwóch obiektach w celu uzyskania pewnego wyniku / działania. Nacisk kładziony jest na działanie, a dwa (lub trzy) [gramatyczne] obiekty mają równe znaczenie.

Nacisk na OOD zawsze koncentruje się na działaniu, gdzie działania są zachowaniem obiektów. Przedmioty są niczym bez swoich zachowań. Jedynym ograniczeniem obiektowym OOD jest to, że wszystko musi być przez coś zrobione.

Nie uważam, że wykonawca jest ważniejszy od rzeczy, która coś z tym zrobiła.

Ale po co obciążać ludzi tak trywialnymi decyzjami bez żadnych konsekwencji operacyjnych, skoro naprawdę oznacza się show (terminalWindow, someText)?

Dla mnie to samo z inną notacją. Nadal musisz zdecydować, kto jest show-em, a kto show-ee. Gdy się o tym dowiesz, w OOD nie będzie żadnej decyzji. Windows pokazuje tekst -> Window.Show (tekst).

Wiele rzeczy (szczególnie w obszarze dziedzictwa) mówi, że to OO, kiedy nie jest. Na przykład istnieje ogromna ilość kodu C ++, który nie implementuje fig OOD.

OOD jest łatwe, gdy wyrwiesz się z myślenia, że ​​rozwiązujesz problem z komputerami. Rozwiązujesz problemy dotyczące rzeczy, które robią różne rzeczy.

Matt Ellen
źródło
10
Nie lubię OOD dokładnie, ponieważ wolę myśleć o tym, jak rozwiązać problem, kropka. Nie chcę myśleć o tym, jak przetłumaczyć naturalny język domeny problemowej na obcy świat przedmiotów, wiadomości, dziedziczenia i tak dalej. Nie chcę wymyślać hierarchicznych taksonomii tam, gdzie one naturalnie nie istnieją. Chcę opisać problem w jego naturalnym języku i rozwiązać go w najprostszy możliwy sposób. Nawiasem mówiąc, świat nie składa się tylko z „rzeczy, które robią rzeczy”. Twoje spojrzenie na rzeczywistość jest bardzo wąskie.
SK-logic
7
@Matt Ellen, piszę programy, które modelują zachowanie entites, które nie są „rzeczami” i które „nie robią” żadnych „rzeczy”. Żadna niezmienna istota nic nie robi. Żadna matematyczna czysta funkcja nic nie robi - to tylko odwzorowanie jednego zestawu na inny, a ten świat jest najczęściej opisywany przez takie funkcje. Żaden logiczny formalizm nic nie „robi”. Tak, OOD mi nie pomoże, ponieważ jestem w stanie korzystać z dużo, dużo potężniejszych abstrakcji i modeli. Powrót do prymitywnego, ograniczonego, ograniczającego OOD poważnie mnie utrudni.
SK-logic
2
@Matt Ellen, tak, chciałbym zobaczyć odniesienia, które popierają tak dziwne twierdzenia, że ​​świat jest lepiej postrzegany jako zbiór „rzeczy, które robią rzeczy” lub „obiektów, które wchodzą w interakcje za pośrednictwem wiadomości”. To jest całkowicie nienaturalne. Weź dowolną teorię naukową (ponieważ na tym etapie wszystkie są tak bliskie modelowania świata rzeczywistego), i spróbuj przepisać ją używając terminologii. Rezultat będzie niezdarny i niezręczny.
SK-logic
4
@ Antonio2011a, nie ma jednego paradygmatu programowania lub modelowania, który mógłby skutecznie obejmować wszystkie możliwe domeny problemowe. OOP, funkcjonalność, przepływ danych, logika pierwszego rzędu, cokolwiek innego - wszystkie są paradygmatami specyficznymi dla domeny i niczym więcej. Popieram tylko różnorodność i otwarte podejście do rozwiązywania problemów. Zawężenie myślenia do jednego paradygmatu jest po prostu głupie. Najbliżej uniwersalnego podejścia, które nie ogranicza się do jednego semantycznego frameworku, jest en.wikipedia.org/wiki/Language-oriented_programming
SK-logic
3
@Calmarius dlaczego miałbyś ułatwić programowanie na komputerach? To po prostu głupie. To ludzie muszą wykonać cięższą pracę.
Matt Ellen,
7

Może nie jestem w stanie zrozumieć sensu, ale:

Czytając pierwszą książkę o OOP (wczesne lata 90., cienki podręcznik Borlanda do Pascala) byłem po prostu zaskoczony jej prostotą i potencjałem. (Wcześniej używałem Cobola, Fortranu, asemblera i innych prehistorycznych rzeczy.)

Dla mnie jest całkiem jasne: pies to zwierzę, zwierzę musi jeść, mój pies to pies, więc musi jeść ...

Z drugiej strony samo programowanie jest z natury nienaturalne (tj. Sztuczne). Ludzka mowa jest sztuczna (nie obwiniajcie mnie, wszyscy nauczyliśmy się naszych języków od innych, nikt nie zna osoby, która wynalazła angielski). Według niektórych naukowców ludzki umysł kształtuje język, którego nauczył się pierwszy.

Przyznaję, że niektóre konstrukcje we współczesnych językach OO są nieco niezręczne, ale taka jest ewolucja.

Nerevar
źródło
1
Jaka była twoja praca, aby przejść z kobolu do fortranu, a następnie na montaż (i resztę)?
Gawron
1
Złe zamówienie. Właściwie zacząłem od Basic, potem przeniosłem się do Fortran, a następnie do Assembly i Cobol (tak, jest to prawidłowa kolejność: najpierw montaż). Pierwszym komputerem w moim życiu był „gigantyczny” komputer mainframe, 256 kB pamięci, maszyna do pisania na konsoli, zasilająca go kartami dziurkowanymi, ponieważ byłem jego operatorem. Kiedy dorosłem na tyle, by zostać programistą systemów, podejrzana rzecz o nazwie PC-AT wylądowała na moim biurku. Więc zanurzyłem się w GW-Basic, Turbo-Pascal ... i tak dalej.
Nerevar,
1
Nie miałem na to ochoty. Więcej do Twojej pracy; bo nie znam wielu ludzi (naprawdę), którzy mieli do czynienia z COBOL (zorientowanym na biznes), fortran (dziedzina naukowa), asemblerem (bardziej zorientowanym na cs), a potem z tymi innymi. Niemniej jednak są profesjonalnymi programistami, czy nie.
Wieża
1
Bez tajemnic: dołączanie do zespołów i projektów, w których wcześniej podjęto decyzję o podejściu do języka. I trochę nietrywialny poziom ciekawości na temat używanych narzędzi.
Nerevar
6

Jedną rzeczą, która mi utrudniała, było myślenie, że OOP dotyczy modelowania świata. Pomyślałem, że jeśli nie zrozumiem tego dobrze, coś może przyjść i ugryźć mnie w tyłek (coś jest prawdą albo nie). Byłem bardzo świadomy problemów, które udają, że wszystko jest przedmiotem lub bytem. To sprawiło, że jestem bardzo niepewny i niepewny co do programowania w OOP.

Potem przeczytałem SICP i zrozumiałem, że tak naprawdę chodzi o typy danych i kontrolowanie dostępu do nich. Wszystkie problemy, które rozpuściłem, ponieważ były oparte na fałszywej przesłance, że w OOP modelujesz świat.

Nadal zastanawiam się nad ogromną trudnością, jaką przyniosła mi ta fałszywa przesłanka (i jak się na nią dostrzegam).

Pinochle
źródło
Dziękujemy za zwrócenie uwagi na niebezpieczeństwo związane z modelowaniem świata.
Sean McMillan
4

Tak, sam OOP jest bardzo nienaturalny - prawdziwy świat nie składa się całkowicie z hierarchicznych taksonomii. Niektóre jego małe części są wykonane z tych rzeczy, a te części są jedynymi rzeczami, które można odpowiednio wyrazić w kategoriach OO. Cała reszta nie może naturalnie wpasować się w tak trywialny i ograniczony sposób myślenia. Zobacz nauki przyrodnicze, zobacz, jak wiele różnych języków matematycznych zostało wymyślonych w celu wyrażenia w najprostszy lub przynajmniej zrozumiały sposób złożoności prawdziwego świata. I prawie żadnego z nich nie można łatwo przetłumaczyć na język przedmiotów i wiadomości.

Logika SK
źródło
5
Jest to równie prawdziwe w przypadku każdego rodzaju formalnej notacji, która próbuje precyzyjnie opisać prawdziwy świat.
Péter Török
1
@ Péter Török, dokładnie mój punkt widzenia. Nie ma jednego formalizmu, który obejmowałby wszystko. Musisz użyć ich wszystkich, w całej ich przerażającej rzeszy. I dlatego wierzę w programowanie zorientowane na język - pozwala na przyjęcie różnych, często niekompatybilnych formalizmów w jednolitym kodzie.
SK-logic
1
Wszystko można podzielić na hierarchiczne taksonomie. Sztuczka polega na wymyślaniu schematów, które mają sens. Często wiąże się to z wielokrotnym spadkiem. Duża różnica między oprogramowaniem a światem rzeczywistym polega na tym, że w świecie rzeczywistym często musimy wnioskować lub odkrywać schematy kategoryzacji; w oprogramowaniu wymyślamy je.
Caleb
1
Używając terminu „hierarchiczna taksonomia”, myślę, że myślisz o… dziedziczeniu. Trudno jest uzasadnić dziedziczenie. Dlatego ludzie sugerują stosowanie kompozycji zamiast dziedziczenia.
Frank Shearar
1
@Frank: W świecie rzeczywistym istnieje wiele rodzajów hierarchicznych taksonomii, z których tylko jedno dziedziczenie. Wykonanie tego wszystkiego poprawnie wymaga lepszych narzędzi niż OOP (np. Rozumowanie ontologiczne) i powodowało problemy dla filozofów przez tysiąclecia…
Donal Fellows
4

My (lub przynajmniej ja) konceptualizujemy świat w kategoriach relacji między rzeczami, które napotykamy, ale OOP koncentruje się na projektowaniu poszczególnych klas i ich hierarchii.

Zaczynasz od (IMO) fałszywej przesłanki. Relacje między obiektami są prawdopodobnie ważniejsze niż same obiekty. To relacje tworzą obiektową strukturę programu. Dziedziczenie, związek między klasami, jest oczywiście ważny, ponieważ klasa obiektu określa, co ten obiekt może zrobić. Ale to relacje między poszczególnymi obiektami decydują o tym, co obiekt faktycznie robi w granicach określonych przez klasę, a tym samym o tym, jak program się zachowuje.

Paradygmat zorientowany obiektowo może początkowo być trudny nie dlatego, że trudno wymyślić nowe kategorie obiektów, ale ponieważ trudno jest wyobrazić sobie graf obiektów i zrozumieć, jakie powinny być między nimi relacje, szczególnie gdy nie masz sposób na opisanie tych relacji. Dlatego wzorce projektowe są tak przydatne. Wzory projektowe dotyczą prawie wyłącznie relacji między obiektami. Wzory dają nam zarówno elementy składowe, których możemy użyć do zaprojektowania relacji między obiektami na wyższym poziomie, jak i język, którego możemy użyć do opisania tych relacji.

To samo dotyczy dziedzin kreatywnych, które działają w świecie fizycznym. Każdy może zrzucić kilka pokoi i nazwać to budynkiem. Pokoje mogą być nawet w pełni wyposażone we wszystkie najnowsze wyposażenie, ale to nie oznacza, że ​​budynek działa. Zadaniem architekta jest optymalizacja relacji między tymi pokojami pod kątem wymagań osób korzystających z tych pomieszczeń i otoczenia budynku. Poprawienie tych relacji sprawia, że ​​budynek działa zarówno z perspektywy funkcjonalnej, jak i estetycznej.

Jeśli masz problem z przyzwyczajeniem się do OOP, zachęcam do zastanowienia się nad tym, jak twoje obiekty pasują do siebie i jak są ułożone ich obowiązki. Jeśli jeszcze tego nie zrobiłeś, przeczytaj o wzorach projektowych - prawdopodobnie zdasz sobie sprawę, że już widziałeś wzory, o których czytałeś, ale nadanie im nazw pozwoli zobaczyć nie tylko drzewa, ale także drzewostany, kopie, zarośla, lasy, gaje, zarośla, a ostatecznie lasy.

Caleb
źródło
3

To tylko część tego, co jest nie tak z OOP.

Zasadniczo funkcje stają się obywatelami drugiej kategorii, a to źle.

Współczesne języki (ruby / python) nie mają tego problemu i zapewniają funkcje jako obiekty pierwszej klasy, a także umożliwiają tworzenie programów bez budowania hierarchii klas.

hasen
źródło
OOP wydaje mi się bardzo naturalne, w rzeczywistości trudno mi myśleć o zadaniach programistycznych w jakikolwiek inny sposób. Mimo to z biegiem lat zrozumiałem, że OOP ma tendencję do przeceniania rzeczowników nad czasownikami. Ta reguła z 2006 roku pomogła mi zrozumieć to rozróżnienie: steve-yegge.blogspot.com/2006/03/…
Jim In Texas
3

OOP nie jest trudne. To, co utrudnia korzystanie z tego dobrze, to płytkie zrozumienie, po co jest dobre, w którym programiści słyszą losowe maksymy i powtarzają je sobie pod nosem, aby otrzymać błogosławieństwa boskiego Gangu Czterech, błogosławionego Martina Fowlera lub ktokolwiek jeszcze czytał.

Marcin
źródło
3

EDYTOWANE

Przede wszystkim chciałbym powiedzieć, że nigdy nie uważałem OOP za trudny ani trudniejszy niż inne paradygmaty programowania. Programowanie jest z natury trudne, ponieważ próbuje rozwiązać problemy ze świata rzeczywistego, a świat rzeczywisty jest niezwykle złożony. Z drugiej strony, kiedy czytam to pytanie, zadaję sobie pytanie: Czy OOP jest „bardziej naturalne” niż inne paradygmaty? A zatem bardziej skuteczny?

Kiedyś znalazłem artykuł (chciałbym móc go znaleźć ponownie, aby móc go opublikować jako odniesienie) na temat badania porównawczego między programowaniem imperatywnym (IP) a programowaniem obiektowym (OOP). W zasadzie zmierzyli produktywność profesjonalnych programistów używających IP i OOP w różnych projektach, w wyniku czego nie zauważyli dużych różnic. Twierdzeniem było więc, że nie było dużej różnicy w wydajności między obiema grupami, a to, co naprawdę się liczy, to doświadczenie.

Z drugiej strony zwolennicy orientacji obiektowej twierdzą, że chociaż podczas wczesnego rozwoju systemu OOP może nawet zająć więcej czasu niż jest to konieczne, w dłuższej perspektywie kod jest łatwiejszy do utrzymania i rozszerzenia dzięki ścisłej integracji danych z operacje.

Pracowałem głównie z językami OOP (C ++, Java), ale często mam wrażenie, że mogę być tak produktywny, używając Pascala lub Ady, chociaż nigdy nie wypróbowałem ich dla dużych projektów.

Porównaj to z OOP, gdzie najpierw musisz znaleźć jeden obiekt (rzeczownik) i powiedzieć mu, aby wykonał jakąś akcję na innym obiekcie.

[kroić]

Dlatego argumentowałbym, że główny nurt robienia OOP (oparty na klasach, single-dispatch) jest trudny, ponieważ JEST NIENATURALNY i nie odpowiada poglądom ludzi na temat świata. Ogólne metody CLOS są bliżej mojego sposobu myślenia, ale niestety nie jest to powszechne podejście.

Kiedy uważniej przeczytałem ten ostatni akapit, w końcu zrozumiałem główny punkt twojego pytania i musiałem przepisać swoją odpowiedź od nowa. :-)

Znam inne propozycje OO, w których wiele obiektów otrzymuje wiadomość zamiast tylko jednego, tj. Kilka obiektów odgrywa symetryczną rolę podczas odbierania wiadomości. TAK, wydaje mi się to bardziej ogólne i może bardziej naturalne (mniej restrykcyjne) podejście do OOP.

Z drugiej strony „wielokrotną wysyłkę” można łatwo zasymulować za pomocą „pojedynczej wysyłki”, a „pojedynczą wysyłkę” można łatwiej wdrożyć. Być może jest to jeden z powodów, dla których „wielokrotna wysyłka” nie stała się głównym nurtem.

Giorgio
źródło
3

Przestań szukać wyłącznie paradygmatu OOP i wypróbuj JavaScript.

Obecnie mam opracowany schemat, w którym moje obiekty interfejsu użytkownika działają w interfejsie sterowanym zdarzeniami. To znaczy, będę miał coś, co wygląda jak typowa metoda publiczna, która po uruchomieniu powoduje wewnętrznie zdefiniowane działanie. Ale kiedy zostanie zwolniony, tak naprawdę dzieje się tak, że wyzwalam zdarzenie na samym obiekcie, a wstępnie zdefiniowany moduł obsługi w tym obiekcie reaguje. To zdarzenie i obiekt zdarzenia, do którego można dołączyć właściwości, które są przekazywane do dowolnego innego detektora, mogą być słyszalne przez wszystko, co chce słuchać. Możesz słuchać bezpośrednio do obiektu lub możesz ogólnie słuchać tego typu zdarzenia (zdarzenia są również wyzwalane na obiekcie ogólnym, którego mogą słuchać wszystkie obiekty zbudowane przez fabrykę). Na przykład teraz mam pole kombi, w którym wybierasz nowy element z listy rozwijanej.

Jeśli chcesz (i byłem zaskoczony odkryciem, że zwykle tego nie chcę - to problem czytelności, gdy nie widzisz, skąd pochodzi zdarzenie), możesz mieć całkowite oddzielenie obiektu i ustalić kontekst za pośrednictwem obiektu zdarzenia przekazanego. Niezależnie od tego nadal unikasz pojedynczej wysyłki, ponieważ możesz zarejestrować wielu respondentów.

Ale nie robię tego z samym OOP, a JS nie jest nawet „właściwie” OOP według niektórych definicji, które uważam za zabawne. Moim zdaniem, dla wyższych poziomów rozwoju aplikacji, jest odpowiednia zdolność do zginania paradygmatu w zależności od sytuacji i możemy naśladować klasy, jeśli nam zależy. Ale w tym przypadku łączę aspekty funkcjonalności (omijanie modułów obsługi) z OOP.

Co ważniejsze, to, co mam, wydaje się dość potężne. Nie myślę w kategoriach jednego obiektu działającego na inny. Zasadniczo decyduję, o co dbają te obiekty, dając im narzędzia, których potrzebują do uporządkowania rzeczy, po prostu wrzucając je do miksera i pozwalając im reagować na siebie.

Myślę więc, że to, co mówię, to: nie jest to problem z instrukcją przełączania. Wymieszaj i dopasuj. Problemem są języki i mody, które chcą, abyś wierzył, że to jedno, co uber alles. Jak na przykład młodszy programista Java może naprawdę docenić OOP, gdy myśli, że zawsze robi to właściwie domyślnie?

Erik Reppen
źródło
2

Wyjaśniono mi toster i samochód. Obie mają sprężyny, więc miałbyś obiekt „sprężynowy” i miałyby różne rozmiary, siły i cokolwiek innego, ale oba byłyby „sprężynami”, a następnie rozciągałyby tę metaforę na samochód, gdybyś miał dużo kół (Koła oczywiście plus kierownica itp.) I to miało sens.

Następnie możesz myśleć o programie jako o liście obiektów, a wizualizacja jest o wiele prostsza: „To lista rzeczy, które robią różne rzeczy, więc nie jest to lista instrukcji, którą widziałeś wcześniej”

Myślę, że prawdziwym problemem związanym z OOP jest sposób, w jaki wyjaśnia się go ludziom. Często (w moich klasach uni) widzę, jak to tłumaczy się, mówiąc: „chodzi o wiele klas, które robią małe rzeczy i można z nich tworzyć przedmioty” i wszystko to dezorientuje wielu ludzi, ponieważ używa tego, co jest zasadniczo abstrakcyjne terminy wyjaśniające te pojęcia, a nie konkretne pomysły, które ludzie zrozumieli, gdy mieli 5 lat i bawili się klockami lego.

Trezoid
źródło
2
Sprężyny występują w milionach form, z których wszystkie spełniają podobne funkcje . Powiedziałbym, że jest to doskonały przykład programowania funkcjonalnego.
l0b0
2

To naturalny sposób myślenia o świecie poprzez kategoryzację. Mniej więcej o to chodzi w OO. OOP jest trudne, ponieważ programowanie jest trudne.

Tom Hawtin - tackline
źródło
Ale czy kategoryzujesz według tego, czy niektóre obiekty mają wspólne atrybuty, czy wspólne zachowania? Czy wszystko, co ma imię i nazwisko, to osoba? Czy wszystko, co chodzi ze zwierzęciem?
zvrba
Jeśli chodzi o kategoryzację, umiejętność wykonania określonego zachowania jest atrybutem. Zebry i konie mogą się rozmnażać, ale potomstwo jest hybrydą. Bardzo trudno jest przewidzieć ten wynik na podstawie funkcji kojarzenia, chyba że wiesz, że nie są to te same gatunki.
JeffO
1
@zvrba: Oto moja odpowiedź na pytanie postawione w komentarzu it doesn't matter. Wszystko, co ma imię i nazwisko, jest osobą w każdym programie, który troszczy się tylko o ludzi. Dla każdego programu, który nie ma wiedzy o ludziach lub nie-ludziach, jest to IHasNameAndSurname. Przedmioty muszą jedynie rozwiązać dany problem.
Tom W
@Jeff O Nawet w obrębie tego samego gatunku / rasy / populacji występuje zmienność i nie ma idealnego (niezbędnego) przykładu. Tak, tak, OO nie jest tak jak natura, ale dobrze pasuje do tego, jak ludzie myślą w naturalny sposób.
Tom Hawtin - tackline
2

Myślę, że niektóre trudności pojawiają się, gdy ludzie próbują używać OOP do reprezentowania rzeczywistości. Wszyscy wiedzą, że samochód ma cztery koła i silnik. Każdy wie, że samochody mogą Start(), Move()i SoundHorn().

W mojej głowie zapaliło się światło, gdy zdałem sobie sprawę, że powinienem przestać próbować to robić cały czas. Obiekt nie jest tym, z czym ma wspólną nazwę. Przedmiotem jest (tzn. Powinien być) wystarczająco szczegółowy podział danych odpowiedni dla zakresu problemu. To oughtdokładnie to, czego rozwiązanie problemu musi go mieć, nie więcej i nie mniej. Jeśli uczynienie obiektu odpowiedzialnym za pewne zachowanie spowoduje powstanie większej liczby wierszy kodu niż to samo zachowanie, które jest zadaniem jakiegoś mglistego podmiotu trzeciego (niektórzy mogą nazwać go „poltergeist”), wtedy poltergeist zarabia na swoich chipach.

Tom W.
źródło
1

Aby zarządzać złożonością, musimy pogrupować funkcjonalność w moduły, co jest ogólnie trudnym problemem. To jak stare powiedzenie o kapitalizmie, OOP to najgorszy system do organizowania oprogramowania, z wyjątkiem wszystkiego, co próbowaliśmy.

Powodem, dla którego grupujemy interakcje w obrębie rzeczowników, nawet jeśli często jest dwuznaczność co do tego, z którym z dwóch rzeczowników się je grupuje, jest to, że ilość rzeczowników przypada na klasy o zarządzalnych rozmiarach, podczas gdy grupowanie według czasowników zwykle powoduje albo bardzo małe grupy takie jak jednorazowe lub bardzo duże grupy dla funkcji takiej jak show . Pojęcia wielokrotnego użytku, takie jak dziedziczenie, również działają znacznie łatwiej, gdy pogrupowane są według rzeczowników.

Również kwestia decydowania o tym, czy pokazać program z oknem, czy z tekstem, jest prawie zawsze znacznie bardziej wyraźna w praktyce niż w teorii. Na przykład prawie wszystkie grupy narzędzi GUI dodają się do kontenera, ale pokazują go za pomocą widżetu. Jeśli spróbujesz napisać kod w drugą stronę, przyczyna stanie się dość szybko widoczna, nawet pomimo abstrakcyjnego myślenia, te dwie metody wydają się zamienne.

Karl Bielefeldt
źródło
2
Czy kiedykolwiek widziałeś odpowiedni system modułów? Jak możesz powiedzieć, że OOP jest najlepszą dostępną rzeczą? Moduły SML są znacznie, znacznie bardziej wydajne. Ale nawet pakiety Ada wystarczą w większości przypadków, nawet bez odrobiny OOP.
SK-logic
@ SK-logic, myślę, że wiesz się na zbyt precyzyjnych definicjach. Przez OOP nie mam na myśli klas , mam na myśli logiczne grupowanie „czasowników” według „rzeczowników”, na których działają, oraz możliwość ponownego użycia i specjalizacji tych czasowników na podstawie konkretnych rzeczowników, na których operują. Klasy są najbardziej znaną implementacją tego, ale nie są jedyną implementacją. Przyznaję się do nieznajomości modułów SML, ale pierwszym przykładem, który zobaczyłem, gdy spojrzałem w górę, była implementacja kolejki, która mogła pochodzić z dowolnej książki projektowej OO ze zmianami składni, aby była funkcjonalna.
Karl Bielefeldt
po prostu niesprawiedliwe byłoby przyznanie niefortunnemu OOP zbyt dużego uznania za coś, co do niego nie należy. Moduły to świetny wynalazek. Pierwszej klasy moduły są fantastyczne. Ale OOP nie ma z nimi nic wspólnego. Niektóre języki OOP przyjęły niektóre funkcje modułu (w szczególności - przestrzenie nazw), ale moduły są znacznie bardziej ogólną i potężną koncepcją niż klasy. Powiedziałeś, że klasy są „najlepsze”, co jest dalekie od prawdy. Pierwszej klasy moduły są znacznie lepsze. I oczywiście systemy typów są znacznie szersze i głębsze niż tylko OO z jego podtytułem.
SK-logic
1
„To jak stare powiedzenie o kapitalizmie, OOP to najgorszy system do organizacji oprogramowania, z wyjątkiem wszystkiego, co próbowaliśmy.”: Może nie próbowaliśmy wystarczająco długo. :-)
Giorgio
1
Myślę, że masz na myśli „demokrację”: quotationspage.com/quote/364.html
nicodemus13
1

Nie . Istnieje kilka sposobów rozwiązania problemu za pomocą programowania: funkcjonalne, proceduralne, logiczne, OOP, inne.

W prawdziwym świecie czasami ludzie używają paradygmatu funkcjonalnego, a czasem paradygmatu proceduralnego i tak dalej. A czasem się pomieszaliśmy. I ostatecznie reprezentujemy je jako szczególny styl lub paradygmat programowania.

Istnieje również paradygmat „wszystko jest listą lub przedmiotem” stosowany w LISP. Chciałbym wspomnieć o czymś innym niż programowanie funkcjonalne . PHP wykorzystuje to w tablicach asocjacyjnych.

OOP i paradygmaty „Wszystko jest listą lub przedmiotem” są uważane za 2 z bardziej NATURALNYCH stylów programowania, jak pamiętam w niektórych klasach sztucznej inteligencji.

Brzmi dla mnie dziwnie: „OOP nie jest naturalne”, może sposób, w jaki się uczysz lub sposób, w jaki cię uczono o OOP, jest zły, ale nie sam OOP.

umlcat
źródło
1

Biorąc pod uwagę te problemy, w jaki sposób / dlaczego tak się stało, że obecnie popularny sposób wykonywania OOP stał się tak popularny? Co można zrobić, aby zdetronizować to?

OOP stał się popularny, ponieważ oferuje narzędzia do organizowania programu na wyższym poziomie abstrakcji niż popularne języki proceduralne, które go poprzedziły. Stosunkowo łatwo było również stworzyć język, który miał strukturę proceduralną wewnątrz metod i otaczającą je strukturę obiektową. Dzięki temu programiści, którzy już wiedzieli, jak programować proceduralnie, mogą pobierać zasady OO pojedynczo. Doprowadziło to również do powstania wielu programów tylko w nazwie OO, które były programami proceduralnymi zawiniętymi w klasę lub dwa.

Aby zdetronizować OO, zbuduj język, który ułatwi stopniowe przejście od tego, co większość programistów zna dzisiaj (głównie proceduralnych, z niewielkim OO) do preferowanego przez ciebie paradygmatu. Upewnij się, że zapewnia wygodne interfejsy API do wykonywania typowych zadań i dobrze je promuj. Wkrótce ludzie będą tworzyć programy tylko w języku X w twoim języku. Potem możesz oczekiwać, że ludzie będą potrzebować lat, by dobrze zacząć robić X.

Sean McMillan
źródło
OP nie twierdzi, że OO jest ogólnie zły i powinien zostać zdetronizowany, ale że „obecnie powszechny sposób wykonywania OOP” nie jest najbardziej naturalny (w porównaniu z „wysyłką wielokrotną”).
Giorgio
OP wydaje się również nadmiernie skoncentrowany na definiowaniu hierarchii typów, w której najlepsze programy OO zwykle polegają bardziej na interfejsach i kompozycji. Jeśli wysyłka wielokrotna to X, to stworzenie języka, który pozwoli ludziom stopniowo uczyć się umiejętności związanych z wysyłką wielokrotną, jest nadal kluczem do zmiany środowiska.
Sean McMillan
1

Myślę, że języki OOP i OOP również mają problemy.

Jeśli rozumiesz to poprawnie, OOP dotyczy czarnych skrzynek (obiektów) z przyciskami, które można wcisnąć (metody). Zajęcia są tylko po to, aby pomóc zorganizować te czarne skrzynki.

Jednym z problemów jest to, że programista umieszcza przyciski na niewłaściwym obiekcie. Terminal nie może wyświetlać tekstu na sobie, tekst nie może wyświetlać się na terminalu. Komponent menedżera okien systemu operacyjnego, który może to zrobić. Okno terminala i tekst to tylko element pasywny. Ale jeśli myślimy w ten sposób, zdajemy sobie sprawę, że większość bytów to rzeczy pasywne i mielibyśmy tylko bardzo niewiele obiektów, które faktycznie coś robią (lub po prostu jeden: komputer ). Rzeczywiście, gdy używasz C, organizujesz go w moduły, moduły te reprezentują tak mało obiektów.

Inną kwestią jest to, że komputer po prostu wykonuje instrukcje sekwencyjnie. Załóżmy, że masz VCRi Televisioncel, jak można odtworzyć wideo? Prawdopodobnie piszesz coś takiego:

connect(television, vcr);
vcr.turnOn();
television.turnOn();
insert(vcr, yourFavoriteCasette);
vcr.play();
while (vcr.isPlaying()) {} // Wait while the VCR is playing the casette.
vcr.eject();
vcr.turnOff();
television.turnOff();

Byłoby to takie proste, ale potrzebujesz do tego co najmniej 3 procesorów ( lub procesów ): jeden odgrywa rolę ciebie, drugi to magnetowid, trzeci to telewizor. Ale zwykle masz tylko jeden rdzeń (przynajmniej za mało dla wszystkich swoich obiektów). Na studiach wielu moich kolegów z klasy nie rozumiało, dlaczego GUI zawiesza się, gdy przycisk wykonuje kosztowną operację.

Myślę więc, że projekt obiektowy może całkiem dobrze opisać świat, ale nie jest to najlepsza abstrakcja dla komputera.

Calmarius
źródło
0

Spójrz na DCI (dane, kontekst i interakcję) wymyślone przez wynalazcę wzoru MVC.

Celem DCI jest (cytowany z Wikipedii):

  • Nadaj systemowi status najwyższej klasy, ponad obiektami (rzeczownikami).
  • Czyste oddzielenie kodu dla szybko zmieniających się zachowań systemu (tego, co robi system) od kodu dla wolno zmieniającej się wiedzy o domenie (czym jest system), zamiast łączenia obu w jednym interfejsie klasy.
  • Wspierać obiektowy styl myślenia, który jest zbliżony do modeli mentalnych ludzi, a nie klasowy styl myślenia.

Oto dobry artykuł autorów, a oto niewielka przykładowa implementacja (.NET), jeśli chcesz zobaczyć kod. Jest o wiele prostszy, niż mogłoby się wydawać, i wydaje się bardzo naturalny.

Rozpłodnik
źródło
0

Często można usłyszeć, że OOP naturalnie odpowiada temu, jak ludzie myślą o świecie. Ale zdecydowanie nie zgadzam się z tym stwierdzeniem (...)

Ponieważ jest ewangelizowany w książkach i gdzie indziej przez dziesięciolecia, ja również się z tym nie zgadzam. Niemniej jednak uważam, że Nygaard i Dahl to właśnie to, i myślę, że skupiali się na tym, jak łatwiej było myśleć o projektowaniu symulacji w porównaniu z alternatywnymi czasami.

(...) ale głównym celem OOP jest projektowanie poszczególnych klas i ich hierarchii.

To twierdzenie wkracza na rozsądne terytorium, biorąc pod uwagę popularność nieporozumień dotyczących OOP i wrażliwość OO na definicję. Mam ponad dziesięć lat w tej dziedzinie, zajmując się zarówno pracą w branży, jak i badaniami naukowymi na temat prog. języków i mogę powiedzieć, że spędziłem wiele lat na uczeniu się „głównego nurtu OO”, ponieważ zacząłem zauważać, jak różni się (i gorszy) od tego, do czego dążyli wcześniejsi twórcy. Dla nowoczesnego, aktualnego traktowania tego tematu odniosę się do ostatniego wysiłku W. Cooka:

„Propozycja uproszczonych, nowoczesnych definicji„ Obiekt ”i„ Obiekt zorientowany ” http://wcook.blogspot.com.br/2012/07/proposal-for-simplified-modern.html

Biorąc pod uwagę te problemy, w jaki sposób / dlaczego tak się stało, że obecnie popularny sposób wykonywania OOP stał się tak popularny?

Być może ten sam powód, dla którego klawiatury QWERTY stały się popularne, lub ten sam powód, dla którego stał się popularny system operacyjny DOS. Rzeczy po prostu jeżdżą popularnymi pojazdami, pomimo ich właściwości, i same stają się popularne. Czasami podobne, ale gorsze wersje czegoś są uważane za rzeczywiste.

Co można zrobić, aby zdetronizować to?

Napisz program, korzystając z doskonałego podejścia. Napisz ten sam program, stosując podejście OO. Pokaż pierwsze ma lepsze właściwości niż drugie pod każdym istotnym aspektem (zarówno właściwości samego systemu, jak i właściwości inżynierskie). Pokaż, że wybrany program jest odpowiedni, a proponowane podejście utrzymuje wysoką jakość właściwości, jeśli zostanie zastosowane do innych rodzajów programów. Bądź rygorystyczny w swojej analizie i używaj precyzyjnych i akceptowanych definicji w razie potrzeby.

Na koniec podziel się z nami swoimi odkryciami.

Thiago Silva
źródło
-1

Weźmy Java: obiekty są rodzajem wąskiego gardła abstrakcji, większość „rzeczy” jest albo ściśle podkomponentami obiektów, albo używa obiektów jako ich podkomponentów. Przedmioty muszą być wystarczająco uniwersalne, aby cała warstwa abstrakcji między tymi dwoma rodzajami rzeczy - wspólny cel oznacza, że ​​nie ma jednej metafory, którą uosabiają. W szczególności Java czyni obiekty (i klasy) jedyną warstwą, przez którą wywołujesz / wysyłasz kod. Ta ilość rzeczy, które ucieleśniają przedmioty, czyni je, szczerze mówiąc, zdecydowanie zbyt złożonymi. Każdy użyteczny ich opis musi być ograniczony do jakiejś specjalistycznej lub zastrzeżonej formy.

Hierarchia dziedziczenia i interfejsu to „rzeczy”, które wykorzystują obiekty jako podskładniki. Jest to jeden wyspecjalizowany sposób opisywania obiektów, a nie sposób uzyskiwania ogólnego zrozumienia obiektów.

Można powiedzieć, że „obiekty” mają wiele rzeczy, ponieważ są abstrakcją wielofunkcyjną, która jest mniej więcej uniwersalna w „OO Langauge”. Jeśli są używane do przechowywania lokalnego stanu zmiennego lub do uzyskania dostępu do jakiegoś zewnętrznego stanu świata, wyglądają bardzo podobnie do „rzeczownika”.

Natomiast obiekt reprezentujący proces, np. „Szyfruj”, „kompresuj” lub „sortuj”, wygląda jak „czasownik”.

Niektóre obiekty pełnią rolę przestrzeni nazw, np. Miejsce na umieszczenie funkcji „statycznej” w Javie.

Jestem skłonny zgodzić się z argumentem, że Java jest zbyt obciążona wywołaniami metod obiektowych, z wysyłką do obiektu. Jest tak prawdopodobnie dlatego, że wolę klasy Haskella do kontrolowania wysyłki. Jest to ograniczenie wysyłki i jest to funkcja Java, ale nie większość języków, a nawet większość języków OO.

Chris Kuklewicz
źródło
-3

Byłem świadkiem wielu debat online na temat OOP i uczestniczyłem w nich. Zwolennicy OOP zwykle nie wiedzą, jak napisać odpowiedni kod proceduralny. Możliwe jest pisanie kodu proceduralnego, który jest wysoce modułowy. Możliwe jest oddzielenie kodu i danych i upewnienie się, że funkcje mogą zapisywać tylko we własnym magazynie danych. Możliwe jest wdrożenie koncepcji dziedziczenia za pomocą kodu proceduralnego. Co ważniejsze, kod proceduralny jest cieńszy, szybszy i łatwiejszy do debugowania.

Jeśli budujesz moduły jednoplikowe z surowymi konwencjami nazewnictwa, kod proceduralny jest łatwiejszy do napisania i utrzymania niż OO i zrobi to samo lub więcej i szybciej. I nie zapominaj, że podczas działania aplikacji jest ona zawsze proceduralna bez względu na to, ile klas występuje w twoim skrypcie.

Następnie masz problem z językami takimi jak PHP, które nie są tak naprawdę zorientowane obiektowo i polegają na włamaniach do fałszowania rzeczy, takich jak wielokrotne dziedziczenie. Wielkie ujęcia, które wpływają na kierunek języka, zmieniły PHP w mozaikę niespójnych reguł, które stały się zbyt duże, aby osiągnąć zamierzony cel. Kiedy widzę, że programiści piszą ogromne klasy szablonów dla tego, co miało być proceduralnym językiem szablonów, nie mogę się powstrzymać od uśmiechu.

Jeśli porównasz poprawnie napisany kod OO ze źle napisanym kodem proceduralnym, zawsze dojdziesz do błędnego wniosku. Bardzo niewiele projektów uzasadnia projekt obiektowy. Jeśli jesteś IBM i zarządzasz dużym projektem, który musi być utrzymywany przez wiele lat przez wielu programistów, wybierz Object Oriented. Jeśli piszesz małego bloga lub stronę z zakupami dla klienta, zastanów się dwa razy.

Aby odpowiedzieć na pierwotne pytanie, OOP jest trudne, ponieważ nie rozwiązuje rzeczywistych dylematów programistycznych bez uciekania się do rozwiązań, które są 100 razy bardziej skomplikowane niż powinny. Jednym z najskuteczniejszych rozwiązań wielu problemów programistycznych jest rozsądne wykorzystanie danych globalnych. Jednak absolwenci uniwersytetów nowej fali powiedzą ci, że to wielkie nie-nie. Globalnie dostępne dane są niebezpieczne tylko wtedy, gdy jesteś niezdarnym królikiem programistycznym. Jeśli masz ścisły zestaw zasad i odpowiednie konwencje nazewnictwa, możesz uniknąć globalnego przechowywania wszystkich swoich danych.

Wymagane jest, aby każdy programista zorientowany obiektowo wiedział, jak napisać aplikację do gry w szachy w asemblerze, aby uzyskać maksymalną dostępną pamięć 16 KB. Następnie uczą się, jak przycinać tłuszcz, lenistwo i generować genialne rozwiązania.

JG Estiot
źródło