Ist OOP schwer, weil es nicht natürlich ist?

86

Man kann oft hören, dass OOP natürlich der Art und Weise entspricht, wie Menschen über die Welt denken. Ich würde dieser Aussage jedoch stark widersprechen: Wir (oder zumindest ich) konzipieren die Welt in Bezug auf Beziehungen zwischen Dingen, denen wir begegnen, aber der Fokus von OOP liegt auf der Gestaltung einzelner Klassen und ihrer Hierarchien.

Beachten Sie, dass im täglichen Leben Beziehungen und Aktionen hauptsächlich zwischen Objekten bestehen, bei denen es sich in OOP um Instanzen nicht verwandter Klassen gehandelt hätte. Beispiele für solche Beziehungen sind: "Mein Bildschirm befindet sich oben auf der Tabelle"; "Ich (ein Mensch) sitze auf einem Stuhl"; "Ein Auto ist unterwegs"; "Ich tippe auf der Tastatur"; "Die Kaffeemaschine kocht Wasser", "der Text wird im Terminalfenster angezeigt."

Wir denken in zweiwertigen (manchmal dreiwertigen, wie zum Beispiel in "Ich gab dir Blumen") Verben, bei denen das Verb die Aktion (Relation) ist, die auf zwei Objekte wirkt, um ein Ergebnis / eine Aktion zu erzielen. Der Fokus liegt auf der Aktion, und die zwei (oder drei) [grammatikalischen] Objekte sind gleich wichtig.

Vergleichen Sie dies mit OOP, bei dem Sie zuerst ein Objekt (Substantiv) finden und es anweisen müssen, eine Aktion für ein anderes Objekt auszuführen. Die Denkweise wird von Aktionen / Verben, die mit Substantiven arbeiten, zu Substantiven, die mit Substantiven arbeiten, verschoben - es ist, als würde alles mit passiver oder reflexiver Stimme gesagt, z. B. "der Text wird im Terminalfenster angezeigt". Oder vielleicht "der Text zeichnet sich selbst im Terminalfenster".

Der Fokus wird nicht nur auf Substantive verlagert, sondern einem der Substantive (nennen wir es grammatikalisches Subjekt) wird eine höhere "Wichtigkeit" beigemessen als dem anderen (grammatikalisches Objekt). Man muss sich also entscheiden, ob man terminalWindow.show (someText) oder someText.show (terminalWindow) sagt. Aber warum Menschen mit so trivialen Entscheidungen ohne operative Konsequenzen belasten, wenn man wirklich Show meint (terminalWindow, someText)? [Konsequenzen sind betrieblich unbedeutend - in beiden Fällen wird der Text im Terminalfenster angezeigt -, können jedoch beim Entwurf von Klassenhierarchien sehr schwerwiegend sein, und eine "falsche" Auswahl kann zu verwickeltem und schwer zu wartendem Code führen.]

Ich würde daher argumentieren, dass die gängige Art, OOP (klassenbasiert, Einzelversand) durchzuführen, schwierig ist, weil sie UNNATURAL ist und nicht der Art entspricht, wie Menschen über die Welt denken. Generische Methoden von CLOS kommen meiner Denkweise näher, aber leider ist dies kein weit verbreiteter Ansatz.

Wie / warum ist es angesichts dieser Probleme dazu gekommen, dass der derzeitige Mainstream-Ansatz der OOP so populär wurde? Und was kann getan werden, um es zu entthronen?

zvrba
quelle
OOP ist für 'Programmierung' gemacht, damit Compiler es genießen können. Es ist keine Möglichkeit, die reale Welt in irgendeiner Weise zu modellieren. Es ist üblich, während des OOP-Unterrichts reale Beispiele wie Tierklasse und Rechteckklasse zu verwenden, aber dies sind nur Beispiele, um die Konzepte zu vereinfachen. Leider "passieren" Programmiersprache und Paradigmen nicht evolutionär und nicht wissenschaftlich. Mit wenigen Ausnahmen ist der Prozess der Sprachgestaltung in der Regel das Kind der Wenigsten!
NoChance
3
Ich würde der Behauptung nicht zustimmen, dass "der Fokus von OOP auf der Gestaltung einzelner Klassen und ihrer Hierarchien liegt". Seit Maybie ist es der Fokus einer bestimmten Implementierung von OOP, aber ich habe zum Beispiel festgestellt, dass dynamische OOP-Sprachen normalerweise keine großen Hierarchien oder gar Klassen haben. Nun, die OOP - Definition kann in Zukunft ändern, gibt es einen Versuch , auch das Objekt ein sich ändern wcook.blogspot.com/2012/07/proposal-for-simplified-modern.html
Azder
1
OOP identifiziert Objekte im System und konstruiert Klassen basierend auf diesen Objekten. Nicht umgekehrt. Aus diesem Grund bin ich auch anderer Meinung als "der Fokus von OOP liegt auf der Gestaltung einzelner Klassen und ihrer Hierarchien".
Radu Murzea
1
Ich denke, dies ist eine sehr subjektive Frage und sie ist voller seltsamer Annahmen über OOP und was die "reale Welt" ist und wie die Leute über Probleme denken. Und schließlich fragt es sogar: "Und was kann getan werden, wenn überhaupt, um es zu entthronen?" Das zeigt wirklich, dass das OP eine sehr starke Meinung dazu hat. Wenn Sie so "religiös" in Bezug auf Programmierparadigmen sind, brauchen Sie vermutlich keine Antworten ... Sie wissen bereits, was Sie hören möchten. Wenn ich von dieser Frage gewusst hätte, als sie zum ersten Mal gestellt wurde, hätte ich wahrscheinlich dafür gestimmt, sie zu schließen ...
Simon Lehmann,

Antworten:

97

OOP ist für einige Probleme unnatürlich. Also ist verfahrenstechnisch. Also ist funktionsfähig. Ich denke, OOP hat zwei Probleme, die es wirklich schwierig erscheinen lassen.

  1. Einige Leute tun so, als wäre es der einzig wahre Weg zu programmieren, und alle anderen Paradigmen sind falsch. IMHO sollte jeder eine multiparadigmische Sprache verwenden und das beste Paradigma für das Teilproblem auswählen, an dem er gerade arbeitet. Einige Teile Ihres Codes haben einen OO-Stil. Einige werden funktionsfähig sein. Einige werden einen klaren prozeduralen Stil haben. Mit der Erfahrung wird deutlich, welches Paradigma für was am besten ist:

    ein. OO ist im Allgemeinen am besten geeignet, wenn Sie Verhaltensweisen haben, die stark an den Zustand gekoppelt sind, in dem sie ausgeführt werden, und die genaue Art des Zustands ein Implementierungsdetail ist, dessen Existenz jedoch nicht ohne Weiteres abstrahiert werden kann. Beispiel: Kollektionsklassen.

    b. Prozedural ist am besten geeignet, wenn Sie eine Reihe von Verhaltensweisen haben, die nicht stark an bestimmte Daten gekoppelt sind. Beispielsweise können sie primitive Datentypen verarbeiten. Es ist am einfachsten, sich das Verhalten und die Daten als separate Einheiten vorzustellen. Beispiel: Zahlencode.

    c. Funktional ist am besten, wenn Sie etwas haben, das relativ einfach deklarativ zu schreiben ist, so dass das Vorhandensein eines Zustands überhaupt ein Implementierungsdetail ist, das leicht entfernt werden kann. Beispiel: Parallelität abbilden / reduzieren.

  2. OOP zeigt im Allgemeinen seine Nützlichkeit bei großen Projekten, bei denen gut gekapselte Codeteile wirklich erforderlich sind. Dies passiert in Anfängerprojekten nicht zu oft.

dsimcha
quelle
4
Ich denke, ein wichtiger Punkt bei der Frage war nicht, ob OOP natürlich ist, sondern ob der Mainstream-Ansatz für OOP der natürlichste OOP-Ansatz ist. (Gute Antwort trotzdem.)
Giorgio
11
"OOP zeigt im Allgemeinen seine Nützlichkeit bei großen Projekten, bei denen gut gekapselte Codeteile wirklich erforderlich sind.": Dies ist jedoch keine spezifische Eigenschaft von OOP, da es gute Modulkonzepte auch für imperative, funktionale, ... Programmiersprachen gibt .
Giorgio
2
OOP ist wirklich auf einer anderen Achse als prozedural / funktional; Es befasst sich mit der Organisation und Kapselung des Codes und nicht mit der Beschreibung der Vorgänge. (Sie arbeiten OOP immer mit einem Ausführungsparadigma zusammen. Ja, es gibt OOP + -Funktionssprachen.)
Donal Fellows
1
Könnte man nicht sagen, dass OOP nur die Kisten sind, in die wir die prozeduralen Dinge stecken?
Erik Reppen
In OOP können Sie weiterhin Methoden schreiben. Was macht OOP schwächer als die prozedurale Programmierung?
Mert Akcakaya
48

IMHO ist es eine Frage des persönlichen Geschmacks und der Denkweise. Ich habe nicht viel Probleme mit OO.

Wir (oder zumindest ich) konzipieren die Welt in Bezug auf die Beziehungen zwischen Dingen, denen wir begegnen, aber der Fokus von OOP liegt auf der Gestaltung einzelner Klassen und ihrer Hierarchien.

IMHO ist dies nicht ganz so, obwohl es eine gemeinsame Wahrnehmung sein kann. Alan Kay, der Erfinder des Begriffs OO, betonte immer die zwischen Objekten gesendeten Botschaften und nicht die Objekte selbst. Und die Botschaften bezeichnen, zumindest für mich, Beziehungen.

Beachten Sie, dass im täglichen Leben Beziehungen und Aktionen hauptsächlich zwischen Objekten bestehen, bei denen es sich in OOP um Instanzen nicht verwandter Klassen gehandelt hätte.

Wenn es eine Beziehung zwischen Objekten gibt, sind diese per Definition miteinander verbunden. In OO können Sie dies mit einer Assoziations- / Aggregations- / Verwendungsabhängigkeit zwischen zwei Klassen ausdrücken.

Wir denken in zweiwertigen (manchmal dreiwertigen, wie zum Beispiel in "Ich gab dir Blumen") Verben, bei denen das Verb die Aktion (Relation) ist, die auf zwei Objekte wirkt, um ein Ergebnis / eine Aktion zu erzielen. Der Fokus liegt auf der Aktion, und die zwei (oder drei) [grammatikalischen] Objekte sind gleich wichtig.

Aber sie haben immer noch ihre genau definierten Rollen im Kontext: Subjekt, Objekt, Handlung usw. "Ich habe dir Blumen gegeben" oder "Du hast mir Blumen gegeben" sind nicht dasselbe (ganz zu schweigen von "Blume hat dich mir gegeben"): -)

Vergleichen Sie dies mit OOP, bei dem Sie zuerst ein Objekt (Substantiv) finden und es anweisen müssen, eine Aktion für ein anderes Objekt auszuführen. Die Denkweise wird von Aktionen / Verben, die mit Substantiven arbeiten, zu Substantiven, die mit Substantiven arbeiten, verschoben - es ist, als würde alles mit passiver oder reflexiver Stimme gesagt, z. B. "der Text wird im Terminalfenster angezeigt". Oder vielleicht "der Text zeichnet sich selbst im Terminalfenster".

Ich bin damit nicht einverstanden. IMHO liest sich der englische Satz "Bill, go to hell" im Programmcode natürlicher bill.moveTo(hell)als move(bill, hell). Und ersteres ist in der Tat analoger zu der ursprünglichen aktiven Stimme.

Man muss sich also entscheiden, ob man terminalWindow.show (someText) oder someText.show (terminalWindow) sagt

Wiederum ist es nicht dasselbe, das Terminal zu bitten, einen Text anzuzeigen, oder den Text zu bitten, das Terminal anzuzeigen. IMHO ist es ziemlich offensichtlich, welches natürlicher ist.

Wie / warum ist es angesichts dieser Probleme dazu gekommen, dass der derzeitige Mainstream-Ansatz der OOP so populär wurde?

Vielleicht, weil die Mehrheit der OO-Entwickler OO anders sieht als Sie?

Péter Török
quelle
15
+1 für die direkte Erwähnung dieser Nachrichten zwischen Objekten und ihrer Bedeutung von Alan Kay
bunglestink
3
@zvrba, tatsächlich gab es auch andere OO-Pioniere, aber das steht nicht im Vordergrund dieser Diskussion. "Das Natürlichste ist, nach dem Text zu fragen, der angezeigt werden soll." - Jetzt verwenden Sie dieselbe passive Stimme, von der Sie behauptet haben, dass sie in OOP so "unnatürlich" ist.
Péter Török
5
@zvrba, Sie sagen, "es gibt immer einen" Agenten ", der [...] einige Dinge tut", protestieren jedoch gegen den OO-Ansatz, diese Agenten (Objekte) zu identifizieren und zu benennen und sie als erstklassige Bürger in der Sprache zu behandeln . Für mich ist dies Teil der Modellierung der Problemdomäne - Sie müssen dies trotzdem tun und das resultierende Domänenmodell dann auf unterschiedliche Weise dem Code zuordnen, je nachdem, ob Ihre Sprache OO ist oder nicht.
Péter Török,
6
@zvrba, es ist nicht OO per se, sondern ein Entwickler / Designer, der über die Rollen und Verantwortlichkeiten verschiedener Objekte entscheidet. Die Verwendung des OO-Ansatzes kann zu guten oder schlechten Domain-Modellen und -Designs führen, genauso wie die Verwendung eines Messers zu einer Scheibe feinem Brot oder einem blutenden Finger - wir geben dem Messer jedoch keine Schuld, da es nur ein Werkzeug ist. Beachten Sie auch, dass die Konzepte / Objekte / Agenten im Modell Abstraktionen von Dingen in der realen Welt sind und als solche immer begrenzt und verzerrt sind und sich nur auf bestimmte "interessante" Aspekte konzentrieren.
Péter Török,
6
@zvrba, ein Auto startet tatsächlich nicht aus eigenem Willen - so wie ein CarObjekt start()nur, wenn seine Methode explizit von jemandem aufgerufen wird.
Péter Török,
10

Einige Programmierer finden OOD schwierig, weil diese Programmierer gerne darüber nachdenken, wie das Problem für den Computer gelöst werden kann und nicht, wie das Problem gelöst werden sollte.

... aber der Fokus von OOP liegt auf dem Entwerfen einzelner Klassen und ihrer Hierarchien.

Darum geht es bei OOD NICHT. Bei OOD geht es darum, herauszufinden, wie sich die Dinge verhalten und wie sie interagieren.

Wir denken in zweiwertigen (manchmal dreiwertigen, wie zum Beispiel in "Ich gab dir Blumen") Verben, bei denen das Verb die Aktion (Relation) ist, die auf zwei Objekte wirkt, um ein Ergebnis / eine Aktion zu erzielen. Der Fokus liegt auf der Aktion, und die zwei (oder drei) [grammatikalischen] Objekte sind gleich wichtig.

Der Fokus auf OOD liegt immer auf Aktionen, bei denen Aktionen das Verhalten von Objekten sind. Objekte sind nichts ohne ihr Verhalten. Die einzige Objektbeschränkung von OOD ist, dass alles von etwas erledigt werden muss.

Ich sehe den Handelnden nicht als wichtiger an als die Sache, die etwas damit angestellt hat.

Aber warum Menschen mit so trivialen Entscheidungen belasten, die keine operativen Konsequenzen haben, wenn man wirklich Show meint (terminalWindow, someText)?

Für mich ist das dasselbe mit einer anderen Schreibweise. Sie müssen sich noch entscheiden, wer duscht und wer duscht. Sobald Sie das wissen, gibt es keine Entscheidung in OOD. Windows show text -> Window.Show (Text).

Viele Dinge da draußen (besonders im Bereich der Legacy) sagen, dass es OO ist, wenn es nicht so ist. Zum Beispiel gibt es eine große Menge an C ++ - Code, der keine OOD-Figur implementiert.

OOD ist einfach, wenn Sie die Einstellung verlassen, dass Sie ein Problem für Computer lösen. Sie lösen Probleme für Dinge, die etwas bewirken.

Matt Ellen
quelle
10
Ich mag OOD nicht genau, weil ich lieber darüber nachdenke, wie ich das Problem lösen kann, Punkt. Ich möchte nicht darüber nachdenken, wie man die natürliche Sprache einer Problemdomäne in eine fremde Welt aus Objekten, Nachrichten, Vererbung usw. übersetzt. Ich möchte hierachische Taxonomien nicht erfinden, wo sie natürlich nicht existieren. Ich möchte das Problem in seiner natürlichen Sprache beschreiben und es so einfach wie möglich lösen. Übrigens besteht die Welt nicht nur aus "Dingen, die Sachen machen". Ihre Sicht auf die Realität ist extrem eng.
SK-logic
7
@Matt Ellen, ich schreibe Programme, die das Verhalten von Entites modellieren, die keine "Dinge" sind und keine "Dinge" "tun". Eine unveränderliche Einheit tut nichts. Jede mathematisch reine Funktion macht nichts - es ist nur eine Abbildung von einer Menge zu einer anderen, und diese Welt wird meistens durch solche Funktionen beschrieben. Jeder logische Formalismus "tut" nichts. Ja, OOD wird mir nicht helfen, weil ich in der Lage bin, viel leistungsfähigere Abstraktionen und Modelle zu verwenden. Die Rückkehr zu einer primitiven, begrenzten, begrenzten OOD wird mich stark behindern.
SK-logic
2
@ Matt Ellen, ja, ich würde gerne Referenzen sehen, die so seltsame Behauptungen stützen, dass die Welt besser als eine Sammlung von "Dingen, die Sachen machen" oder "Objekten, die über Nachrichten interagieren" angesehen wird. Es ist völlig unnatürlich. Nehmen Sie eine wissenschaftliche Theorie (da sie alle so nah wie möglich an der Modellierung der realen Welt sind) und versuchen Sie, sie unter Verwendung Ihrer Terminologie umzuschreiben. Das Ergebnis wird ungeschickt und umständlich sein.
SK-logic
4
@ Antonio2011a, es gibt kein einzelnes Programmier- oder Modellierungsparadigma, das alle möglichen Problembereiche effizient abdecken kann. OOP, Funktionalität, Datenfluss, Logik erster Ordnung, was auch immer - alle sind problemdomänenspezifische Paradigmen und nichts weiter. Ich befürworte nur die Vielfalt und den aufgeschlossenen Ansatz bei der Problemlösung. Es ist einfach dumm, sich auf ein einziges Paradigma zu beschränken. Das, was einem universellen Ansatz am nächsten kommt und Sie nicht auf ein einziges semantisches Framework beschränkt, ist en.wikipedia.org/wiki/Language-oriented_programming
SK-logic
3
@Calmarius, warum würden Sie die Programmierung für Computer vereinfachen? Das ist nur albern. Es sind die Menschen, die die härtere Arbeit leisten müssen.
Matt Ellen
7

Vielleicht verstehe ich das nicht, aber:

Als ich das erste Buch über OOP las (Anfang der 90er Jahre, Borlands dünnes Handbuch für Pascal), war ich einfach erstaunt über seine Einfachheit und sein Potenzial. (Vorher hatte ich Cobol, Fortran, Assemblersprache und anderes prähistorisches Zeug benutzt.)

Für mich ist es ziemlich klar: Ein Hund ist ein Tier, ein Tier muss fressen, mein Hund ist ein Hund, also muss er fressen ...

Andererseits ist die Programmierung selbst von Natur aus unnatürlich (dh künstlich). Die menschliche Sprache ist künstlich (beschuldigen Sie mich nicht, wir haben alle unsere Sprachen von anderen gelernt, niemand kennt die Person, die Englisch erfunden hat). Nach Ansicht einiger Wissenschaftler wird der menschliche Geist durch die Sprache geformt, die er zuerst gelernt hat.

Ich gebe zu, einige Konstrukte in modernen OO-Sprachen sind etwas umständlich, aber es ist die Entwicklung.

Nerevar
quelle
1
Was genau war Ihre Aufgabe, als Sie von Cobol zu Fortran und dann zur Montage (und zum Rest) wechselten?
Turm
1
Falsche Bestellung. Tatsächlich habe ich mit Basic angefangen, bin dann nach Fortran und dann nach Assembly und Cobol gezogen (ja, es ist die richtige Reihenfolge: Assembly first). Der erste Computer in meinem Leben war ein "gigantischer" Großrechner mit 256 kB Speicher, der seine Konsole mit Lochkarten fütterte, weil ich sein Bediener war. Als ich mich zum Systemprogrammierer entwickelt hatte, war ein verdächtiges Ding namens PC-AT an meinem Schreibtisch gelandet. Also hatte ich mich in GW-Basic, Turbo-Pascal usw. vertieft.
Nerevar
1
Darauf habe ich nicht eingegangen. Mehr zu Ihrer Jobdomäne; Weil ich nicht viele Leute kenne (irgendjemand wirklich), die sich mit COBOL (geschäftlich orientiert), fortran (wissenschaftlicher Bereich), Assembler (mehr cs-orientiert) und dann diesen anderen beschäftigten. Trotzdem sind sie professionelle Programmierer oder nicht.
Turm
1
Kein Rätsel: Schließen Sie sich Teams und Projekten an, bei denen zuvor eine Entscheidung über den Sprachansatz getroffen wurde. Und eine nicht triviale Neugier für die von ihnen verwendeten Tools.
Nerevar
6

Eine Sache, die es mir schwer machte, war zu denken, dass es bei OOP darum ging, die Welt zu modellieren. Ich dachte, wenn ich das nicht richtig verstanden hätte, könnte mir etwas in den Arsch beißen (etwas ist entweder wahr oder nicht wahr). Ich war mir der Probleme sehr bewusst, dass das Vorgeben von allem ein Objekt oder eine Entität ist. Dies machte mich sehr vorsichtig und zuversichtlich in Bezug auf das Programmieren in OOP.

Dann habe ich SICP gelesen und bin zu dem neuen Verständnis gekommen, dass es wirklich um Datentypen und die Kontrolle des Zugriffs darauf geht. Alle Probleme, die ich weggeschmolzen hatte, weil sie auf der falschen Annahme beruhten, dass Sie in OOP die Welt modellieren.

Ich staune immer noch über die immense Schwierigkeit, die diese falsche Prämisse mir bereitet hat (und wie ich mich dazu verpflichten lasse).

Binokel
quelle
Vielen Dank, dass Sie auf die Gefahr hingewiesen haben, die Welt zu modellieren.
Sean McMillan
4

Ja, OOP selbst ist sehr unnatürlich - die reale Welt besteht nicht ausschließlich aus hierarchischen Taxonomien. Einige kleine Teile davon bestehen aus diesem Zeug, und diese Teile sind die einzigen Dinge, die in Bezug auf OO angemessen ausgedrückt werden können. Alles andere lässt sich natürlich nicht in eine so triviale und eingeschränkte Denkweise einordnen. Sehen Sie sich die Naturwissenschaften an und sehen Sie, wie viele verschiedene mathematische Sprachen erfunden wurden, um die Komplexität der realen Welt auf einfachste oder zumindest nachvollziehbare Weise auszudrücken. Und fast keine von ihnen kann leicht in eine Sprache von Objekten und Nachrichten übersetzt werden.

SK-Logik
quelle
5
Das gilt auch für jede formale Notation, die versucht, die reale Welt genau zu beschreiben.
Péter Török
1
@ Péter Török, genau mein Punkt. Es gibt keinen einzigen Formalismus, der alles abdeckt. Sie müssen sie alle benutzen, in all ihrer gruseligen Menge. Und das ist der Grund, warum ich an eine sprachorientierte Programmierung glaube - sie ermöglicht es, verschiedene, oft inkompatible Formalismen in eine solide Code-Entität zu übernehmen.
SK-logic
1
Alles kann in hierarchische Taxonomien eingeteilt werden. Der Trick besteht darin, sinnvolle Konzepte zu entwickeln. Mehrfachvererbung ist häufig beteiligt. Ein großer Unterschied zwischen Software und der realen Welt besteht darin, dass wir in der realen Welt häufig die Kategorisierungsschemata ableiten oder entdecken müssen. In der Software erfinden wir sie.
Caleb
1
Wenn Sie einen Begriff wie "hierarchische Taxonomie" verwenden, denken Sie an Vererbung. Vererbung ist in der Tat schwer zu begründen. Deshalb schlagen die Leute vor, Komposition anstelle von Vererbung zu verwenden.
Frank Shearar
1
@Frank: In der realen Welt gibt es viele Arten hierarchischer Taxonomien, von denen die Vererbung nur eine ist. Dies alles richtig zu machen, erfordert bessere Werkzeuge als OOP (zB ontologisches Denken) und hat Philosophen seit Jahrtausenden
Donal Fellows
4

Wir (oder zumindest ich) konzipieren die Welt in Bezug auf die Beziehungen zwischen Dingen, denen wir begegnen, aber der Fokus von OOP liegt auf der Gestaltung einzelner Klassen und ihrer Hierarchien.

Sie gehen von einer falschen Prämisse aus (IMO). Die Beziehungen zwischen Objekten sind wohl wichtiger als die Objekte selbst. Es sind die Beziehungen, die eine objektorientierte Programmstruktur ergeben. Vererbung, die Beziehung zwischen Klassen, ist natürlich wichtig, da die Klasse eines Objekts bestimmt, was dieses Objekt tun kann . Es sind jedoch die Beziehungen zwischen einzelnen Objekten, die bestimmen, was ein Objekt innerhalb der von der Klasse definierten Grenzen tatsächlich tut und wie sich das Programm verhält.

Das objektorientierte Paradigma kann zunächst schwierig sein, nicht weil es schwierig ist, sich neue Kategorien von Objekten auszudenken, sondern weil es schwierig ist, sich einen Graphen von Objekten vorzustellen und zu verstehen, wie die Beziehungen zwischen ihnen aussehen sollten, insbesondere wenn Sie keine haben Art und Weise, diese Beziehungen zu beschreiben. Aus diesem Grund sind Entwurfsmuster so nützlich. Bei Entwurfsmustern geht es fast ausschließlich um die Beziehungen zwischen Objekten. Muster geben uns sowohl die Bausteine, mit denen wir Objektbeziehungen auf einer höheren Ebene entwerfen können, als auch eine Sprache, mit der wir diese Beziehungen beschreiben können.

Gleiches gilt für kreative Bereiche, die in der physischen Welt arbeiten. Jeder könnte ein paar Zimmer zusammenwerfen und es ein Gebäude nennen. Die Zimmer sind vielleicht sogar komplett mit den neuesten Ausstattungen ausgestattet, aber das lässt das Gebäude nicht funktionieren. Die Aufgabe eines Architekten besteht darin, die Beziehungen zwischen diesen Räumen in Bezug auf die Anforderungen der Personen, die diese Räume nutzen, und die Umgebung des Gebäudes zu optimieren. Es ist das, was ein Gebäude sowohl aus funktionaler als auch aus ästhetischer Sicht zum Funktionieren bringt.

Wenn Sie Probleme haben, sich an OOP zu gewöhnen, sollten Sie sich überlegen, wie Ihre Objekte zusammenpassen und wie ihre Verantwortlichkeiten angeordnet sind. Wenn Sie dies noch nicht getan haben, lesen Sie über Entwurfsmuster - Sie werden wahrscheinlich feststellen, dass Sie die Muster, über die Sie gelesen haben, bereits gesehen haben. Wälder, Haine, Waldstücke und schließlich Wälder.

Caleb
quelle
3

Dies ist nur ein Teil dessen, was mit OOP nicht stimmt.

Im Grunde werden Funktionen zu Bürgern zweiter Klasse, und das ist schlecht.

Moderne Sprachen (Ruby / Python) leiden nicht unter diesem Problem und bieten Funktionen als erstklassige Objekte sowie die Möglichkeit, Programme zu erstellen, ohne eine Klassenhierarchie zu erstellen.

hasen
quelle
OOP erscheint mir sehr natürlich, es fällt mir in der Tat schwer, über Programmieraufgaben auf andere Weise nachzudenken. Im Laufe der Jahre habe ich jedoch verstanden, dass OOP dazu neigt, Substantive über Verben zu betonen. Diese Beschimpfung von 2006 hat mir geholfen, diese Unterscheidung zu verstehen: steve-yegge.blogspot.com/2006/03/…
Jim In Texas
3

OOP ist nicht schwer. Was es schwierig macht, gut zu verwenden, ist ein flaches Verständnis dessen, wofür es gut ist, wenn Programmierer zufällige Maximen hören und sie vor sich hin wiederholen, um den Segen der göttlichen Viererbande, des gesegneten Martin Fowler, oder wen auch immer sie sonst gelesen haben.

Marcin
quelle
3

BEARBEITET

Zuallererst möchte ich sagen, dass ich OOP nie als schwierig oder schwieriger empfunden habe als andere Programmierparadigmen. Das Programmieren ist von Natur aus schwierig, da es versucht, Probleme aus der realen Welt zu lösen, und die reale Welt ist äußerst komplex. Andererseits, als ich diese Frage las, fragte ich mich: Ist OOP "natürlicher" als andere Paradigmen? Und damit effektiver?

Ich habe einmal einen Artikel über eine vergleichende Studie zwischen imperativer Programmierung (IP) und objektorientierter Programmierung (OOP) gefunden (ich wünschte, ich könnte ihn wiederfinden, um ihn als Referenz zu veröffentlichen). Sie hatten im Grunde genommen die Produktivität professioneller Programmierer gemessen, die IP und OOP in verschiedenen Projekten verwendeten, und das Ergebnis war, dass sie keine großen Unterschiede gesehen hatten. Die Behauptung lautete also, dass es keinen großen Produktivitätsunterschied zwischen den beiden Gruppen gibt und dass Erfahrung wirklich zählt.

Auf der anderen Seite behaupten Befürworter der Objektorientierung, dass während der frühen Entwicklung eines Systems OOP sogar mehr Zeit als nötig in Anspruch nehmen kann, der Code auf lange Sicht aufgrund der engen Integration von Daten und einfacher zu pflegen und zu erweitern ist Operationen.

Ich habe hauptsächlich mit OOP-Sprachen (C ++, Java) gearbeitet, aber ich habe oft das Gefühl, mit Pascal oder Ada so produktiv zu sein, obwohl ich sie nie für große Projekte ausprobiert habe.

Vergleichen Sie dies mit OOP, bei dem Sie zuerst ein Objekt (Substantiv) finden und es anweisen müssen, eine Aktion für ein anderes Objekt auszuführen.

[Schnitt]

Ich würde daher argumentieren, dass die gängige Art, OOP (klassenbasiert, Einzelversand) durchzuführen, schwierig ist, weil sie UNNATURAL ist und nicht der Art entspricht, wie Menschen über die Welt denken. Generische Methoden von CLOS kommen meiner Denkweise näher, aber leider ist dies kein weit verbreiteter Ansatz.

Als ich diesen letzten Absatz genauer las, verstand ich endlich den Hauptpunkt Ihrer Frage und musste meine Antwort von Grund auf neu schreiben. :-)

Ich kenne andere OO-Vorschläge, bei denen mehrere Objekte eine Nachricht statt nur eines erhalten, dh, mehrere Objekte spielen beim Empfang einer Nachricht eine symmetrische Rolle. JA, dies scheint mir ein allgemeinerer und vielleicht natürlicherer (weniger restriktiver) OOP-Ansatz zu sein.

Andererseits kann "Mehrfachversand" mit "Einzelversand" leicht simuliert werden, und "Einzelversand" ist einfacher zu implementieren. Vielleicht ist dies ein Grund, warum "Mehrfachversand" nicht zum Mainstream geworden ist.

Giorgio
quelle
3

Hören Sie auf, nach einem exklusiven OOP-Paradigma zu suchen, und probieren Sie JavaScript aus.

Derzeit habe ich ein Schema ausgearbeitet, bei dem meine UI-Objekte unter einer ereignisgesteuerten Schnittstelle ausgeführt werden. Das heißt, ich habe etwas, das wie eine typische öffentliche Methode aussieht, die beim Abfeuern zu einer intern definierten Aktion führt. Aber wenn es ausgelöst wird, ist das, was wirklich passiert, dass ich ein Ereignis für das Objekt selbst auslöse und ein vordefinierter Handler in diesem Objekt reagiert. Dieses Ereignis und das Ereignisobjekt, an das Sie Eigenschaften anhängen können, die an einen anderen Listener übergeben werden, können von allen Benutzern abgehört werden, die das Abhören möchten. Sie können direkt auf das Objekt oder allgemein auf diesen Ereignistyp hören (Ereignisse werden auch für ein generisches Objekt ausgelöst, das von allen werkseitig erstellten Objekten gehört werden kann). Jetzt habe ich zum Beispiel ein Kombinationsfeld, in dem Sie ein neues Element aus der Dropdown-Liste auswählen können.

Wenn Sie möchten (und ich war überrascht, dass ich dies normalerweise nicht möchte - es ist ein Problem der Lesbarkeit, wenn Sie nicht sehen können, woher das Ereignis kommt), können Sie eine vollständige Objektentkopplung durchführen und den Kontext über ein übergebenes Ereignisobjekt herstellen. Unabhängig davon können Sie Single-Dispatch-Vorgängen immer noch ausweichen, indem Sie mehrere Responder registrieren.

Aber ich mache das nicht mit OOP alleine und JS ist nach einigen Definitionen nicht einmal 'richtig' OOP, was ich komisch finde. Richtig, für die höheren Ebenen der App-Entwicklung meiner Meinung nach, ist es die Macht, das Paradigma auf das zu biegen, was für Ihre Situation funktioniert, und wir können Klassen ganz gut emulieren, wenn es uns wichtig ist. Aber in diesem Fall mische ich Aspekte der Funktionalität (Weitergabe von Handlern) mit OOP.

Noch wichtiger ist, was ich habe, fühlt sich ziemlich mächtig an. Ich denke nicht daran, dass ein Objekt auf ein anderes wirkt. Ich entscheide im Grunde genommen, worauf es den Objekten ankommt, gebe ihnen die Werkzeuge, die sie zum Sortieren der Dinge benötigen, lege sie einfach in einen Mixer und lasse sie aufeinander reagieren.

Ich schätze, ich sage Folgendes: Es ist keine switch-Anweisung, sondern ein Problem. Es ist Mix and Match. Das Problem sind Sprachen und Modeerscheinungen, die Sie glauben lassen wollen, dass es eine Sache über alles ist. Wie kann zum Beispiel ein Java-Junior-Entwickler OOP wirklich schätzen, wenn er denkt, dass er es standardmäßig immer richtig macht?

Erik Reppen
quelle
2

Die Art, wie es mir erklärt wurde, war mit einem Toaster und einem Auto. Beide haben Federn, du hättest also ein "Feder" -Objekt und sie hätten unterschiedliche Größen, Stärken und was auch immer, aber sie wären beide "Federn" und würden dann diese Metapher auf das Auto übertragen, wenn du viele Räder hättest (Räder natürlich plus Lenkrad, ect) und das ergab sehr viel Sinn.

Sie können sich das Programm dann als eine Liste von Objekten vorstellen, und es ist viel einfacher zu visualisieren als "Es ist eine Liste von Dingen, die Dinge tun, also ist es nicht so wie die Liste von Anweisungen, die Sie zuvor gesehen haben".

Ich denke, das eigentliche Problem bei OOP ist, wie es den Leuten erklärt wird. Oft (in meinen Uni-Klassen) sehe ich, wie es erklärt wird, indem ich sage, "es geht um viele Klassen, die kleine Dinge tun, und man kann daraus Objekte erstellen", und das alles verwirrt viele Leute, weil es verwendet, was im Wesentlichen abstrakt ist Begriffe, um diese Konzepte zu erklären, und nicht konkrete Ideen, die Menschen im Alter von 5 Jahren beim Spielen mit Lego verstanden haben.

Trezoid
quelle
2
Federn gibt es in Millionen von Formen, die alle ähnliche Funktionen erfüllen . Ich würde sagen, dies ist ein perfektes Beispiel für funktionale Programmierung.
l0b0
2

Es ist die natürliche Art, die Welt durch Kategorisierung zu betrachten. Das ist mehr oder weniger das, worum es bei OO geht. OOP ist schwierig, weil das Programmieren schwierig ist.

Tom Hawtin - Tackline
quelle
Aber kategorisieren Sie, ob einige Objekte gemeinsame Attribute oder gemeinsame Verhaltensweisen haben? Ist alles, was Vor- und Nachnamen hat, eine Person? Ist alles, was geht, ein Tier?
Zvrba
Bei der Kategorisierung ist es ein Attribut, ein bestimmtes Verhalten ausführen zu können. Zebras und Pferde können sich fortpflanzen, aber die Nachkommen sind Hybriden. Es ist sehr schwierig, dieses Ergebnis aufgrund der Paarungsfunktion vorherzusagen, es sei denn, Sie wissen, dass es sich nicht um dieselbe Art handelt.
JeffO
1
@zvrba: Meine Antwort auf die Frage im Kommentar gestellt ist , dass it doesn't matter. Alles, was einen Vor- und Nachnamen hat, ist eine Person in jedem Programm, die sich nur um Menschen kümmert. Für jedes Programm, das keine Kenntnisse von Menschen oder Nicht-Menschen hat, ist es eine IHasNameAndSurname. Objekte müssen nur das vorliegende Problem lösen.
Tom W
@ Jeff O Auch innerhalb derselben Art / Rasse / Population gibt es Variationen und kein ideales (wesentliches) Beispiel. Also ja, OO ist nicht so, wie es die Natur eigentlich ist, aber es passt gut dazu, wie Menschen natürlich denken.
Tom Hawtin - Tackline
2

Ich denke, einige der Schwierigkeiten treten auf, wenn Leute versuchen, OOP zu verwenden, um die Realität darzustellen. Jeder weiß, dass ein Auto vier Räder und einen Motor hat. Jeder weiß , dass die Autos können Start(), Move()und SoundHorn().

Ein Licht ging in meinem Kopf an, als mir klar wurde, dass ich aufhören sollte, dies die ganze Zeit zu versuchen. Ein Objekt ist nicht das, womit es einen Namen teilt. Ein Objekt ist (dh sollte) eine ausreichend detaillierte Partition von Daten, die für den Umfang des Problems relevant sind. Es oughtmuss genau das geben, was die Lösung des Problems braucht, nicht mehr und nicht weniger. Wenn ein Objekt, das für ein bestimmtes Verhalten verantwortlich ist, mehr Codezeilen als dasselbe Verhalten zur Aufgabe eines nebulösen Dritten macht (manche nennen es möglicherweise einen "Poltergeist"), verdient der Poltergeist seine Chips.

Tom W
quelle
1

Um die Komplexität zu bewältigen, müssen wir die Funktionalität in Module gruppieren, und dies ist im Allgemeinen ein schwieriges Problem. Es ist wie das alte Sprichwort über den Kapitalismus: OOP ist das schlechteste System für die Organisation von Software, abgesehen von allem, was wir bisher versucht haben.

Der Grund, warum wir Interaktionen innerhalb der Substantive gruppieren, obwohl es häufig Unklarheiten darüber gibt, mit welchem ​​der beiden Substantive sie gruppiert werden sollen, ist, dass die Anzahl der Substantive sich zufällig auf handhabbare Klassen auswirkt, während die Gruppierung nach Verben in der Regel zu beidem führt sehr kleine gruppen wie einmalig oder sehr große gruppen für eine funktion wie show . Wiederverwendungskonzepte wie Vererbung funktionieren auch viel einfacher, wenn sie nach Substantiven gruppiert werden.

Auch die Frage, ob die Präsentation mit dem Fenster oder dem Text gezeigt werden soll, ist in der Praxis fast immer viel klarer als in der Theorie. Zum Beispiel fast all GUI - Toolkits Gruppe hinzufügen mit dem Behälter, sondern zeigt mit dem Widget. Wenn Sie versuchen, Code in die andere Richtung zu schreiben, wird der Grund ziemlich schnell offensichtlich, auch wenn die beiden Methoden, wenn Sie abstrakt darüber nachdenken, austauschbar erscheinen.

Karl Bielefeldt
quelle
2
Haben Sie jemals ein geeignetes Modulsystem gesehen? Wie kann man sagen, dass OOP das Beste ist, was es gibt? SML-Module sind sehr viel leistungsfähiger. Aber selbst Ada-Pakete reichen für die meisten Fälle aus, auch ohne einen Hauch von OOP.
SK-logic
@ SK-logic, ich glaube, Sie sind mit zu genauen Definitionen konfrontiert. Mit OOP meine ich keine Klassen , sondern die logische Gruppierung von "Verben" durch die "Substantive", mit denen sie arbeiten, und die Möglichkeit, diese Verben basierend auf den speziellen Substantiven, mit denen sie gerade arbeiten, wiederzuverwenden und zu spezialisieren. Klassen sind die bekannteste Implementierung davon, aber nicht die einzige Implementierung. Ich gebe zu, dass ich die SML-Module nicht kenne, aber das erste Beispiel, das ich beim Nachschlagen sah, war die Implementierung einer Warteschlange, die aus einem OO-Designbuch mit Syntaxänderungen stammen konnte, um es funktionsfähig zu machen.
Karl Bielefeldt
Es wäre einfach nicht fair, einem unglücklichen OOP für etwas, das nicht dazu gehört, zu viel Anerkennung zu zollen. Module sind eine großartige Erfindung. Erstklassige Module sind fantastisch. Aber OOP hat damit überhaupt nichts zu tun. Einige OOP-Sprachen haben einige der Modulfeatures übernommen (insbesondere Namespaces), aber Module sind viel allgemeiner und leistungsfähiger als Klassen. Sie sagten, der Unterricht sei "der Beste", was weit von der Wahrheit entfernt ist. Erstklassige Module sind viel besser. Und natürlich sind Typsysteme viel breiter und tiefer als nur ein OO mit seinem Subtyping-Ding.
SK-logic
1
"Es ist wie das alte Sprichwort über den Kapitalismus, OOP ist das schlechteste System zum Organisieren von Software, abgesehen von allem, was wir bisher versucht haben.": Vielleicht haben wir es nicht lange genug versucht. :-)
Giorgio
1
Ich denke, Sie meinen "Demokratie": quotationspage.com/quote/364.html
nicodemus13
1

Nein . Es gibt verschiedene Möglichkeiten, ein Problem mithilfe der Programmierung zu lösen: funktional, prozedural, logisch, OOP usw.

In der realen Welt verwenden die Menschen manchmal das funktionale Paradigma und manchmal das prozedurale Paradigma und so weiter. Und manchmal haben wir verwechselt. Und schließlich repräsentieren wir sie als einen bestimmten Stil oder ein bestimmtes Paradigma der Programmierung.

Es gibt auch das in LISP verwendete Paradigma "Alles ist eine Liste oder ein Element". Ich möchte etwas anderes erwähnen als funktionale Programmierung . PHP verwendet das in assoziativen Arrays.

OOP- und "Everything is a list or item" -Paradigmen werden als zwei der NATÜRLICHEREN Programmierstile betrachtet, an die ich mich in einigen Klassen der künstlichen Intelligenz erinnere.

Klingt für mich seltsam, "OOP ist nicht natürlich", vielleicht ist die Art und Weise, wie Sie lernen oder wie Sie über OOP unterrichtet wurden, falsch, aber nicht OOP selbst.

umlcat
quelle
1

Wie / warum ist es angesichts dieser Probleme dazu gekommen, dass der derzeitige Mainstream-Ansatz der OOP so populär wurde? Und was kann getan werden, um es zu entthronen?

OOP wurde populär, weil es Tools bietet, mit denen Sie Ihr Programm auf einer höheren Abstraktionsebene organisieren können als in den bekannten Verfahrenssprachen, die davor standen. Es war auch relativ einfach, eine Sprache zu erstellen, die innerhalb der Methoden eine prozedurale Struktur und eine sie umgebende objektorientierte Struktur aufwies. So konnten Programmierer, die bereits wissen, wie man prozedural programmiert, nacheinander die OO-Prinzipien aufgreifen. Dies führte auch zu vielen OO-in-Name-Programmen, bei denen es sich um prozedurale Programme handelte, die in eine oder zwei Klassen eingeschlossen waren.

Um OO zu entthronen, erstellen Sie eine Sprache, die es einfach macht, schrittweise von dem, was die meisten Programmierer heute kennen (meistens prozedural, mit ein wenig OO), zu Ihrem bevorzugten Paradigma überzugehen. Stellen Sie sicher, dass es praktische APIs für allgemeine Aufgaben bietet, und fördern Sie es gut. Die Leute werden in Kürze X-in-Name-Programme in Ihrer Sprache erstellen. Dann kann man davon ausgehen, dass es Jahre und Jahre dauert, bis die Leute gut darin sind, tatsächlich X zu machen.

Sean McMillan
quelle
Das OP argumentiert nicht, dass OO generell schlecht ist und entthront werden sollte, aber dass die "derzeit gängige Art, OOP zu machen" nicht die natürlichste ist (im Vergleich zu "Mehrfachversand").
Giorgio
OP scheint sich auch zu sehr auf die Definition der Typhierarchie zu konzentrieren, bei der die besten OO-Programme eher auf Schnittstellen und Komposition setzen. Wenn der Mehrfachversand auf X festgelegt ist, ist die Erstellung einer Sprache, in der die mit dem Mehrfachversand verbundenen Fähigkeiten schrittweise erlernt werden, immer noch der Schlüssel zum Ändern der Umgebung.
Sean McMillan
1

Ich denke, die OOP- und OOP-Sprachen haben auch Probleme.

Wenn Sie es richtig verstehen, handelt es sich bei OOP um Black Boxes (Objekte), auf denen sich Drucktasten befinden, die gedrückt werden können (Methoden). Klassen sind nur da, um diese Blackboxen zu organisieren.

Ein Problem ist, wenn der Programmierer die Druckknöpfe auf das falsche Objekt legt. Das Terminal kann keinen Text auf sich selbst anzeigen, der Text kann sich nicht auf dem Terminal anzeigen. Die Fenstermanagerkomponente des Betriebssystems, die dies ausführen kann. Terminalfenster und -text sind nur eine passive Einheit. Aber wenn wir so denken, erkennen wir, dass die meisten Entitäten passive Dinge sind und wir nur sehr wenige Objekte haben, die tatsächlich etwas tun (oder einfach nur eines: den Computer ). In der Tat, wenn Sie C verwenden, organisieren Sie es in Module, diese Module repräsentieren die wenigen Objekte.

Ein weiterer Punkt ist, dass der Computer die Anweisungen nur nacheinander ausführt. Nehmen wir an, Sie haben ein VCRund ein TelevisionObjekt. Wie würden Sie ein Video abspielen? Sie schreiben wahrscheinlich so etwas:

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();

Dies wäre so einfach, aber Sie würden mindestens 3 Prozessoren ( oder Prozesse ) dafür benötigen : einer spielt die Rolle von Ihnen, der zweite ist der Videorecorder, der dritte ist der Fernseher. Aber normalerweise hast du nur einen Kern (zumindest nicht genug für alle deine Objekte). Im College haben viele meiner Klassenkameraden nicht verstanden, warum die GUI einfriert, wenn ein Druckknopf eine teure Operation ausführt.

Daher denke ich, dass ein objektorientiertes Design die Welt recht gut beschreibt, aber es ist nicht die beste Abstraktion für den Computer.

Calmarius
quelle
0

Werfen Sie einen Blick auf DCI (Daten, Kontext und Interaktion), die vom Erfinder des MVC-Musters erfunden wurden.

Das Ziel von DCI ist (aus Wikipedia zitiert):

  • Geben Sie dem Systemverhalten einen erstklassigen Status über Objekten (Substantiven).
  • Sauberes Trennen von Code zur schnellen Änderung des Systemverhaltens (was das System tut) von Code zur langsamen Änderung des Domänenwissens (was das System ist), anstatt beide in einer Klassenschnittstelle zu kombinieren.
  • Unterstützung eines objektorientierten Denkstils, der eher den mentalen Vorbildern der Menschen als dem klassenorientierten Denkstil entspricht.

Hier ist ein guter Artikel der Autoren und hier ist eine kleine Beispielimplementierung (.NET), wenn Sie Code sehen möchten. Es ist viel einfacher als es sich anhört und fühlt sich sehr natürlich an.

Vater
quelle
0

Man kann oft hören, dass OOP natürlich der Art und Weise entspricht, wie Menschen über die Welt denken. Aber ich würde mit dieser Aussage überhaupt nicht einverstanden sein (...)

Da es seit Jahrzehnten in Büchern und anderswo evangelisiert wird, bin ich auch nicht damit einverstanden. Trotzdem denke ich, dass Nygaard und Dahl das so ausgedrückt haben, und ich denke, sie haben sich darauf konzentriert, wie einfach es war, Simulationen im Vergleich zu den Alternativen der Zeit zu entwerfen.

(...) aber der Fokus von OOP liegt auf der Gestaltung einzelner Klassen und ihrer Hierarchien.

Diese Behauptung betritt ein vernünftiges Territorium, da die gängigen Missverständnisse in Bezug auf OOP bestehen und die Definition von OO empfindlich ist. Ich bin seit mehr als zehn Jahren in diesem Bereich tätig und arbeite sowohl in der Industrie als auch in der akademischen Forschung mit Prog. Ich kann Ihnen sagen, dass ich viele Jahre damit verbracht habe, "Mainstream OO" zu verlernen, weil ich bemerkte, wie unterschiedlich (und minderwertig) es von dem ist, was die früheren Schöpfer anstrebten. Für eine moderne, aktuelle Behandlung des Themas verweise ich auf die jüngsten Bemühungen von W. Cook:

"Ein Vorschlag für vereinfachte, moderne Definitionen von" Objekt "und" objektorientiert " http://wcook.blogspot.com.br/2012/07/proposal-for-simplified-modern.html

Wie / warum ist es angesichts dieser Probleme dazu gekommen, dass der derzeitige Mainstream-Ansatz der OOP so populär wurde?

Vielleicht aus demselben Grund, aus dem QWERTY-Tastaturen populär wurden, oder aus demselben Grund, aus dem das DOS-Betriebssystem populär wurde. Die Dinge werden trotz ihrer Eigenschaften nur mit beliebten Fahrzeugen gefahren und selbst populär. Und manchmal werden ähnliche, aber schlechtere Versionen von etwas als die eigentliche Sache angesehen.

Und was kann getan werden, um es zu entthronen?

Schreiben Sie ein Programm mit einem überlegenen Ansatz. Schreiben Sie dasselbe Programm mit einem OO-Ansatz. Zeigen Sie, dass Ersteres in jeder Hinsicht bessere Eigenschaften aufweist als Letzteres (sowohl die Eigenschaften des Systems selbst als auch die technischen Eigenschaften). Zeigen Sie, dass das ausgewählte Programm relevant ist und der vorgeschlagene Ansatz die hohe Qualität der Eigenschaften beibehält, wenn er auf andere Arten von Programmen angewendet wird. Seien Sie bei Ihrer Analyse streng und verwenden Sie bei Bedarf präzise und akzeptierte Definitionen.

Teilen Sie uns abschließend Ihre Erkenntnisse mit.

Thiago Silva
quelle
-1

Nehmen wir Java: Objekte sind eine Art Abstraktionsengpass, die meisten "Dinge" sind entweder reine Unterkomponenten von Objekten oder verwenden Objekte als Unterkomponenten. Objekte müssen für eine ganze Abstraktionsschicht zwischen diesen beiden Arten von Dingen vielseitig genug sein - Mehrzweck bedeutet, dass es keine einzige Metapher gibt, die sie verkörpern. Insbesondere macht Java Objekte (& Klassen) zur einzigen Ebene, über die Sie Code aufrufen / versenden. Diese Menge an Dingen, die Objekte verkörpern, macht sie offen gesagt viel zu komplex. Jede nützliche Beschreibung muss auf eine spezielle oder eingeschränkte Form beschränkt sein.

Die Vererbungs- und Schnittstellenhierarchien sind "Dinge", die Objekte als Unterkomponenten verwenden. Dies ist eine spezielle Methode zur Beschreibung von Objekten, keine Methode, um ein allgemeines Verständnis von Objekten herzuleiten.

Man kann sagen, dass "Objekte" viele Dinge haben oder sein, weil sie eine Mehrzweckabstraktion sind, die in einer "OO-Sprache" mehr oder weniger universell ist. Wenn sie verwendet werden, um einen lokalen veränderlichen Zustand zu enthalten oder auf einen Zustand der Außenwelt zuzugreifen, ähneln sie sehr einem "Nomen".

Im Gegensatz dazu sieht ein Objekt, das einen Prozess darstellt, z. B. "Verschlüsseln" oder "Komprimieren" oder "Sortieren", wie ein "Verb" aus.

Einige Objekte werden für ihre Rolle als Namespace verwendet, z. B. um "statische" Funktionen in Java zu platzieren.

Ich bin geneigt, dem Argument zuzustimmen, dass Java bei Objektmethodenaufrufen mit Dispatch für das Objekt zu umfangreich ist. Dies liegt wahrscheinlich daran, dass ich Haskells Typklassen für die Versandsteuerung bevorzuge. Dies ist eine Versandbeschränkung und eine Funktion von Java, jedoch nicht die meisten Sprachen oder sogar die meisten OO-Sprachen.

Chris Kuklewicz
quelle
-3

Ich habe viele Online-Debatten über OOP miterlebt und daran teilgenommen. Die Befürworter von OOP wissen normalerweise nicht, wie man richtigen Prozedurcode schreibt. Es ist möglich, sehr modularen Prozedurcode zu schreiben. Es ist möglich, Code und Daten zu trennen und sicherzustellen, dass Funktionen nur in ihren eigenen Datenspeicher schreiben können. Es ist möglich, das Konzept der Vererbung mithilfe von Prozedurcode zu implementieren. Noch wichtiger ist, dass der prozedurale Code schlanker, schneller und einfacher zu debuggen ist.

Wenn Sie Single-File-Module mit strengen Namenskonventionen erstellen, ist der prozedurale Code einfacher zu schreiben und zu pflegen als OO, und das gleiche oder mehr und schneller. Und vergessen Sie nicht, dass die Ausführung Ihrer Anwendung immer prozedural ist, unabhängig davon, wie viele Klassen in Ihrem Skript enthalten sind.

Dann haben Sie das Problem von Sprachen wie PHP, die nicht wirklich objektorientiert sind und sich auf Hacks verlassen, um Dinge wie Mehrfachvererbung zu fälschen. Die großen Schüsse, die die Richtung der Sprache beeinflussen, haben PHP zu einem Flickenteppich inkonsistenter Regeln gemacht, die zu groß für das geworden sind, was es ursprünglich beabsichtigte. Wenn ich sehe, dass Entwickler umfangreiche Vorlagenklassen für eine prozedurale Vorlagensprache schreiben, muss ich lächeln.

Wenn Sie richtig geschriebenen OO-Code mit schlecht geschriebenem Prozedurcode vergleichen, kommen Sie immer zu einer falschen Schlussfolgerung. Sehr wenige Projekte erfordern ein objektorientiertes Design. Wenn Sie IBM sind und ein großes Projekt verwalten, das mehrere Entwickler jahrelang warten müssen, entscheiden Sie sich für objektorientiert. Wenn Sie einen kleinen Blog oder eine Shopping-Website für einen Kunden schreiben, denken Sie zweimal darüber nach.

Zur Beantwortung der ursprünglichen Frage ist OOP schwierig, da es keine realen Programmierprobleme löst, ohne auf Lösungen zurückzugreifen, die hundertmal komplizierter sind, als sie sein sollten. Eine der wirksamsten Lösungen für viele Programmierprobleme ist der umsichtige Umgang mit globalen Daten. Doch die New-Wave-Hochschulabsolventen werden Ihnen sagen, dass es ein großes Nein-Nein ist. Global verfügbare Daten sind nur dann gefährlich, wenn Sie ein ungeschickter Programmierer sind. Wenn Sie über strenge Regeln und korrekte Namenskonventionen verfügen, können Sie es vermeiden, dass alle Ihre Daten global sind.

Es sollte für jeden objektorientierten Programmierer eine obligatorische Anforderung sein, zu wissen, wie eine Schachspielanwendung in Assembler für einen maximal verfügbaren Speicher von 16 KB geschrieben wird. Sie würden dann lernen, wie man das Fett trimmt, die Faulheit schneidet und geniale Lösungen generiert.

JG Estiot
quelle