Was ist mit "OOP verbirgt den Staat" gemeint? [geschlossen]

11

In einem von vielen Anti-OOP-Rants auf cat-v.org fand ich eine Passage von Joe Armstrong, die mehrere Einwände gegen das OOP-Modell erhob, von denen einer der folgenden war:

Einwand 4 - Objekte haben einen privaten Zustand

Staat ist die Wurzel allen Übels. Insbesondere Funktionen mit Nebenwirkungen sollten vermieden werden.

Während der Zustand in Programmiersprachen unerwünscht ist, gibt es in der realen Welt einen Überfluss. Ich interessiere mich sehr für den Status meines Bankkontos. Wenn ich Geld von meiner Bank einzahle oder abhebe, erwarte ich, dass der Status meines Bankkontos korrekt aktualisiert wird.

Welche Möglichkeiten sollte die Programmiersprache angesichts des Zustands in der realen Welt für den Umgang mit dem Staat bieten?

OOPLs sagen "verstecke den Status vor dem Programmierer". Die Zustände sind nur durch Zugriffsfunktionen verborgen und sichtbar. Herkömmliche Programmiersprachen (C, Pascal) besagen, dass die Sichtbarkeit von Zustandsvariablen durch die Bereichsregeln der Sprache gesteuert wird. Reine deklarative Sprachen sagen, dass es keinen Staat gibt. Der globale Zustand des Systems wird in alle Funktionen übertragen und geht aus allen Funktionen hervor. Mechanismen wie Monaden (für FPLs) und DCGs (Logiksprachen) werden verwendet, um den Status vor dem Programmierer zu verbergen, damit sie "so programmieren können, als ob der Status keine Rolle spielt", aber vollen Zugriff auf den Status des Systems haben, falls dies erforderlich sein sollte.

Die von OOPLs gewählte Option "Status vor dem Programmierer ausblenden" ist die schlechtere Option. Anstatt den Staat zu enthüllen und nach Wegen zu suchen, um die Belästigung des Staates zu minimieren, verstecken sie ihn.

Was genau ist damit gemeint? Ich habe sehr wenig Erfahrung auf niedrigem Niveau oder in Verfahren, meistens OOP, was wahrscheinlich erklärt, wie wenig ich damit vertraut bin. Und von einem moderneren Standpunkt aus, nachdem der größte Teil der objektorientierten Hysterie überwunden ist (zumindest soweit ich das beurteilen kann), wie genau / relevant halten Sie diese Passage?

Danke für Ihre Hilfe.

Jake
quelle
3
Empfohlene Lektüre: Besprechen Sie dieses $ {blog}
Mücke
1
Wenn Sie mich fragen, enthält der Artikel, auf den Sie verlinkt haben, einige ziemlich schlechte Argumente (ganz zu schweigen von der Qualität des Schreibens). Ich würde nicht zu viel Wert darauf legen, was es zu sagen hat.
Benjamin Hodgson
1
Bah. Immer mehr denke ich, dass diese ganze "unveränderliche" Sache eine gute Idee ist, die anfängt, nach Religion zu stinken.
Rob
3
Joe Armstrong hat öffentlich anerkannt, dass seine Einwände gegen OO auf schwerwiegenden Missverständnissen darüber beruhten, was OO genau ist. Er hat jetzt erkannt, dass Erlang tatsächlich eine zutiefst objektorientierte Sprache ist (tatsächlich könnte es die objektorientierteste Sprache im Mainstream-Gebrauch sein).
Jörg W Mittag
9
Um das zu erweitern: Die erste Aufnahme von Joe Armstrongs Schimpfen auf archive.org stammt aus dem April 2001. Joe schrieb seine Diplomarbeit im Jahr 2003. Während des Schreibens seiner Diplomarbeit lernte er viel über OO und stellte fest, dass er dem zum Opfer gefallen war häufiges Missverständnis, dass OO irgendwie mit dem veränderlichen Zustand zusammenhängt (es ist nicht so, der veränderliche Zustand ist vollständig orthogonal). Seitdem hat er anerkannt, dass seine Kritik an OO falsch war und dass Erlang ironischerweise tatsächlich eine objektorientierte Sprache ist (sie hat Nachrichten, sie hat Objekte, die sie Prozesse nennt, sie hat Kapselung).
Jörg W Mittag

Antworten:

32

Was genau ist damit gemeint?

In diesem Zusammenhang bedeutet dies, dass OOP den Status eines Programms verdeckt, indem es es vor dem Programmierer verbirgt, es aber dennoch über (undichte) Zugriffsmethoden sichtbar macht. Das Argument ist, dass es durch die Verschleierung des Staates schwieriger wird, mit ihm zu arbeiten, und im weiteren Sinne zu mehr Fehlern führt.

Wie genau / relevant findet ihr diese Passage?

Ich halte es für relevant, aber fehlgeleitet. Es ist absolut problematisch, wenn Ihre Klasse das Konzept ihres Zustands nach außen überträgt. Es gibt absolut ein Problem, wenn Ihre Klasse versucht, den Zustand zu verschleiern, wenn er von der Außenwelt manipuliert werden sollte. Dies ist jedoch kein Versagen von OOP als Ganzes, sondern mit dem individuellen Design der Klasse. Ich würde nicht sagen, dass das Verstecken des Zustands selbst ein Problem ist - Monaden tun dies ständig in der funktionalen Programmierung.

Im besten Fall funktioniert OOP wie die beste Mischung aus funktionaler Programmierung und Prozedur - Menschen können die Klasse verwenden, "als ob der Staat keine Rolle spielt", weil der private Staat, der zum Schutz der Invarianten der Klasse verwendet wird, verborgen ist, aber Freiheit hat einen genau definierten öffentlichen Zustand der Klasse zu verwenden, der die Details abstrahiert.

Erschwert OOP es den Menschen, diese besten Fälle zu erreichen? Möglicherweise. "Java-Schulen" und die gesamte Form / Kreis / Rechteck oder Auto hat Wheels School of Teaching OO haben wahrscheinlich mehr Schuld als der Ansatz selbst. Das moderne OOP nimmt einiges von der funktionalen Programmierung in Anspruch, fördert unveränderliche Objekte und reine Funktionen und entmutigt die Vererbung, um das Entwerfen von Klassen, die gut funktionieren, zu vereinfachen.

Telastyn
quelle
3
Ich stimme voll und ganz der ganzen "Java-Schule" zu, mag das überhaupt nicht, heh. Vielen Dank, ich würde abstimmen, wenn ich könnte.
Jake
2
Um genau zu sein: Monaden verstecken den Zustand im Allgemeinen nicht, manche Monaden (z. B. IO). Siehe unter anderem stackoverflow.com/questions/2488646/…
thSoft
2
+1. Dies ist eine weitaus ausgewogenere und differenziertere Analyse als der Artikel, den der Fragesteller verlinkt hat
Benjamin Hodgson,
2
Joe Armstrong hat öffentlich anerkannt, dass seine Einwände gegen OO auf schwerwiegenden Missverständnissen darüber beruhten, was OO genau ist. Er hat jetzt erkannt, dass Erlang tatsächlich eine zutiefst objektorientierte Sprache ist (tatsächlich könnte es die objektorientierteste Sprache im Mainstream-Gebrauch sein).
Jörg W Mittag
2
Jorg - könntest du einen Link zu Joes Follow-up posten? Es würde mich sehr interessieren, es zu lesen. Und @radarbob, genau richtig!
user949300
2

Es wird schwierig sein, über ein System nachzudenken, wenn es veränderbare Zustände gibt, die keinen einzigen eindeutigen "Eigentümer" haben. Das bedeutet nicht, dass Objekte niemals einen veränderlichen Zustand haben sollten, sondern dass Objekte, die einen veränderlichen Zustand haben, nicht auf eine Weise verwendet werden sollten, bei der das Eigentum möglicherweise unklar ist, und umgekehrt, dass Objekte, die frei weitergegeben werden müssen, ohne das Eigentum zu verfolgen, dies tun sollten unveränderlich sein.

In der Praxis erfordert eine effiziente Programmierung häufig, dass einige Objekte einen veränderlichen Zustand haben. Ein solcher Zustand sollte jedoch auf nicht gemeinsam genutzte Arbeiterobjekte beschränkt sein. Betrachten Sie die IEnumerable/ IEnumerator-Schnittstellen in .NET: Wenn eine Sammlung implementiert IEnumerablewird, können die Elemente einzeln ausgelesen werden. Der eigentliche Prozess des Auslesens einer Sammlung erfordert häufig das Verfolgen, welche Elemente gelesen wurden (ein Stück veränderlichen Zustands), aber ein solcher Zustand ist nicht in einer Implementierung von enthalten IEnumerable. Stellt stattdessen IEnumerableeine aufgerufene Methode bereit, GetEnumeratordie ein Objekt zurückgibt, IEnumeratordas genügend Status implementiert und enthält, damit Elemente aus der Sammlung ausgelesen werden können. Die Tatsache, dass das Objekt einen solchen Zustand enthält, ist jedoch kein ProblemWenn die Objektimplementierung IEnumeratornicht freigegeben ist .

In den meisten Fällen besteht das beste Muster darin, eine Mischung aus Objekten zu verwenden, die frei geteilt werden, aber niemals geändert werden (zumindest nicht, nachdem sie geteilt wurden), und Objekten, die einen eindeutigen Eigentümer haben und von diesem Eigentümer frei geändert werden können , werden aber nie mit jemandem geteilt.

Superkatze
quelle
Hervorragende Unterscheidung zwischen unveränderlichem und veränderlichem Zustand. Als ich dies las, stellte ich fest, dass meine neueren Objektgraphen (unveränderlicher als früher) im Wesentlichen dieser Richtlinie folgen, ohne dass sie so klar angegeben wurden wie Sie. Dies ist ein gutes moderates Gegenmittel gegen den "veränderlichen Zustand ist immer böse" -Hogwash, den Sie manchmal hören.
Mike unterstützt Monica
@ Mike: Ich denke, das eigentliche Problem ist, dass alle Objektreferenzen in Java und .NET vollständig promiskuitiv sind. Jeder Code, der einen Verweis auf ein Objekt erwirbt oder empfängt, kann ihn ohne Einschränkung mit jedem anderen Code teilen. Kein Framework hat ein Konzept für ein nicht gemeinsam nutzbares Referenzfeld. Strukturen und Byrefs in .NET kommen sich nahe, aber sie sind in Bezug auf ihre Möglichkeiten oder die Verhinderung von externem Code eher eingeschränkt. Auf jeden Fall würde ich ein grundlegendes Sprichwort in Bezug auf den veränderlichen Zustand
vorbringen
... den gegenwärtigen Zustand eines realen Objekts und den Zustand, den das Objekt um 00:57 Uhr hatte. Wenn sich der reale Zustand des Objekts ändert, kann ein Objekt nicht mehr beide darstellen. Manchmal muss das Objekt weiterhin den Zustand 00:57 und manchmal den gegenwärtigen Zustand darstellen. Die Beziehung zwischen dem Zustand 00:57 Uhr und dem gegenwärtigen Zustand kann jedoch nicht bestehen bleiben, wenn sich der gegenwärtige Zustand ändert.
Supercat
0

Auf die Gefahr hin, über die Beantwortung der Frage hinauszugehen, ist es leicht, Fehler in der Idee von OOP zu erkennen, aber ich neige dazu zu glauben, dass sich die Kraft einer Idee in ihrer Fähigkeit widerspiegelt, missbraucht zu werden.

Schließlich hat jeder seine Lieblingssprache, die er mit Begriffen wie "sehr sehr mächtig" beschreibt, was bedeutet, dass er sie wirklich wirklich mag . Das Wunder der rechnerischen Universalität ist jedoch, dass eine Sprache, egal wie großartig sie ist, Assemblersprache simulieren kann, wenn sie wirklich mächtig ist. Und wenn es geht, wird jemand sehen, dass es funktioniert. (Nicht, dass irgendetwas mit der Assemblersprache nicht stimmt.)

Mein persönliches Gefühl in Bezug auf den OOP-Zug ist, dass er die Ausbildung der Menschen in Software-Engineering / Informatik beeinträchtigt. Sie sind auf einer Ebene verkümmert, auf der sie denken, dass es nur um Datenstruktur geht. Klassen, Vererbung, Container, Iteratoren, Hash-Maps, Eigenschaften, Ausblenden von Status usw. - alles über Datenstruktur - je mehr desto besser.

Ich persönlich würde gerne ein nächstes Level sehen, in dem die Leute lernen würden, Probleme zu lösen, indem sie sie sprachlich betrachten. Wo sie das Konzept domänenspezifischer Sprachen verstehen würden, wie man sie einfach herstellt und ihre Erstellung zu einem integralen Bestandteil der Problemlösung macht. Es ist nicht falsch zu sagen , dass eine Datenstruktur ist eine Sprache. Die Leute sollten diese Fähigkeit des Sprachdesigns haben, damit sie nicht nur durch sie stöbern.

Dann würde ich mir als nächstes Level eine Wiederbelebung der künstlichen Intelligenz wünschen. Ich würde gerne sehen, wie Programmierer über Bytes und Threads und virtuelle Funktionstabellen und CUDAs hinausgehen und sich damit befassen, wie Maschinen zum Nachdenken, Lernen und Erstellen gebracht werden. Ich weiß, dass dies in kleinen Ecken des Feldes sehr weit fortgeschritten ist, aber bei weitem nicht weit genug.

Mike Dunlavey
quelle
1
"Wenn es wirklich mächtig ist, kann es Assemblersprache simulieren" - Sie tauschen die Definition von powerfulgenau dort aus. Wenn andere sagen powerful, sprechen sie darüber, wie gut es Programmierern ermöglicht, zu abstrahieren , was eine andere Geschichte ist als Rechenleistung .
Phil
@Phil: Zusammenfassung ist ein anderes dieser Wörter :)
Mike Dunlavey
Nein, nein. Du hast über Worte gesprochen. Ich habe über Ideen gesprochen. Ihre 2. und 3. Verwendung des Wortes powerbedeuten verschiedene Dinge. Bitte nicht irreführen.
Phil
Übrigens, wenn Sie interessiert sind, schauen Sie sich Racket an , was dem Ansatz, den Sie in Ihrem vierten Absatz sagen, ziemlich nahe kommt (damit Programmierer die Sprache auf das Niveau ihres Problems bringen können, anstatt sie dazu zu bringen, ihr Problem auf das Problem zu bringen feste Konstrukte der Sprache). Es geht weit über das klassische Lisp / Schema hinaus, nur für den Fall, dass jemand diesen Eindruck hat, wenn er es zum ersten Mal betrachtet.
Phil
0

Die Barrierefreiheit ist keine Funktion von OOP, sondern spezifisch für Implementierungen wie Java und Microsoft dotNET. Das Hauptmerkmal, das OOP definiert, ist Polymorphismus.

Wenn Sie den Objektstatus ausblenden, können Sie keine aussagekräftige API erstellen. Die Präsentation ist ein wesentlicher Bestandteil der realen OOP. Diejenigen, die nicht einverstanden sind, haben wahrscheinlich eine irrationale Feindseligkeit gegenüber der Softwareindustrie, was ihre Meinung aus meiner Sicht irrelevant macht.

Websites wie die, die Sie verlinkt haben, sind bekannt für extrem starre Gedanken und Kritik an neuen Technologien. Manche Leute verstehen es einfach nicht.

Leopold Asperger
quelle
Es sollte ein Objekt vorhanden sein, um die Invarianten des von ihm modellierten Konzepts zu schützen. Die Präsentation ist ein völlig eigenständiges Anliegen und kann nicht effizient und wartbar von demselben Objekt gehandhabt werden, da ein Objekt nicht alle verschiedenen Arten verstehen kann, wie es über Zeit und Raum präsentiert werden kann. Die Präsentation muss über einen anderen Mechanismus wie Ereignis-Streaming und materialisierte Ansichten erfolgen, wenn Ihr Ziel vielseitige, wartbare Objekte sind. Ein Objekt sollte sich nur ändern, wenn sein Konzept überarbeitet oder seine Invarianten geändert werden.
Andrew Larsson