Bedeutende Herausforderer für OOP

Question

Soweit ich weiß, ist OOP das am häufigsten verwendete Paradigma für Großprojekte.Ich weiß auch, dass einige kleinere Teilmengen großer Systeme andere Paradigmen verwenden (z. B.SQL, das deklarativ ist), und mir ist auch klar, dass OOP auf niedrigeren Rechenebenen nicht wirklich machbar ist.Aber es scheint mir, dass die Teile von Lösungen auf höherer Ebene normalerweise fast immer auf OOP-Art zusammengesetzt werden.

Gibt es Szenarien, in denen ein wirklich Nicht-OOP-Paradigma tatsächlich ein... ist? besser Wahl für eine groß angelegte Lösung?Oder ist das heutzutage undenkbar?

Ich habe mich das gefragt, seit ich begonnen habe, Informatik zu studieren.Man hat leicht das Gefühl, dass OOP ein Nirvana der Programmierung ist, das niemals übertroffen werden wird.

Answer 1

Meiner Meinung nach ist der Grund, OOP ist verwendet, so weit nicht so sehr, dass es das richtige Werkzeug für den Job. Ich denke, es ist mehr, dass eine Lösung in einer Art und Weise an den Kunden beschrieben werden, dass sie verstehen.

Ein Auto ist ein Fahrzeug, das einen Motor hat. Das ist die Programmierung und die reale Welt in einem!

Es ist schwer, etwas zu verstehen, das die Programmierung und die realen Welt ganz so elegant passen.

Answer 2

Linux ist ein Großprojekt, das sehr viel nicht OOP ist. Und es wäre nicht viel haben, entweder von ihm zu gewinnen.

Ich denke, OOP einen guten Klang hat, weil sie sich mit guten Programmiertechniken wie Verkapselung, Verbergen von Daten, die Wiederverwendung von Code, Modularität et.c. zugeordnet ist, Aber diese Tugenden sind keineswegs einzigartig OOP.

Answer 3

Sie vielleicht einen Blick auf Erlang haben, geschrieben von Joe Armstrong.

Wikipedia:

  

"Erlang ist ein Allzweck   gleichzeitige Programmiersprache und   Laufzeitsystem. Die sequentielle Subset   von Erlang ist eine funktionale Sprache,   mit strengen Bewertung, Single   Zuordnung und dynamische Typisierung. "

Joe Armstrong:

  

„Weil das Problem mit   objektorientierten Sprachen ist sie haben   hatte all diese implizite Umgebung,   sie tragen mit ihnen um. Sie   eine Banane wollte, aber was hast du war ein   Gorilla hält die Banane und die   ganzer Dschungel.“

Answer 4

Das Versprechen der OOP war die Wiederverwendung von Code und einfachere Wartung. Ich bin nicht sicher, ob es geliefert. Ich sehe die Dinge wie dot net so viel die gleichen wie die C-Bibliotheken sind wir verwendet fro verschiedene Anbieter zu erhalten. Sie können diese Wiederverwendung von Code aufrufen, wenn Sie wollen. Wie für die Wartung schlecht Code ist schlechter Code. OOP hat nicht geholfen.

Answer 5

Ich bin der größte Fan von OOP, und ich übe jeden Tag OOP. Es ist der natürlichste Weg, um Code zu schreiben, weil es das wirkliche Leben ähnelt.

Obwohl, ich merke, dass die Virtualisierung der OOP kann Leistungsprobleme verursachen. Natürlich, die auf Ihrem Design abhängig ist, die Sprache und die Plattform, die Sie gewählt haben (geschrieben Systeme in Garbage Collection basierten Sprachen wie Java oder C # könnte schlimmer als Systeme durchführen, die in C ++ zum Beispiel geschrieben wurden).

Ich denke, in Echtzeit-Systemen kann die prozeduralen Programmierung besser geeignet sein.

Answer 6

Beachten Sie, dass nicht alle Projekte, die in der Tat OOP sein OOP Anspruch. Manchmal ist die Mehrheit des Code Verfahren oder das Datenmodell ist anämisch , und so weiter. ..

Answer 7

Zyx, Sie schrieb: "Die meisten Systeme relationale Datenbanken verwenden ..."

Ich fürchte, es gibt nicht so etwas. Das relationale Modell wird 40 Jahre alt im nächsten Jahr und hat noch nie umgesetzt worden. Ich denke, Sie meinen, „SQL-Datenbanken.“ Sie sollten etwas von Fabian Pascal lesen Sie den Unterschied zwischen einem relationalen DBMS und einer SQL-dbms zu verstehen.

„... das relationale Modell in der Regel wegen seiner Popularität gewählt wird,“

Es stimmt, es ist sehr beliebt.

"... Verfügbarkeit von Werkzeugen"

Ach, ohne das Hauptwerkzeug notwendig. Eine Implementierung des relationalen Modells

"Unterstützung"

Yup, das relationale Modell hat feine Unterstützung, ich bin sicher, aber es ist völlig ungestützt durch eine dbms Umsetzung.

„und die Tatsache, dass das relationale Modell in der Tat ist ein mathematisches Konzept,“

Ja, es ist ein mathematisches Konzept, aber nicht umgesetzt wird, ist es weitgehend die Elfenbeintürme begrenzt. Die Stringtheorie ist auch ein mathematisches Konzept, aber ich würde nicht ein System mit ihm umzusetzen.

In der Tat, trotz es ein methematical Konzept zu sein, ist es sicherlich keine Wissenschaft (wie in der Informatik), weil sie die erste Voraussetzung jeder Wissenschaft fehlt: dass es falsifizierbar ist: Es gibt keine Implementierung eines relationalen DBMS, gegen die wir überprüfen kann seine Ansprüche.

Es ist reine snake oil.

"... im Gegensatz zu OOP."

Und im Gegensatz zu OOP hat das relationale Modell nie umgesetzt worden.

Kaufen Sie ein Buch über SQL und bekommen produktiv.

Lassen Sie das relationale Modell zu unproduktiv Theoretiker.

Answer 8

Siehe dieses und diese . Anscheinend kann man C # mit fünf verschiedenen Programmierparadigmen verwenden, C ++ mit drei, etc.

Software Konstruktion ist Fundamentale Physik nicht verwendet. Physik strebt Realität mit Paradigmen zu beschreiben, die durch neue experimentelle Daten und / oder Theorien in Frage gestellt werden können. Die Physik ist eine Wissenschaft, die für eine „Wahrheit“ sucht, in einer Weise, die Software Konstruktion nicht.

Software Konstruktion ist ein Unternehmen . Sie müssen produktiv sein , das heißt, einige Ziele zu erreichen, für die jemand Geld bezahlen. Paradigmen verwendet werden, weil sie Software nützlich zu produzieren sind effektiv . Sie brauchen nicht alle zustimmen. Wenn ich OOP tun und es funktioniert gut für mich, ist mir egal, wenn eine „neue“ Paradigma möglicherweise 20% mehr nützlich für mich wäre, wenn ich die Zeit und Geld zu lernen, es hatte und später die gesamte Softwarestruktur überdenken ich m arbeiten in und Neugestaltung es von Grund auf neu.

Auch können Sie ein anderes Paradigma verwenden, und ich werde immer noch glücklich sein, auf die gleiche Art und Weise, dass ich Geld aus einem japanischen Restaurant zu machen und Sie können Geld mit einem mexikanischen Essen Restaurant nebenan zu machen. Ich brauche nicht als mexikanisches Essen mit Ihnen, ob japanisches Essen ist besser zu diskutieren.

Answer 9

Ich bezweifle OOP geht weg in absehbarer Zeit, sie paßt nur unsere Probleme und mentale Modelle viel zu gut.

Was wir beginnen, wenn zu sehen ist Multi-Paradigma Ansätze, mit deklarativen und funktionalen Ideen in objektorientierten Designs integriert werden. Die meisten der neueren JVM Sprachen sind ein gutes Beispiel für dieses (JavaFX, Scala, Clojure, etc.) sowie LINQ und F # auf der .NET-Plattform.

Es ist wichtig zu beachten Sie, dass ich nicht über mich reden hier OO zu ersetzen, aber es zu ergänzen.

• JavaFX hat, dass eine deklarative gezeigt Lösung geht über SQL und XSLT, und kann auch für die Bindung verwendet werden Eigenschaften und Ereignisse zwischen visuellen Komponenten in einer GUI

• Für fehlertolerante und hoch parallel arbeitende Systeme, funktionelle Programmierung ist eine sehr gute Passform, wie von der Ericsson demonstriert AXD301 (programmiert mit Erlang)

So ... als Gleichzeitigkeit wird immer wichtiger und FP wird immer beliebter, ich stelle mir vor, dass Sprachen nicht dieses Paradigma unterstützt werden leiden. Dazu gehören viele, die derzeit beliebt sind wie C ++, Java und Ruby, obwohl JavaScript sollte sehr gut fertig werden.

Answer 10

Mit OOP macht den Code leichter zu verwalten (wie in modify / update / neue Funktionen hinzuzufügen) und zu verstehen. Dies gilt vor allem bei größeren Projekten. Da Module / Objekte ihre Daten und Operationen auf diesen Daten kapseln ist es einfacher, die Funktionalität und das große Bild zu verstehen.

Der Vorteil der OOP ist, dass es einfacher ist, zu diskutieren (mit anderen Entwicklern / Management / Kunde) ein LogManager oder Ordermanager, die jeweils spezifische Funktionen umfassen, dann beschreibt ‚eine Gruppe von Methoden, die die Daten in der Datei Dump‘ und ‚die Methoden, die den Überblick über Bestellangaben halten‘.

Also ich denke, OOP hilfreich ist vor allem bei großen Projekten, aber es gibt immer wieder neue Konzepte so Aufdrehen hält auf Suche nach neuen Sachen in der Zukunft, bewerten und zu halten, was nützlich ist.

Answer 11

Die Leute mögen verschiedene Dinge als „Objekte“ denken und zu klassifizieren, so dass kein Zweifel daran, dass OOP so beliebt ist. Allerdings gibt es einige Bereiche, in denen OOP hat noch keine größere Popularität gewonnen. Die meisten Systeme verwenden relationale Datenbanken nicht objektiv. Auch wenn die zweiten einige bemerkenswerte Aufzeichnungen und sind besser für einige Arten von Aufgaben halten, wird das relationale Modell unsually wegen seiner Popularität gewählt, die Verfügbarkeit von Tools, Support und die Tatsache, dass das relationale Modell in der Tat ist ein mathematisches Konzept entgegen OOP.

Ein weiterer Bereich, in dem ich OOP nie gesehen ist die Software Bauprozess. Die ganze Konfiguration und machen Skripte sind prozedurale, teilweise wegen des Fehlens der Unterstützung für die OOP in der Schale Sprachen, zum Teil, weil OOP zu komplex ist, für solche Aufgaben.

Answer 12

Eine etwas kontroverse Meinung meinerseits, aber ich glaube nicht, dass OOP, zumindest nicht von der Art, die derzeit allgemein angewendet wird, so ist Das Hilfreich bei der Erstellung der größten Software in meinem speziellen Bereich (VFX, das in der Szenenorganisation und dem Anwendungsstatus etwas ähnlich ist wie Spiele).Ich finde es im mittleren bis kleineren Maßstab sehr nützlich.Ich muss hier etwas vorsichtig sein, da ich in der Vergangenheit einige Mobs eingeladen habe, aber ich sollte zugeben, dass dies auf meine begrenzte Erfahrung in meiner speziellen Art von Domäne zurückzuführen ist.

Die Schwierigkeit, die ich oft festgestellt habe, besteht darin, dass all diese kleinen konkreten Objekte, die Daten verkapseln, nun alle miteinander kommunizieren wollen.Die Interaktionen zwischen ihnen können beispielsweise äußerst komplex werden (außer dass sie in einer realen Anwendung, die Tausende von Objekten umfasst, viel, viel komplexer sind):

Dabei handelt es sich nicht um einen Abhängigkeitsgraphen, der direkt mit der Kopplung zusammenhängt, sondern eher um einen „Interaktionsgraphen“.Es könnte Abstraktionen geben, um diese konkreten Objekte voneinander zu entkoppeln. Foo vielleicht nicht mit ihm reden Bar direkt.Es könnte stattdessen mit ihm kommunizieren IBar oder so etwas in der Art.Dieses Diagramm würde immer noch eine Verbindung herstellen Foo Zu Bar denn obwohl sie entkoppelt sind, reden sie immer noch miteinander.

Und die gesamte Kommunikation zwischen kleinen und mittelgroßen Objekten, die ihr eigenes kleines Ökosystem bilden, kann, wenn sie auf den gesamten Umfang einer großen Codebasis in meiner Domäne angewendet wird, äußerst schwierig aufrechtzuerhalten sein.Und es wird so schwierig, es aufrechtzuerhalten, weil es schwierig ist, darüber nachzudenken, was bei all diesen Interaktionen zwischen Objekten im Hinblick auf Dinge wie Nebenwirkungen passiert.

Stattdessen habe ich es als nützlich empfunden, die gesamte Codebasis in völlig unabhängige, umfangreiche Subsysteme zu organisieren, die auf eine zentrale „Datenbank“ zugreifen.Jedes Subsystem gibt dann Daten ein und aus.Einige andere Subsysteme greifen möglicherweise auf dieselben Daten zu, ohne dass ein System direkt miteinander kommuniziert.

...oder dieses:

...und jedes einzelne System versucht nicht mehr, den Zustand zu kapseln.Es versucht nicht, ein eigenes Ökosystem zu werden.Stattdessen liest und schreibt es Daten in der zentralen Datenbank.

Natürlich können sie bei der Implementierung jedes Subsystems eine Reihe von Objekten verwenden, um sie bei der Implementierung zu unterstützen.Und hier finde ich OOP bei der Implementierung dieser Subsysteme sehr nützlich.Aber jedes dieser Subsysteme stellt ein relativ mittelgroßes bis kleines Projekt dar, nicht zu groß, und gerade in diesem mittleren bis kleineren Maßstab finde ich OOP sehr nützlich.

„Fließbandprogrammierung“ mit minimalen Kenntnissen

Dadurch kann sich jedes Subsystem ganz auf seine Aufgabe konzentrieren, ohne zu wissen, was in der Außenwelt vor sich geht.Ein Entwickler, der sich auf Physik konzentriert, kann sich einfach mit dem Physik-Subsystem hinsetzen und wenig darüber wissen, wie die Software funktioniert, außer dass es eine zentrale Datenbank gibt, aus der er Dinge wie Bewegungskomponenten (nur Daten) abrufen und durch Anwendung der Physik auf diese Daten umwandeln kann.Und das macht seine Arbeit sehr einfach und ermöglicht es ihm, das zu tun, was er am besten kann, mit einem Minimum an Kenntnissen darüber, wie alles andere funktioniert.Eingabe-Zentraldaten und Ausgabe-Zentraldaten:Das ist alles, was jedes Subsystem richtig machen muss, damit alles andere funktioniert.Es ist das, was ich in meinem Bereich am nächsten an der „Fließbandprogrammierung“ gefunden habe, bei der jeder Entwickler sein Ding mit minimalen Kenntnissen über die Funktionsweise des Gesamtsystems machen kann.

Auch das Testen ist aufgrund des engen Fokus jedes Subsystems immer noch recht einfach.Wir verspotten nicht mehr konkrete Objekte mit der Abhängigkeitsinjektion, sondern generieren vielmehr eine Mindestmenge an Daten, die für ein bestimmtes System relevant sind, und testen, ob das bestimmte System die richtige Ausgabe für eine bestimmte Eingabe bereitstellt.Da so wenige Systeme getestet werden müssen (nur Dutzende können eine komplexe Software bilden), reduziert sich auch die Anzahl der erforderlichen Tests erheblich.

Kapselung durchbrechen

Das System verwandelt sich dann in eine eher flache Pipeline, die den zentralen Anwendungsstatus durch unabhängige Subsysteme umwandelt, die praktisch keine Kenntnis von der Existenz des anderen haben.Manchmal kann es vorkommen, dass ein zentrales Ereignis in die Datenbank übertragen wird, das von einem anderen System verarbeitet wird, aber das andere System weiß immer noch nicht, woher dieses Ereignis stammt.Ich habe festgestellt, dass dies zumindest in meinem Bereich der Schlüssel zur Bewältigung der Komplexität ist, und zwar effektiv über ein Entitäts-Komponenten-System.

Dennoch ähnelt es eher einer prozeduralen oder funktionalen Programmierung auf breiter Ebene, alle diese Subsysteme zu entkoppeln und sie mit minimalem Wissen über die Außenwelt arbeiten zu lassen, da wir die Kapselung aufbrechen, um dies zu erreichen und zu vermeiden, dass die Systeme mit jedem kommunizieren müssen andere.Wenn Sie hineinzoomen, werden Sie vielleicht feststellen, dass Ihr Anteil an Objekten zur Implementierung eines dieser Subsysteme verwendet wird, aber im weitesten Sinne ähneln die Systeme etwas anderem als OOP.

Globale Daten

Ich muss zugeben, dass ich zunächst sehr zögerlich war, ECS auf einen Architekturentwurf in meinem Bereich anzuwenden, da es erstens meines Wissens noch nicht bei beliebten kommerziellen Wettbewerbern (3DS Max, SoftImage usw.) durchgeführt wurde und zweitens , es sieht aus wie eine ganze Menge global zugänglicher Daten.

Ich habe jedoch festgestellt, dass dies kein großes Problem darstellt.Wir können Invarianten immer noch sehr effektiv aufrechterhalten, vielleicht sogar besser als zuvor.Der Grund liegt in der Art und Weise, wie das ECS alles in Systeme und Komponenten organisiert.Sie können sicher sein, dass ein Audiosystem nicht versucht, eine Bewegungskomponente zu verändern, z. B. nicht einmal in den schwierigsten Situationen.Selbst mit einem schlecht koordinierten Team ist es sehr unwahrscheinlich, dass das ECS zu etwas degradiert, bei dem man nicht mehr darüber nachdenken kann, welche Systeme auf welche Komponente zugreifen, da dies auf dem Papier ziemlich offensichtlich ist und es praktisch keinerlei Gründe für den Zugriff auf ein bestimmtes System gibt eine ungeeignete Komponente.

Im Gegenteil, es hat oft viele der früheren Versuchungen für Hacky-Dinge beseitigt, da die Daten weit offen standen, da viele der Hacky-Dinge, die in unserer früheren Codebasis unter lockerer Koordination und Crunch-Zeit durchgeführt wurden, in übereilten Versuchen durchgeführt wurden, Abstraktionen zu röntgen und zu versuchen Zugriff auf die Interna der Ökosysteme von Objekten.Die Abstraktionen begannen, undicht zu werden, weil Menschen in Eile versuchten, einfach an die Daten zu kommen und Dinge damit zu tun, auf die sie zugreifen wollten.Im Grunde genommen haben sie sich nur schwerlich mit dem Versuch beschäftigt, auf Daten zuzugreifen, was dazu geführt hat, dass sich die Schnittstellendesigns schnell verschlechtert haben.

Es gibt immer noch etwas, das vage einer Kapselung ähnelt, allein aufgrund der Art und Weise, wie das System organisiert ist, da es oft nur ein System gibt, das einen bestimmten Komponententyp modifiziert (in einigen Ausnahmefällen zwei).Sie besitzen diese Daten jedoch nicht und bieten keine Funktionen zum Abrufen dieser Daten an.Die Systeme kommunizieren nicht miteinander.Sie alle arbeiten über die zentrale ECS-Datenbank (die die einzige Abhängigkeit darstellt, die in alle diese Systeme eingefügt werden muss).

Flexibilität und Erweiterbarkeit

Dies ist bereits weit verbreitet in externen Ressourcen über Unternehmenskomponentensysteme, aber sie können sich im Nachhinein radikal neue Designideen anpassen, sogar konzeptbrochene, wie ein Vorschlag für eine Kreatur, die ein Säugetier, Insekt und Anpflanzen ist, das Sprossenblätter unter Sonnenlicht auf einmal.

Einer der Gründe liegt darin, dass es keine zentralen Abstraktionen gibt, die durchbrochen werden könnten.Sie führen einige neue Komponenten ein, wenn Sie hierfür mehr Daten benötigen, oder erstellen einfach eine Entität, die die für eine Pflanze, ein Säugetier und ein Insekt erforderlichen Komponenten aneinanderreiht.Die Systeme, die für die Verarbeitung von Insekten-, Säugetier- und Pflanzenkomponenten konzipiert sind, nehmen diese dann automatisch auf und Sie erhalten möglicherweise das gewünschte Verhalten, ohne etwas zu ändern, außer eine Codezeile hinzuzufügen, um eine Entität mit einer neuen Komponentenkombination zu instanziieren.Wenn Sie völlig neue Funktionen benötigen, fügen Sie einfach ein neues System hinzu oder ändern ein vorhandenes.

Was ich anderswo nicht so oft diskutiert gefunden habe, ist, wie sehr dies die Wartung erleichtert, selbst in Szenarien, in denen es keine konzeptbrechenden Designänderungen gibt, die wir nicht vorhergesehen haben.Selbst wenn man die Flexibilität des ECS außer Acht lässt, kann es die Dinge wirklich vereinfachen, wenn Ihre Codebasis eine bestimmte Größe erreicht.

Objekte in Daten verwandeln

In einer früheren OOP-lastigen Codebasis, bei der ich die Schwierigkeit sah, eine Codebasis näher an der ersten Grafik oben beizubehalten, explodierte die erforderliche Codemenge aufgrund der Analogie Car in diesem Diagramm:

...musste als völlig separater Untertyp (Klasse) erstellt werden, der mehrere Schnittstellen implementiert.Wir hatten also eine explosionsartige Anzahl an Objekten im System:ein separates Objekt für Punktlichter von gerichteten Lichtern, ein separates Objekt für eine Fischaugenkamera von einem anderen usw.Wir hatten Tausende von Objekten, die ein paar Dutzend abstrakte Schnittstellen in endlosen Kombinationen implementierten.

Als ich es mit ECS verglich, waren dafür nur Hunderte erforderlich und wir konnten genau die gleichen Dinge tun, ohne einen kleinen Teil des Codes zu verwenden, weil das die Analogie veränderte Car Entität in etwas, das seine Klasse nicht mehr benötigt.Es wird zu einer einfachen Sammlung von Komponentendaten als verallgemeinerte Instanz von nur einer einzigen Entity Typ.

OOP-Alternativen

Es gibt also Fälle wie diesen, in denen eine übermäßige Anwendung von OOP auf der breitesten Ebene des Designs die Wartbarkeit erheblich beeinträchtigen kann.Wenn Sie Ihr System aus der Vogelperspektive betrachten, kann es hilfreich sein, es abzuflachen und nicht zu versuchen, es so „tief“ zu modellieren, dass Objekte mit Objekten interagieren, wie abstrakt sie auch sein mögen.

Vergleicht man die beiden Systeme, an denen ich in der Vergangenheit und jetzt gearbeitet habe, so stellt man fest, dass das neue über mehr Funktionen verfügt, aber Hunderttausende von LOC benötigt.Ersteres erforderte über 20 Millionen LOC.Natürlich ist das nicht der fairste Vergleich, da das erstere ein riesiges Erbe hatte, aber wenn man einen Ausschnitt aus den beiden Systemen nimmt, die ohne die Altlasten funktionell ziemlich gleich sind (zumindest in etwa so nah an Gleichheit, wie wir vielleicht bekommen könnten), wird das ECS benötigt einen kleinen Teil des Codes, um dasselbe zu tun, und das liegt zum Teil daran, dass es die Anzahl der im System vorhandenen Klassen drastisch reduziert, indem es sie in Sammlungen (Entitäten) von Rohdaten (Komponenten) umwandelt und stattdessen umfangreiche Systeme zu deren Verarbeitung benötigt einer Schiffsladung kleiner/mittlerer Gegenstände.

Gibt es Szenarien, in denen ein wirklich Nichtoop-Paradigma tatsächlich eine bessere Wahl für eine Lackierung von Largescale ist?Oder ist das von diesen Tagen unbekannt?

Es ist alles andere als unbekannt.Das System, das ich oben beschreibe, wird beispielsweise häufig in Spielen verwendet.Das kommt in meinem Fachgebiet ziemlich selten vor (die meisten Architekturen in meinem Fachgebiet sind COM-ähnlich mit reinen Schnittstellen, und das ist die Art von Architektur, an der ich in der Vergangenheit gearbeitet habe), aber ich habe festgestellt, dass es so ist, wenn ich mir anschaue, was Gamer wann tun Das Entwerfen einer Architektur machte einen großen Unterschied darin, etwas schaffen zu können, das auch dann noch sehr verständlich bleibt, wenn es wächst und wächst.

Allerdings halten einige Leute ECS für eine eigenständige Art objektorientierter Programmierung.Wenn ja, ähnelt es nicht der Art von OOP, an die die meisten von uns denken würden, da Daten (Komponenten und Entitäten, aus denen sie bestehen) und Funktionalität (Systeme) getrennt sind.Es erfordert die Aufgabe der Kapselung auf breiter Systemebene, die oft als einer der grundlegendsten Aspekte von OOP angesehen wird.

High-Level-Codierung

Aber es scheint mir, dass normalerweise die Stücke mit höherer Ebene fast immer auf OOP -Weise zusammengestellt werden.

Wenn Sie eine Anwendung mit Code auf sehr hoher Ebene zusammensetzen können, ist sie in der Regel eher klein oder mittelgroß, was den Code betrifft, den Ihr Team pflegen muss, und kann wahrscheinlich sehr effektiv mit OOP zusammengestellt werden.

In meinem Bereich VFX müssen wir oft relativ einfache Dinge wie Raytracing, Bildverarbeitung, Mesh-Verarbeitung, Fluiddynamik usw. tun und können diese nicht einfach aus Produkten von Drittanbietern zusammensetzen, da wir tatsächlich im Wettbewerb stehen mehr im Hinblick darauf, was wir auf der unteren Ebene tun können (Benutzer sind mehr von innovativen, wettbewerbsfähigen Produktions-Rendering-Verbesserungen begeistert als beispielsweise von einer schöneren Benutzeroberfläche).Es kann also jede Menge Code geben, der von sehr einfachen Bit- und Byte-Mischvorgängen bis hin zu Code auf sehr hoher Ebene reicht, den Skripter über eingebettete Skriptsprachen schreiben.

Interweb der Kommunikation

Aber irgendwann kommt bei jeder Art von Anwendung, egal ob High-Level oder Low-Level oder eine Kombination, ein Punkt, an dem es um einen sehr komplexen zentralen Anwendungszustand geht, an dem es meiner Meinung nach nicht mehr sinnvoll ist, zu versuchen, alles zu kapseln in Objekte.Dadurch erhöht sich tendenziell die Komplexität und die Schwierigkeit, über die Vorgänge nachzudenken, da sich die Interaktion zwischen allem vervielfacht.Es ist nicht mehr so ​​einfach, davon auszugehen, dass Tausende von Ökosystemen miteinander kommunizieren, wenn es nicht in einem ausreichend großen Maßstab einen Bruchpunkt gibt, an dem wir aufhören, alles als abgekapselte Ökosysteme zu modellieren, die miteinander kommunizieren müssen.Auch wenn jedes einzeln einfach ist, kann alles in seiner Gesamtheit den Geist mehr als überfordern, und wir müssen oft eine ganze Menge davon berücksichtigen, um Änderungen vorzunehmen, neue Funktionen hinzuzufügen, Dinge zu debuggen und so weiter, wenn Sie möchten Versuchen Sie, den Entwurf eines gesamten Großsystems ausschließlich auf OOP-Prinzipien auszurichten.Es kann hilfreich sein, zumindest für einige Domänen in gewissem Umfang aus der Kapselung auszubrechen.

An diesem Punkt ist es nicht mehr unbedingt sinnvoll, beispielsweise ein Physiksystem seine eigenen Daten kapseln zu lassen (sonst könnten viele Dinge mit ihm kommunizieren und diese Daten abrufen und sie mit den entsprechenden Eingabedaten initialisieren), und das ist der Punkt Ich fand diese Alternative durch ECS sehr hilfreich, da sie das analoge physikalische System und alle derart umfangreichen Systeme in einen „zentralen Datenbanktransformator“ oder einen „zentralen Datenbankleser, der etwas Neues ausgibt“ verwandelt, die jetzt nicht mehr voneinander wissen können.Jedes System ähnelt dann eher einem Prozess in einer flachen Pipeline als einem Objekt, das einen Knoten in einem sehr komplexen Kommunikationsdiagramm bildet.