Vergessene Geschichte von OOP

Die meisten der heute verwendeten Programmierparadigmen wurden erstmals in den 1930er Jahren mathematisch untersucht, wobei die Ideen der Lambda-Rechnung und der Turing-Maschine verwendet wurden, die Varianten des universellen Rechenmodells sind (dies sind formalisierte Systeme, die Allzweckberechnungen durchführen können). Die Church-Turing-These zeigte, dass Lambda-Kalkül und Turing-Maschinen funktional gleichwertig sind. Wir sprechen nämlich von der Tatsache, dass alles, was mit einer Turing-Maschine berechnet werden kann, auch mit Lambda-Kalkül berechnet werden kann und umgekehrt.



Es gibt ein weit verbreitetes Missverständnis, dass Turing-Maschinen alles berechnen können, was berechnet werden kann. Es gibt Problemklassen (z. B. das Problem des Stoppens ), die nur in einigen Fällen mit Turing-Maschinen berechnet werden können. Wenn das Wort "rechnerisch" in diesem Text verwendet wird, bedeutet es "rechnerisch durch eine Turingmaschine".

Die Lambda-Rechnung demonstriert den Ansatz, Funktionen von oben nach unten auf Berechnungen anzuwenden. Eine Turing-Bandmaschine ist ein zwingender (schrittweiser) Ansatz für die Datenverarbeitung, der von unten nach oben implementiert wird.

Low-Level-Programmiersprachen wie Maschinencode oder Assembler erschienen in den 1940er Jahren, und Ende der 1950er Jahre entstanden die ersten populären Hochsprachen, die sowohl funktionale als auch zwingende Ansätze implementierten. Daher sind Dialekte der Lisp-Sprache immer noch weit verbreitet, darunter Clojure, Scheme, AutoLisp und so weiter. In den fünfziger Jahren erschienen Sprachen wie FORTRAN und COBOL. Sie sind Beispiele für zwingende Hochsprachen, die noch leben. Obwohl anzumerken ist, dass die Sprachen der C-Familie in den meisten Bereichen sowohl COBOL als auch FORTRAN ersetzten.

Die Wurzeln der imperativen und funktionalen Programmierung liegen in der formalen Mathematik des Rechnens, sie erschienen vor digitalen Computern. Die objektorientierte Programmierung (Object Oriented Programming, OOP) entstand später in der Revolution der strukturellen Programmierung, die in den sechziger und siebziger Jahren des letzten Jahrhunderts stattfand.

Das erste Objekt, das ich kannte, wurde von Ivan Sutherland in seiner schicksalhaften Anwendung Sketchpad verwendet, die zwischen 1961 und 1962 erstellt wurde und die er 1963 in dieser Arbeit beschrieb. Objekte waren grafische Zeichen, die auf dem Oszilloskopbildschirm angezeigt wurden (möglicherweise ist dies das erste Mal in der Geschichte der Verwendung eines grafischen Computermonitors), die die Vererbung durch dynamische Delegierte unterstützen, die Ivan Sutherland in seiner Arbeit als „Meister“ bezeichnete. Jedes Objekt könnte ein Master-Objekt werden, zusätzliche Instanzen des Objekts wurden als "Vorkommen" bezeichnet. Dies machte das Sketchpad-System zum Besitzer der ersten der berühmten Programmiersprachen, die die Vererbung von Prototypen implementierten.

Die erste Programmiersprache, allgemein als "objektorientiert" bekannt, war die Simula-Sprache, deren Spezifikationen 1965 entwickelt wurden. Wie Sketchpad ermöglichte Silmula die Arbeit mit Objekten, umfasste jedoch auch Klassen, klassenbasierte Vererbung, Unterklassen und virtuelle Methoden.

Eine virtuelle Methode ist eine Methode, die in einer Klasse definiert ist und von Unterklassen neu definiert werden soll. Mit virtuellen Methoden können Programme Methoden aufrufen, die zum Zeitpunkt der Kompilierung des Codes möglicherweise nicht vorhanden sind, indem mithilfe des dynamischen Versands festgelegt wird, welche bestimmte Methode während der Programmausführung aufgerufen werden soll. JavaScript hat dynamische Typen und verwendet eine Delegierungskette, um zu bestimmen, welche Methode aufgerufen werden soll. Daher muss diese Sprache Programmierern das Konzept virtueller Methoden nicht vorstellen. Mit anderen Worten, alle Methoden in JavaScript verwenden den Versand zur Laufzeit. Daher müssen Methoden in JavaScript nicht als "virtuell" deklariert werden, um diese Funktion zu unterstützen.

Meinung des OOP-Vaters zu OOP

"Ich habe den Begriff" objektorientiert "geprägt und kann sagen, dass ich nicht C ++ gemeint habe." Alan Kay, OOPSLA-Konferenz, 1997.

Alan Kay prägte den Begriff "objektorientierte Programmierung" und bezog sich dabei auf die Programmiersprache Smalltalk (1972). Diese Sprache wurde von Alan Kay, Dan Ingles und anderen Mitarbeitern des Xerox PARC Research Center im Rahmen des Dynabook-Geräteprojekts entwickelt. Smalltalk war objektorientierter als Simula. In Smalltalk ist alles ein Objekt, einschließlich Klassen, Ganzzahlen und Blöcke (Abschlüsse). Die anfängliche Implementierung der Sprache, Smalltalk-72, war nicht in der Lage, Unterklassen zu erstellen. Diese Funktion wurde in Smalltalk-76 angezeigt.

Während Smalltalk Klassen und damit Unterklassen unterstützte, stellte Smalltalk diese Ideen nicht in den Vordergrund. Es war eine funktionale Sprache, die Lisp genauso beeinflusste wie Simula. Laut Alan Kay ist es ein Fehler, Klassen als Mechanismus zur Wiederverwendung von Code zu behandeln. Die Programmierbranche legt großen Wert auf die Erstellung von Unterklassen, die von den tatsächlichen Vorteilen der objektorientierten Programmierung ablenken.

JavaScript und Smalltalk haben viel gemeinsam. Ich würde sagen, dass JavaScript Smalltalks Rache an der Welt ist, weil er die Konzepte von OOP missverstanden hat. Beide Sprachen unterstützen die folgenden Funktionen:

• Objekte
• Erstklassige Funktionen und Verschlüsse.
• Dynamische Typen.
• Späte Bindung (Funktionen und Methoden können während der Programmausführung ersetzt werden).
• OOP ohne klassenbasiertes Vererbungssystem.

„Ich bedauere, dass ich vor langer Zeit den Begriff„ Objekte “für dieses Phänomen erfunden habe, da seine Verwendung dazu führt, dass viele Menschen einer Idee, die nicht so wichtig ist wie die Hauptidee, höchste Bedeutung beimessen. Die Hauptidee ist Messaging. “ Alan Kay

In einer E-Mail- Korrespondenz von 2003 stellte Alan Kay klar, was er vorhatte, als er Smalltalk "eine objektorientierte Sprache" nannte.

"Für mich bedeutet OOP nur Messaging, lokale Speicherung und Schutz sowie das Ausblenden des Status und das sehr späte Binden." Alan Kay

Mit anderen Worten, gemäß Alan Kays Ideen sind die wichtigsten OOP-Zutaten die folgenden:

• Messaging
• Kapselung.
• Dynamische Verknüpfung.

Es ist wichtig anzumerken, dass Alan Kay, der Mann, der den Begriff „OOP“ erfand und in die Massen brachte, Vererbung und Polymorphismus nicht als die wichtigsten Bestandteile von OOP ansah.

Die Essenz von OOP

Die Kombination von Messaging und Kapselung dient mehreren wichtigen Zwecken:

• Vermeiden des gemeinsam veränderlichen Status eines Objekts durch Einkapseln des Status und Isolieren anderer Objekte von lokalen Änderungen seines Status. Die einzige Möglichkeit, den Zustand eines anderen Objekts zu beeinflussen, besteht darin, ihn zu bitten (anstatt ihm einen Befehl zu geben), sich zu ändern, indem er ihm eine Nachricht sendet. Statusänderungen werden auf lokaler, zellularer Ebene überwacht, der Status wird anderen Objekten nicht zur Verfügung gestellt.
• Trennung von Objekten voneinander. Der Absender der Nachricht ist über die Messaging-API lose mit dem Empfänger verbunden.
• Anpassungsfähigkeit und Widerstandsfähigkeit gegen Änderungen während der Programmausführung durch späte Bindung. Die Anpassung an Änderungen während der Programmausführung bietet viele bedeutende Vorteile, die Alan Kay für OOP als sehr wichtig erachtete.

Alan Kay, der diese Ideen zum Ausdruck brachte, ließ sich von seinen Kenntnissen der Biologie und seinem Wissen über ARPANET (dies ist eine frühe Version des Internets) inspirieren. Wir sprechen nämlich von biologischen Zellen und von einzelnen Computern, die mit dem Netzwerk verbunden sind. Schon damals stellte sich Alan Kay vor, wie Programme auf riesigen, verteilten Computern (dem Internet) ausgeführt werden, während einzelne Computer als biologische Zellen fungieren, unabhängig voneinander mit ihrem eigenen isolierten Zustand arbeiten und Daten durch Senden von Nachrichten mit anderen Computern austauschen.

"Ich erkannte, dass eine Metapher für eine Zelle oder einen Computer dabei hilft, die Daten [...] loszuwerden." Alan Kay

Alan Kay sagte: „Hilfe beim Entfernen der Daten“ und war sich natürlich der Probleme bewusst, die durch den gemeinsam genutzten veränderlichen Zustand und die starke Konnektivität durch den Datenaustausch verursacht wurden. Heute sind diese Themen weit verbreitet. In den späten 1960er Jahren waren ARPANET-Programmierer jedoch unzufrieden mit der Notwendigkeit, vor der Entwicklung von Programmen eine Datenmodelldarstellung für ihre Programme auszuwählen. Die Entwickler wollten sich von dieser Praxis lösen, da es schwieriger ist, in Zukunft etwas zu ändern, wenn sie sich im Voraus in das durch die Präsentation der Daten festgelegte Framework hineinbewegen.

Das Problem war, dass verschiedene Arten der Darstellung der Daten für den Zugriff auf sie unterschiedlichen Code und unterschiedliche Syntax in den zu einem bestimmten Zeitpunkt verwendeten Programmiersprachen erforderten. Der Heilige Gral wäre hier eine universelle Möglichkeit, auf Daten zuzugreifen und diese zu verwalten. Wenn alle Daten für das Programm gleich aussehen würden, würde dies viele Probleme der Entwickler hinsichtlich der Entwicklung und Wartung von Programmen lösen.
Alan Kay versuchte, die Idee "loszuwerden", wonach Daten und Programme in gewissem Sinne unabhängige Einheiten waren. Sie werden in List oder Smalltalk nicht als solche betrachtet. Es gibt keine Trennung zwischen dem, was mit Daten (mit Werten, Variablen, Datenstrukturen usw.) und Software-Konstrukten wie Funktionen gemacht werden kann. Funktionen sind „erstklassige Bürger“, und Programme dürfen sich während ihrer Ausführung ändern. Mit anderen Worten, Smalltalk hat keine besondere, privilegierte Beziehung zu Daten.

Alan Kay betrachtete Objekte außerdem als algebraische Strukturen, die eindeutige, mathematisch nachweisbare Garantien für ihr Verhalten gaben.

"Durch meinen mathematischen Hintergrund konnte ich verstehen, dass jedem Objekt mehrere algebraische Modelle zugeordnet sein können, dass es ganze Gruppen ähnlicher Modelle geben kann und dass sie sehr, sehr nützlich sein können." Alan Kay

Es wurde bewiesen, dass dies der Fall ist, und dies bildete die Grundlage für Objekte wie Versprechen und Linsen. Darüber hinaus wurde die Kategorietheorie von beiden beeinflusst.
Die algebraische Natur, wie Alan Kay Objekte sah, würde es Objekten ermöglichen, eine formale Verifikation, ein deterministisches Verhalten und eine Verbesserung der Testbarkeit bereitzustellen, da algebraische Modelle im Wesentlichen Operationen sind, die mehreren Regeln in Form von Gleichungen folgen.

Im Fachjargon der Programmierer sind „algebraische Modelle“ Abstraktionen, die aus Funktionen (Operationen) erstellt wurden, die von bestimmten Regeln begleitet werden, die durch Komponententests erzwungen werden, die diese Funktionen bestehen müssen (Axiome, Gleichungen).

Diese Ideen wurden in den meisten objektorientierten Sprachen der C-Familie, einschließlich C ++, Java, C # usw., seit Jahrzehnten vergessen. Diese Ideen beginnen jedoch mit der Suche nach der Rückreise in neueren Versionen der am häufigsten verwendeten objektorientierten Sprachen.

Bei dieser Gelegenheit kann jemand sagen, dass die Welt der Programmierung die Vorteile der funktionalen Programmierung wieder entdeckt und rationale Argumente im Kontext objektorientierter Sprachen liefert.

Wie früher JavaScript und Smalltalk werden die meisten modernen objektorientierten Sprachen immer mehr zum "Multi-Paradigma". Es gibt keinen Grund, zwischen funktionaler Programmierung und OOP zu wählen. Wenn wir das historische Wesen jedes dieser Ansätze betrachten, sehen sie nicht nur als kompatibel, sondern auch als komplementäre Ideen aus.

Was ist nach den Gedanken von Alan Kay das Wichtigste in der PLO?

• Kapselung.
• Messaging
• Dynamische Bindung (die Fähigkeit von Programmen, sich während ihrer Ausführung zu entwickeln und an Änderungen anzupassen).

Was ist in OOP vernachlässigbar?

• Klassen.
• Klassenbasierte Vererbung.
• Besondere Beziehung zu Objekten, Funktionen oder Daten.
• Schlüsselwort new .
• Polymorphismus.
• Statische Eingabe.
• Einstellung zu Klassen als „Typen“.

Wenn Sie Java oder C # kennen, denken Sie vielleicht, dass statische Typisierung oder Polymorphismus die wichtigsten Bestandteile von OOP sind, aber Alan Kay zieht es vor, sich mit universellen Verhaltensmustern in algebraischer Form zu befassen. Hier ist ein Beispiel in Haskell:

 fmap :: (a -> b) -> fa -> fb 

Dies ist die Signatur des universellen map , der mit den undefinierten Typen a und b arbeitet und die Funktion von a nach b im Kontext des Funktors a anwendet, um den Funktor b zu erstellen. "Functor" ist ein Wort aus dem mathematischen Jargon, dessen Bedeutung auf "Unterstützung der Anzeigeoperation" reduziert wird. Wenn Sie mit der Methode [].map() in JavaScript vertraut sind, wissen Sie bereits, was dies bedeutet.

Hier einige Beispiele für JavaScript:

 // isEven = Number => Boolean const isEven = n => n % 2 === 0; const nums = [1, 2, 3, 4, 5, 6]; //  map   `a => b`    `a` ( `this`) //     `b` //    `a`   `Number`,   `b`  `Boolean` const results = nums.map(isEven); console.log(results); // [false, true, false, true, false, true] 

Die .map() -Methode ist universell in dem Sinne, dass a und b von jedem Typ sein können, und diese Methode bewältigt eine ähnliche Situation ohne Probleme, da Arrays Datenstrukturen sind, die die algebraischen Gesetze von Funktoren implementieren. Die Typen für .map() spielen keine Rolle, da diese Methode nicht versucht, direkt mit den entsprechenden Werten zu arbeiten. Stattdessen wird eine Funktion verwendet, die Werte der entsprechenden Typen erwartet und zurückgibt, die aus Sicht der Anwendung korrekt sind.

 // matches = a => Boolean //  `a`    ,   const matches = control => input => input === control; const strings = ['foo', 'bar', 'baz']; const results = strings.map(matches('bar')); console.log(results); // [false, true, false] 

Die Beziehung universeller Typen kann in Sprachen wie TypeScript schwierig korrekt und vollständig auszudrücken sein, ist jedoch in dem in Haskell verwendeten Hindley-Milner-Typsystem, das höhere Typen (Typtypen) unterstützt, sehr einfach.

Die meisten Typsysteme unterliegen zu starken Einschränkungen, um den freien Ausdruck dynamischer und funktionaler Ideen zu ermöglichen, wie z. B. die Zusammensetzung von Funktionen, die freie Zusammensetzung von Objekten, die Erweiterung von Objekten während der Programmausführung, die Verwendung von Kombinatoren, Linsen usw. Mit anderen Worten? Statische Typen erschweren häufig das Schreiben von Software mithilfe von Erstellungsmethoden.

Wenn Ihr Typsystem zu viele Einschränkungen aufweist (wie in TypeScript oder Java), müssen Sie komplexeren Code schreiben, um dieselben Ziele zu erreichen, als wenn Sie Sprachen mit einer freieren Schreibweise verwenden. Dies bedeutet nicht, dass die Verwendung statischer Typen eine unglückliche Idee ist oder dass alle Implementierungen statischer Typen dieselben Einschränkungen aufweisen. Zum Beispiel habe ich viel weniger Probleme beim Arbeiten mit dem System vom Typ Haskell festgestellt.

Wenn Sie ein Fan von statischen Typen sind und nicht gegen Einschränkungen sind, wünsche ich Ihnen sieben Fuß unter dem Kiel. Wenn Sie jedoch feststellen, dass einige der hier zum Ausdruck gebrachten Ideen schwierig umzusetzen sind, da es nicht einfach ist, Funktionen zu tippen, die durch Zusammensetzen anderer Funktionen und zusammengesetzter algebraischer Strukturen erhalten werden, geben Sie dem Typensystem und nicht der Idee die Schuld. Fahrer mögen die Annehmlichkeiten, die Rahmen-SUVs ihnen bieten, aber niemand beschwert sich, dass sie nicht fliegen. Zum Fliegen benötigen Sie ein Fahrzeug mit mehr Freiheitsgraden.

Wenn Einschränkungen Ihren Code einfacher machen - großartig! Wenn Sie jedoch aufgrund der Einschränkungen gezwungen sind, komplexeren Code zu schreiben, stimmt möglicherweise etwas mit diesen Einschränkungen nicht.

Was ist ein "Objekt"?

Das Wort „Objekt“ hat im Laufe der Zeit viele sekundäre Bedeutungskonnotationen erhalten. Was wir in JavaScript als "Objekte" bezeichnen, sind einfach zusammengesetzte Datentypen, ohne einen Hinweis auf die klassenbasierte Programmierung oder Alan Kays Ideen zur Nachrichtenübermittlung.

In JavaScript können diese Objekte die Kapselung, das Weiterleiten von Nachrichten, die Trennung des Verhaltens durch Methoden und sogar den Polymorphismus mithilfe von Unterklassen unterstützen (häufig auch unterstützen) (obwohl eine Delegierungskette anstelle eines typbasierten Versands verwendet wird).

Alan Kay wollte den Unterschied zwischen dem Programm und seinen Daten beseitigen. JavaScript erreicht dieses Ziel in gewissem Maße, indem Objektmethoden an derselben Stelle platziert werden wie die Eigenschaften, in denen die Daten gespeichert sind. Jeder Eigenschaft kann beispielsweise eine beliebige Funktion zugewiesen werden. Sie können das Objektverhalten dynamisch konstruieren und den semantischen Inhalt des Objekts während der Programmausführung ändern.

Ein Objekt ist nur eine zusammengesetzte Datenstruktur und benötigt nichts Besonderes, um als Objekt betrachtet zu werden. Die Programmierung mit Objekten führt jedoch nicht dazu, dass sich ein solcher Code als "objektorientiert" herausstellt, ebenso wie die Verwendung von Funktionen den Code nicht "funktionsfähig" macht.

OOP ist kein echtes OOP mehr

Da das Konzept des "Objekts" in modernen Programmiersprachen viel weniger bedeutet als das, was Alan Kay meinte, verwende ich das Wort "Komponente" anstelle des Wortes "Objekt", um die Regeln dieser OOP zu beschreiben. Viele Objekte sind direkt im Besitz von JavaScript-Code von Drittanbietern und werden von diesen gesteuert. Komponenten müssen jedoch ihren eigenen Status kapseln und steuern.

Folgendes ist echtes OOP:

• Programmieren mit Komponenten (Alan Kay nennt sie "Objekte").
• Der Status der Komponente muss gekapselt sein.
• Für die Kommunikation zwischen Entitäten wird Messaging verwendet.
• Komponenten können zur Laufzeit hinzugefügt, geändert und ersetzt werden.

Die meisten Objektverhalten können mithilfe algebraischer Datenstrukturen universell definiert werden. Es besteht keine Notwendigkeit für eine Vererbung. Komponenten können Verhaltensweisen aus öffentlichen Funktionen wiederverwenden und Module importieren, ohne ihre Daten veröffentlichen zu müssen.

Das Bearbeiten von Objekten in JavaScript oder das Verwenden der klassenbasierten Vererbung bedeutet nicht, dass jemand an der OOP-Programmierung beteiligt ist. Aber die Verwendung von Komponenten auf solche Weise - bedeutet. Es ist jedoch sehr schwierig, die etablierten Begriffe loszuwerden. Vielleicht sollten wir den Begriff „OOP“ belassen und die oben genannten „Komponenten“ als „Message Oriented Programming (MOP)“ bezeichnen. Wir werden den Begriff "MOP" unten verwenden, um über nachrichtenorientierte Programmierung zu sprechen.

Zufällig wird das englische Wort "mop" als "mop" übersetzt und, wie Sie wissen, zur Wiederherstellung der Ordnung verwendet.

Wie sieht ein guter MOP aus?

Die meisten modernen Programme verfügen über eine Benutzeroberfläche (User Interface, UI), die für die Interaktion mit dem Benutzer verantwortlich ist, einen Code, der den Status der Anwendung verwaltet (Benutzerdaten), und Code, der mit dem System funktioniert oder für den Datenaustausch mit dem Netzwerk verantwortlich ist.

Um den Betrieb jedes dieser Systeme zu unterstützen, sind möglicherweise langlebige Prozesse erforderlich, z. B. Ereignis-Listener. Hier benötigen Sie den Status der Anwendung - um Informationen über Netzwerkverbindungen, den Status der Schnittstellensteuerung und die Anwendung selbst zu speichern.

Ein guter MOP bedeutet, dass alle Systeme, die Zugriff auf den Status des anderen haben und diese direkt steuern können, über Nachrichten miteinander interagieren. Wenn der Benutzer auf die Schaltfläche "Speichern" klickt, kann die Nachricht "SAVE" gesendet werden. Die Anwendungskomponente für die Statusverwaltung kann diese Nachricht interpretieren und an den Prozessor umleiten, der für die Aktualisierung aus dem Status verantwortlich ist (z. B. eine reine Reduzierungsfunktion). Möglicherweise "STATE_UPDATED" die für die Verwaltung des Status verantwortliche Komponente nach dem Aktualisieren des Status die Nachricht "STATE_UPDATED" die Benutzeroberflächenkomponente, die wiederum den Status interpretiert, entscheidet, welche Teile der Schnittstelle aktualisiert werden müssen, und den aktualisierten Status an die Unterkomponenten weitergibt, die für die Arbeit verantwortlich sind spezifische Schnittstellenelemente.

In der Zwischenzeit kann die für Netzwerkverbindungen verantwortliche Komponente die Verbindung des Benutzers zu einem anderen Computer im Netzwerk überwachen, Nachrichten abhören und eine aktualisierte Ansicht des Status senden, um sie auf dem Remotecomputer zu speichern. Eine solche Komponente ist für die Arbeit mit Netzwerkmechanismen verantwortlich, weiß, ob die Verbindung funktioniert oder nicht und so weiter.

Ähnliche Anwendungssysteme sollten die Details ihrer anderen Teile nicht kennen. Sie sollten sich nur darum kümmern, ihre eigenen Probleme zu lösen. Systemkomponenten können als Konstruktor zerlegt und zusammengebaut werden. Sie implementieren standardisierte Schnittstellen, was bedeutet, dass sie miteinander interagieren können. Solange die bekannten Anforderungen an die Schnittstelle der Komponenten erfüllt sind, können solche Komponenten durch andere ersetzt werden, mit denselben Schnittstellen, aber dasselbe anders machen oder etwas völlig anderes ausführen, dieselben Nachrichten empfangen. Sie können eine Komponente auch während der Ausführung des Programms in eine andere ändern - dies wird die Arbeit nicht beeinträchtigen.

Die Komponenten eines Softwaresystems müssen sich nicht einmal auf demselben Computer befinden. Das System kann dezentralisiert werden. Der Netzwerkspeicher kann Daten in einem dezentralen Speichersystem wie IPFS ablegen . Dadurch ist der Benutzer unabhängig vom Zustand eines bestimmten Computers, wodurch die Sicherheit seiner Daten gewährleistet wird. Bei diesem Ansatz werden die Daten zuverlässig gespeichert und vor Eindringlingen geschützt.

Die PLO stand teilweise unter dem Einfluss der Ideen von ARPANET, und eines der Ziele dieses Projekts war die Schaffung eines dezentralen Netzwerks, das gegen Angriffe wie einen Atomschlag resistent ist.

Ein gutes MOP-System kann durch ein ähnliches Maß an Stabilität gekennzeichnet werden, wenn Komponenten verwendet werden, die Hot-Swapping unterstützen, während die Anwendung ausgeführt wird. Es kann weiterhin funktionieren, wenn der Benutzer von einem Mobiltelefon aus damit arbeitet und aufgrund der Tatsache, dass es den Tunnel betreten hat, keine Netzabdeckung mehr hat. Wenn ein Hurrikan die Stromversorgung eines der Rechenzentren unterbricht, in denen sich seine Server befinden, funktioniert er auch weiterhin.

Es ist Zeit für die Software-Welt, sich von einem erfolglosen klassenbasierten Vererbungsexperiment zu befreien und die mathematischen und wissenschaftlichen Prinzipien zu übernehmen, die bei OOP an vorderster Front standen.

Es ist Zeit für uns Entwickler, flexiblere, stabilere und schönere Programme mit einer harmonischen Kombination aus MOP und funktionaler Programmierung zu erstellen.
Übrigens wird das Akronym "MOP" bereits verwendet, das "Monitoring Oriented Programming" beschreibt, aber dieses Konzept wird im Gegensatz zu OOP einfach leise verschwinden.

Lassen Sie sich daher nicht entmutigen, wenn der Begriff „MOP“ nicht wie ein Wort aus dem Jargon der Programmierer aussieht. Räumen Sie einfach Ihren OOP mit den oben genannten MOP-Prinzipien auf.