Czy OOP jest trudne, ponieważ nie jest naturalne?

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?

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.

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?

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.

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.

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).

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.

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.

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.

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ł.

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.

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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.