Ich habe zuvor eine Frage zu Dataset vs Business Objects gestellt .NET Dataset vs. Business Object : Warum die Debatte? Warum nicht die beiden kombinieren?
und ich möchte hier die Frage verallgemeinern: Wo ist der Beweis, dass OOP wirklich für sehr komplexe Probleme geeignet ist? Nehmen wir zum Beispiel eine MMO Game Engine. Ich bin überhaupt kein Spezialist, aber während ich diesen Artikel lese, ist klar, dass OOP weit davon entfernt ist, genug zu sein:
Es schließt ab: Die Programmierung gut mit Entity Systems ist der Programmierung mit einer relationalen Datenbank sehr nahe. Es wäre nicht unvernünftig, ES als eine Form von "Relation Oriented Programming" zu bezeichnen.
Also versucht OOP nicht, etwas loszuwerden, das hier bleiben soll?
OOP ist nichtlinear, Relational ist linear, beide sind abhängig von dem Teil eines Systems, also warum versuchen Sie, Relational zu eliminieren, nur weil es kein "reines" Objekt ist. Ist OOP ein Selbstzweck?
Meine Frage ist nicht OOP nützlich. OOP ist nützlich, meine Frage ist eher, warum die Puristen "reines" OOP machen wollen?
Als Autor des verlinkten Beitrags dachte ich, ich würde ein paar Gedanken einwerfen.
Zu Ihrer Information: Ich habe 1997 ernsthaft mit OOP / ORM / UML angefangen (d. h. für kommerzielle Arbeit), und ich brauchte ungefähr fünf Jahre täglich, um IMHO wirklich gut zu werden. Ich habe zu diesem Zeitpunkt ungefähr 5 Jahre lang in ASM- und Nicht-OOP-Sprachen programmiert.
Die Frage mag unvollständig formuliert sein, aber ich denke, es ist eine gute Frage, sich selbst zu fragen und zu untersuchen - wenn Sie einmal verstanden haben, wie man es besser formuliert, werden Sie viel Nützliches darüber gelernt haben, wie das alles zusammenhängt. p>
"Also versucht OOP nicht, etwas loszuwerden, das hier bleiben soll?"
Lesen Sie zuerst Bjarnes Papier hier: Ссылка
Meines Erachtens sollte niemandem ein OOP beigebracht werden, ohne dieses Papier zu lesen (und erneut zu lesen, nachdem sie OOP "gelernt" haben). So viele Menschen verstehen falsch, womit sie es zu tun haben.
IME, viele Universitätskurse lehren OOP nicht gut; Sie lehren Menschen, wie man Methoden und Klassen schreibt und wie man Objekte benutzt. Sie lehren schlecht warum Sie diese Dinge tun würden, woher die Ideen kommen, usw. Ich denke viel von dem Missbrauch kommt daher: fast ein Fall von Blinden, die Blinde führen (sie sind nicht t blind in "wie" OOP zu verwenden, sind sie nur blind in "warum" OOP zu verwenden.
Um aus den letzten Absätzen des Papiers zu zitieren:
"Wie Sie gute Programmiertechniken und gute Designtechniken unterstützen, ist wichtiger als Etiketten und Schlagworte. Die grundlegende Idee besteht einfach darin, Design und Programmierung durch Abstraktion zu verbessern. Sie wollen Details verbergen, Sie wollen jede Gemeinsamkeit in einem System ausnutzen und du willst das erschwinglich machen.
Ich möchte Sie ermutigen, objektorientiert nicht bedeutungslos zu sein. Der Begriff "objektorientiert" wird zu oft herabgesetzt: - indem man es mit gut gleichsetzt, - indem man es mit einer einzigen Sprache gleichsetzt, oder - indem man alles als objektorientiert akzeptiert.
Ich habe argumentiert, dass es über objektorientierte Programmierung und Design hinaus nützliche Techniken gibt und geben muss. Um jedoch nicht völlig missverstanden zu werden, möchte ich betonen, dass ich kein ernsthaftes Projekt mit einer Programmiersprache versuchen würde. Dies war nicht genug, um den klassischen Begriff der objektorientierten Programmierung zu unterstützen. Zusätzlich zu Funktionen, die objektorientierte Programmierung unterstützen, möchte ich - und C ++ bietet Funktionen, die über diejenigen hinausgehen, die in ihrer Unterstützung für die direkte Ausdrucksweise von Konzepten und Beziehungen stehen. "
Nun ... ich würde Sie fragen ... von allen OOP-Programmierern und OOP-Projekten, die Sie gesehen haben, wie viele von ihnen können ehrlich behaupten, dass sie sich an das gehalten haben, was Bjarne dort verlangt?
IME, weniger als die Mehrheit.
Bjarne sagt folgendes:
"Die grundlegende Idee ist einfach, Design und Programmierung durch Abstraktion zu verbessern"
... und doch erfinden viele Menschen für sich eine andere Bedeutung, etwas wie:
"Die grundlegende Idee ist, dass OOP gut ist, und alles-nicht-OOP ist minderwertig"
Programmierer, die sequentiell mit ASM programmiert haben, dann später mit ASM, dann mit Pascal, dann mit C, dann mit C ++ und dem Chaos ausgesetzt waren, das das Programmieren von Präkapselung usw. war, neigen dazu, dieses Wissen besser zu verstehen. Sie wissen, warum OOP entstanden ist, was es zu lösen versucht hat.
Lustig genug, OOP war nicht versucht, jedes Programmierproblem zu lösen. Wer hätte das gedacht, um zu sagen, worüber heute gesprochen wird?
Es war auf eine kleine Anzahl von Problemen ausgerichtet, die sehr gefährlich waren, je größer Ihr Projekt wurde und welche sich zwischen "gut" und "sehr gut" beim Lösen herausstellte.
Aber sogar einige von ihnen ist es nicht besser als nur "gut" zu lösen; Es gibt andere Paradigmen, die besser sind ...
Alle IMHO, natürlich;)
Systeme mit bemerkenswerter Komplexität sind nicht linear. Selbst wenn Sie wirklich hart daran gearbeitet haben, ein System zu einem linearen Prozess zu machen, verlassen Sie sich immer noch auf Dinge wie Festplatten, Speicher und Netzwerkverbindungen, die flockig sein können, also müssen Sie das umgehen.
Ich weiß nicht, dass jemand denkt, OOP sei die endgültige Antwort. Es ist nur ein Weg, mit der Komplexität umzugehen, indem versucht wird, verschiedene Probleme auf die kleinstmögliche Sphäre beschränkt zu halten, so dass der Schaden, den sie verursachen, wenn sie explodieren, minimiert wird. Mein Problem mit Ihrer Frage ist, dass Perfektion möglich ist. Wenn es so wäre, könnte ich zustimmen OOP ist nicht notwendig. Es ist für mich, bis jemand einen besseren Weg für mich findet, um die Anzahl der Fehler zu minimieren, die ich mache.
Lesen Sie einfach Ihren Artikel über Entity Systems, der ES mit OOP vergleicht, und es ist offensichtlich falsch über mehrere Aspekte von OOP. Wenn z. B. 100 Instanzen einer Klasse vorhanden sind, schreibt OOP nicht vor, dass 100 Kopien der Klassen-Methoden in den Speicher geladen werden, nur einer ist notwendig. Alles, was ES vorgibt, "besser" als OOP zu sein, weil es "Komponenten" und "Systeme" hat, unterstützt OOP auch über Schnittstellen und statische Klassen (und / oder Singletons).
Und OOP fügt sich natürlicher in die reale Welt ein, da jede reale oder eingebildete Problemdomäne, die aus mehreren physischen und / oder nicht-physischen Objekten und Abstraktionen besteht, und die Beziehungen zwischen ihnen mit einem entsprechend gestalteten Hiearchical modelliert werden können OOP-Klassenstruktur.
Wir versuchen, einen OO-Stil auf ein relationales System zu setzen. In C # land erhält dies ein stark typisiertes System, so dass alles von Anfang bis Ende kompiliert und getestet werden kann. Die Datenbank ist schwer zu testen, zu refaktorieren, etc. OOP erlaubt uns, unsere Anwendung in Schichten und Hierarchie zu organisieren, die relationale nicht erlaubt.
Nun, Sie haben eine theoretische Frage.
Zunächst möchte ich Ihnen zustimmen, dass OOP keine All-Lösung ist. Es ist gut für etwas, es ist nicht gut für andere. Aber das heißt nicht, dass es nicht skaliert. Einige schrecklich komplexe und riesige Systeme wurden mit OOP entwickelt.
Ich denke, OOP ist so beliebt, weil es es verdient hat. Es löst einige Probleme ziemlich wunderbar, es ist leicht, in Bezug auf Objekte zu denken, weil wir das tun können, ohne uns selbst neu zu programmieren.
Also, bis wir alle eine bessere Alternative finden können, die tatsächlich im praktischen Leben funktioniert, denke ich, dass OOP eine ziemlich gute Idee ist und auch relationale Datenbanken.
Es gibt wirklich keine Grenzen, mit denen OOP umgehen kann - genauso wie es keine wirkliche Grenze gibt für das, womit C umgehen kann, oder Assembler für diese Angelegenheit. Alle sind Turing-komplett, das ist alles was du wirklich brauchst.
OOP gibt Ihnen einfach einen höheren Weg, das Programm zu zerlegen, genauso wie C ein höherer Level als Assembler ist.
Der Artikel über Entitätssysteme besagt nicht, dass OO das nicht kann - tatsächlich klingt es so, als ob sie OOP verwenden, um ihre Entitäten, Komponenten usw. zu implementieren. In jeder komplexen Domäne gibt es verschiedene Möglichkeiten, sie zu zerlegen, und mit OOP können Sie es irgendwann auf die Objekt- / Klassenebene herunterbrechen. Dies schließt nicht aus, übergeordnete konzeptionelle Frameworks zu haben, die zum Entwurf des OOP-Systems verwendet werden.
Das Problem ist nicht der objektorientierte Ansatz in den meisten Situationen, das Problem ist die Leistung und tatsächliche Entwicklung der zugrunde liegenden Hardware.
Das OO-Paradigma nähert sich der Softwareentwicklung, indem es uns eine Metapher der realen Welt liefert, wenn wir Konzepte haben, die die allgemein akzeptierten und erwarteten Eigenschaften und das Verhalten realer Objekte in der Welt definieren. Ist die Art, wie Menschen Dinge modellieren und wir die meisten Probleme damit lösen können.
Theoretisch können Sie jeden Aspekt eines Spiels, Systems oder was auch immer mit OO definieren. In der Praxis wird sich Ihr Programm einfach zu langsam verhalten, so dass das Paradigma durch Optimierungen durcheinander gebracht wird, die die Einfachheit des Modells von der Performance ablenken.
Auf diese Weise sind relationale Datenbanken nicht objektorientiert, so dass wir eine objektorientierte Ebene zwischen unserem Code und der Datenbank erstellen ... dadurch haben Sie einen Teil der Leistung der Datenbank verloren und etwas an ihrer Aussagekraft, weil von der Sichtweise des OO-Paradigmas eine relationale Datenbank ist eine vollständige Klasse, ist ein sehr komplexes Objekt, das Informationen bereitstellt.
Aus meiner Sicht ist OO ein nahezu perfekter Ansatz im theoretischen Sinne des Wortes, da er sich eng an die Art und Weise anpasst, wie wir Menschen denken, aber er passt nicht gut zu den begrenzten Ressourcen der computergestützten Entwicklung ... also nehmen wir Abkürzungen. Auf der und, Leistung ist viel wichtiger als theoretische Organisation oder Klarheit, so dass diese Abkürzungen zu Standards oder üblichen Praktiken werden.
Das heißt, wir passen das theoretische Modell an unsere derzeitigen Beschränkungen an. In den späten 70-er Jahren war objektorientiert einfach unmöglich ... es würde zu vielen Aspekten und zu wenig Leistung führen, also verwendeten wir einen vereinfachten Ansatz, so dass Sie keine Objekte oder Klassen hatten. Sie hatten Variablen. Aber das Konzept war zu dieser Zeit das gleiche. Gruppen von Variablen beschrieben verwandte Konzepte, Eigenschaften, die heute Füße in ein Objekt. Steuersequenzen, die auf einem Variablenwert basieren, wurden zum Ersetzen von Klassenhierarchien usw. verwendet.
Ich denke, wir verwenden OOP schon lange und werden es noch lange verwenden. Wenn sich die Hardwarefunktionen verbessern, können wir das Modell vereinfachen, sodass es anpassungsfähiger wird. Wenn ich perfekt (fast) das Konzept einer Katze beschreibe (was eine Menge an Beschreibungen für viele involvierte Konzepte beinhaltet), kann dieses Konzept überall wiederverwendet werden ... das Problem ist hier nicht, wie ich gesagt habe, mit dem Paradigma selbst, aber mit unseren Einschränkungen, es zu implementieren.
BEARBEITEN: Beantworten Sie die Frage, warum Sie reines OO verwenden sollten. Jede "Wissenschaft" möchte ein vollständiges Modell haben, um Dinge darzustellen. Wir haben zwei physikalische Modelle, um die Natur zu beschreiben, eine auf der mikroskopischen und eine auf der makroskopischen Ebene, und wir wollen nur eine haben, weil sie Dinge vereinfacht, die uns einen besseren Weg geben, Dinge zu beweisen, zu testen und zu entwickeln. Bei OO gilt der gleiche Vorgang. Sie können ein System nicht analytisch testen und nachweisen, wenn das System keinen genauen Regeln folgt. Wenn Sie zwischen Paradigmen in einem Programm wechseln, dann kann Ihr Programm nicht richtig analysiert werden, es muss in jedem analysiert, analysiert und dann erneut analysiert werden, um zu sehen, dass die Interaktionen korrekt sind. Es macht es sehr viel schwieriger, ein System zu verstehen, weil es tatsächlich zwei oder drei Systeme gibt, die auf unterschiedliche Weise interagieren.
Jungs, geht es nicht mehr um ORM als um OOP? OOP ist eine Art der Programmierung - die Sache, die tatsächlich verglichen wird, ist eine relationale Datenbank, die auf Objekte abgebildet ist.
OOP ist eigentlich mehr als nur das ORM! Es ist auch nicht nur die Vererbung und Polymorphie! Es ist eine extrem breite Palette von Design-Mustern und vor allem ist es die Art, wie wir über die Programmierung selbst denken.
Jorge: Es ist in Ordnung, dass Sie auf den Optimierungsteil hingewiesen haben - was Sie nicht hinzugefügt haben ist, dass dieser Schritt zuletzt durchgeführt werden sollte und in 99% Fällen ist der langsame Teil nicht der OOP.
Jetzt klar und einfach: der OOP-Stil mit allen hinzugefügten Prinzipien (sauberer Code, Verwendung von Designmustern, nicht zu tiefen Vererbungsstrukturen und lassen Sie uns nicht Einheitentests vergessen!) es eine Möglichkeit, mehr Leute zu verstehen, was Sie tun schrieb. Das wiederum ist notwendig, damit Unternehmen ihre Geschäfte sichern können. Das ist auch ein Rezept für kleine Teams, um ein besseres Verständnis für die Community zu bekommen. Es ist wie eine gemeinsame Metasprache über der Programmiersprache selbst.
Es ist immer einfacher über Konzepte aus puristischer Sicht zu reden. Sobald Sie mit einem wirklichen Lebensproblem konfrontiert werden, werden die Dinge schwieriger und die Welt ist nicht mehr nur schwarz und weiß. Genau wie der Autor des Artikels sehr gründlich darauf hinweist, dass sie nicht tun, sagt OOP "OOP purist", dass OOP der einzige Weg ist. Die Wahrheit liegt irgendwo dazwischen.
Es gibt keine einzige Antwort, solange Sie die verschiedenen Möglichkeiten (OOP, Entitätssysteme, funktionale Programmierung und vieles mehr) verstehen, Dinge zu tun und einen guten Grund dafür geben können, warum Sie in einem gegebenen Fall eines wählen Situation ist es wahrscheinlicher, dass Sie Erfolg haben.
Über Entitätssysteme. Es ist eine interessante Konzeption, aber es bringt nichts wirklich Neues. Zum Beispiel heißt es:
OOP-Stil wäre für jede Komponente, keine oder mehrere Methoden zu haben, die irgendein externes Ding irgendwann aufrufen muss. Der ES-Stil besteht darin, dass für jede Komponente keine Methoden zur Verfügung stehen, sondern dass das kontinuierlich laufende System eigene interne Methoden für verschiedene Komponenten nacheinander ausführt.
Aber ist es nicht das gleiche wie Martin Fowlers Anti-Pattern namens "Anemic Domain Model" (das heutzutage sehr häufig verwendet wird) link ?
Also ist ES im Grunde eine "Idee auf dem Papier". Um es zu akzeptieren, muss es mit funktionierenden Codebeispielen bewiesen werden. Es gibt kein einziges Wort in dem Artikel, wie diese Idee in der Praxis umgesetzt werden kann. Über Skalierbarkeitsprobleme wurde nichts gesagt. Nichts über Fehlertoleranz gesagt ...
Was Ihre eigentliche Frage anbelangt, sehe ich nicht, wie die im Artikel beschriebenen Entitätssysteme relationalen Datenbanken ähnlich sein können. Relationale Datenbanken haben keine "Aspekte", die im Artikel beschrieben werden. In der Tat ist relationale - basierend auf Tabellen Datenstruktur - sehr begrenzt, wenn es zum Beispiel mit hierarchischen Daten arbeitet. Begrenzter als zum Beispiel Objektdatenbanken ...
Könnten Sie klarstellen, was genau Sie hier zu vergleichen und zu beweisen versuchen? OOP ist ein Programmierparadigma, eines von vielen. Es ist nicht perfekt. Es ist keine Wunderwaffe.
Was bedeutet "relationsorientierte Programmierung"? Datenzentriert? Nun, Microsoft war auf dem Weg zu mehr datenzentriertem Programmierstil, bis sie auf Linq2Sql verzichten und sich voll auf ihr O / RM EntityFramework konzentrieren.
Auch relationale Datenbanken sind nicht alles. Es gibt viele verschiedene Arten von Datenbankarchitekturen: hierarchische Datenbanken, Netzwerkdatenbanken, Objektdatenbanken usw. Und diese können noch effizienter als relational sein. Relational ist so populär aus den gleichen Gründen, warum OOP so populär ist: Es ist einfach, sehr einfach zu verstehen und meistens effizient genug.
Ironischerweise, als die Programmierung angekommen war, war es viel einfacher, größere Systeme zu bauen, dies spiegelte sich im Anstieg der Software auf dem Markt wider.
In Bezug auf Größe und Komplexität können Sie mit gutem Design ziemlich komplexe Systeme erstellen. siehe ddd Eric Evans für einige prinzipielle Muster zur Handhabung von Komplexität in oo.
Allerdings sind nicht alle Problemdomänen für alle Sprachen am besten geeignet. Wenn Sie die Freiheit haben, eine Sprache auszuwählen, wählen Sie eine, die zu Ihrer Problemdomäne passt. oder baue eine dsl, wenn das passender ist.
Wir sind schließlich Softwareingenieure, es sei denn, es gibt jemanden, der Ihnen sagt, wie Sie Ihren Job machen sollen, verwenden Sie einfach die besten Tools für den Job oder schreiben Sie sie:)
Tags und Links oop