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

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.

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.

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.

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.

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.