Verstehen Sie mich nicht falsch - OOP ist derzeit das Beste, um große Codebasen zu strukturieren.
Aber warum versuchen Leute irgendetwas in eine OO-Ansicht zu stopfen?
Zum Beispiel: Jedes Lehrbuch über OOP enthält ein "einführendes Beispiel", das versucht, eine kleine Ansicht unserer realen Welt in einem OO-Vererbungs- und Zusammensetzungs- und Aggregationskonstrukt auszudrücken. Und inzwischen wissen wir alle, dass es niemals zu dem allmächtigen OO-Konstrukt kommt, das das OO-Modell selbst versprach! Die Autoren haben gerade eine Illusion geschaffen.
Meine persönliche Meinung ist, dass OO schön ist, Code zu strukturieren, aber er ist nicht dafür geeignet, Daten der realen Welt und seine Beziehungen zu repräsentieren. IMHO das relationale Modell ist überlegen, wahrscheinlich ist jedes andere Modell überlegen.
In OO Design wurde es üblich, die Komposition über Vererbung zu empfehlen - wann immer möglich. Dieses mächtige Modell einer alles-erblichen Welt-von-Objekten-Sache, die erstklassige Bücher andeuten, ist nur eine Illusion. Also, OO selbst kann eine Illusion sein? Und aktuelle zusammensetzungszentrierte OO-Modelle sind nichts anderes als einfache Datenstrukturen mit einem standardisierten syntaktischen Zucker - das ist nicht viel anders als bei Pre-OOP-Ansätzen.
Ein anderes Beispiel: Stellen Sie sich ein wirklich komplexes Modell unserer realen Welt vor. Neben allem anderen gibt es Steinblöcke und Menschen . In einem OO-Modell sind Menschen Säugetiere, Tiere sind organische Lebensformen und so weiter (die streng starre Vererbungshierarchie, die OO auferlegt, weißt du ..). Die Steinblöcke sind nicht-organische Dinge, vielleicht sind sie starre Körper oder was auch immer, es ist egal.
Wenn Sie ein Künstler sind und Sie einen Steinblock finden müssen, der eine gute "Schablone" (?) für eine Statue eines Menschen mit gegebener Breite, Höhe und Dicke macht, dann müssen Sie eine Menge Sonderfälle schreiben OO-Code zum Abrufen dieser Attribute aus dem menschlichen Modell und aus dem Steinblockmodell. Oder alternativ wurde Ihr ganzes Weltmodell so aufgebaut, dass es geometrische Abfragen unterstützt - dann wäre es einfach! Aber das führt zu der Schlussfolgerung, dass OOP bei der Darstellung von Daten so saugt, dass wir sie in verschiedenen Anwendungsfällen verwenden können. OOP erlaubt uns nur Daten für genau die Use Cases darzustellen, die wir vorher entworfen haben. Nicht viel mehr. Jegliche Verwendung außer diesen vorherbestimmten Fällen kann nur mit viel Fiedeln gemacht werden. Das relationale Modell versucht zumindest, Daten in wiederverwendbarer Weise darzustellen. (wiederverwendbar: OOP hat dieses Wort einmal selbst besetzt)
Warum all das hasst?
Ich arbeite an einem Projekt, das ein ORM verwendet - und es ist einfach scheiße. Es begann mit der Modellierung der Datenbank (aufgrund von ORM-Einschränkungen), dann kam die Zeit, um die Einzelheiten des ORM (und seine Fehler und weiteren Einschränkungen) zu lernen, dann kam die Angst vor implizit stattfindenden Sachen (new thing (); ding - & gt; save () erstellt eine neue Zeile, aber wo ist "Sache" verwurzelt? Warum versuchen die Leute, Objekte so "unabhängig" wie möglich zu machen, sondern im Hintergrund viel tiefere Abhängigkeiten von freaking pro-table-singletons, das kommunizieren mit Verbindung-Singletons .. oh mein Gott .. ich schweife ab).
So viele Dinge, die in ein paar Zeilen SQL und einer süßen winzigen Abfrage-API hätten erledigt werden können, wurden in Hunderten oder sogar Tausenden von Zeilen von "Business Logic" -Code durchgeführt (natürlich in der Anwendungsschicht, nicht in der Datenbank) wo die Daten sind und wo Aggregation Funktionen wie count () oder sum () wäre billig). Ich denke, die Leute fühlen sich einfach besser, wenn sie in OOP arbeiten können. Aber das ist nur dumm.
Und die Schöpfer von ORM wollen nur die Benutzer von den "schmutzigen Sachen" fernhalten. Aber genau diese Leute sollten nicht ORM schreiben - das perfekte Beispiel: Ich bin der festen Überzeugung, dass der ORM-Creator-Typ von Leuten nicht einmal weiß, dass eine Datenbanktabelle zusammengesetzte Primärschlüssel enthalten kann! ; -)
Also, warum beschäftigt OOP so? Es ist nur eine halbherzige Abstraktion, aber die Leute schwören darauf für alles, wenn Sie einige fragen, können sie Ihnen sogar sagen, dass OOP den Weltfrieden schaffen wird.
Warum beschäftigt sich OOP so sehr mit Monopolisierung?
Es scheint mir, dass, wenn Ihre Business-Logik-Implementierung das Design Ihrer Datenbank vorantreibt, jemand den Wagen vor das Pferd stellt. Ich dachte, die Idee wäre, ein rationales (nein, ich habe nicht sagen, relationales) Datenmodell zu entwickeln und dann die Logik zu implementieren, die die Daten abfragt und aktualisiert.
Meine Erfahrung ist, dass, obwohl relationale Datenbanken hervorragend zum Speichern und Abfragen von Daten aus der Sicht des Benutzers sind, das Versuch, das relationale Modell in ein strukturiertes Programmier- oder OOP-Paradigma zu erweitern, extrem schwierig ist. Es gibt immer eine Übersetzungsschicht. Heute denkt jeder, dass ORM die Lösung ist. Und obwohl technisch jede Übersetzungsschicht, die zwischen einem relationalen Datenspeicher und einer objektorientierten Datenzugriffsschicht sitzt, ORM ist, wenn sie heutzutage Leute sehen, die über ORM sprechen, scheinen sie über einen automatisierten Weg zu sprechen, diese ORM-Schicht zu erzeugen.
>Ich bin nicht davon überzeugt, dass eine verallgemeinerte ORM-Lösung existiert. Jeder, den ich gesehen habe, ist voller Gefahren. Es ist ein Schmerz im Nacken, aber die einzigen zuverlässigen ORM-Schichten, die ich jemals gesehen habe, waren handkodiert. Zugegeben, ich habe in den letzten fünf Jahren nicht viel mit Datenbankmaterial gearbeitet, also haben sich die Dinge vielleicht geändert.
Ich stimme Ihnen zu, dass OOP weitgehend nur eine Menge von syntaktischem Zucker in einem soliden strukturierten Design ist. Es ist jedoch gut syntaktischer Zucker. Es formalisiert viele Dinge, die in der strukturierten Programmierung als "Best Practices" angesehen wurden, und fügt einige Dinge hinzu (Vererbung, Interfaces, Polymorphie ua), die in rein strukturierten Sprachen nur schwer oder gar nicht auszudrücken waren. Wir hätten sicherlich einige oder alle dieser Funktionen zu strukturierten Sprachen hinzufügen können, ohne den ganzen Weg zu OOP gehen zu müssen, aber warum? OOP war der offensichtliche nächste Schritt in der Entwicklung prozeduraler Programmiersprachen.
OOP ist nur ein weiteres Tool in der Toolbox, aber bedenken Sie, dass OO seit über 20 Jahren der Schwerpunkt der Mainstream-Programmiersprachen ist - angefangen von C ++ bis hin zu Java und C #. Das hat wahrscheinlich mehr damit zu tun, warum das Modell derzeit "so besetzt" ist als alles andere.
Der Punkt von OOP ist nicht notwendigerweise jede einzelne Facette jedes einzelnen Objekts in der Welt darzustellen. Der Punkt ist, die Sachen darzustellen, die dir wichtig sind. Angenommen, es gibt ein Haus. Jemand, der Immobilien macht, würde sich um den Standort, den Verkaufspreis usw. kümmern. Ein Bauunternehmer könnte sich um die Bauplan-ID oder etwas anderes kümmern, ich weiß nicht. Der Punkt ist, modellieren Sie die wichtigen Sachen und ignorieren Sie den Rest. Fügen Sie später hinzu, wenn Sie mehr Informationen benötigen.
Ja, das macht eine "Haus" -Klasse, die auf die App zugeschnitten ist und möglicherweise für andere nicht geeignet ist. Das allgemeine Ziel von OOP besteht nicht darin, Klassen wiederzuverwenden, obwohl das manchmal passiert. Der Punkt ist, Daten mit den Aktionen zu bündeln, die diese Daten beeinflussen können, und so ein Problem konzeptionell von Hunderten von Variablen und Funktionen auf einige Objekte mit bekannten und getesteten Schnittstellen und damit verbundenen Verhaltensweisen zu reduzieren.
OO ist "besetzt", weil es sich als eine ausgezeichnete Wahl für viele Programmierprobleme erwiesen hat. In ähnlicher Weise hat sich das relationale Modell als eine ausgezeichnete Wahl für viele Datenspeicherungs- und Wiederauffindungsprobleme erwiesen. Wenn ich "viele" sage, meine ich "so viele, dass alle anderen im Vergleich blass sind". In der Tat sind beide miteinander gekoppelt eine ausgezeichnete Kombination, aber es gibt eine Komplexität beim Mapping, wo diese beiden Paradigmen zusammentreffen, also ORM.
Ich dachte fast, Ihre Frage sei unaufrichtig, aber dann entschied ich, dass es ein Mangel an Erfahrung war (nicht als Beleidigung gedacht, sondern nur aus den Fragen / Behauptungen). Sie werden feststellen, dass es Probleme gibt, die so komplex sind, dass OO der einzig gangbare Weg ist, sie zu modellieren. Nicht alles ist eine datenbankgestützte Website oder ein Berichterstellungstool. Viele Systeme sind meist "Geschäftslogik", wobei die beste Lösung eine OO-Lösung ist (Beispiel aus meiner Erfahrung: Steuerung und Überwachung von Roboterflugzeugen und ihren verschiedenen Nutzlasten). Viele der beliebten datenbankgestützten Web-Frameworks sind OO + RDBMS (Rails, Grails, Java + Spring + Hibernate usw.), weil die Kombination so mächtig ist.
Zwar gibt es sicherlich Modeerscheinungen und klebrige, aber überholte Paradigmen. Ich schlage vor, dass Menschen, wenn es viele Möglichkeiten gibt (OO, funktionale Programmierung, RDBMS-zentrisch usw.), fast immer wählen, was am produktivsten ist. Für mindestens 10 Jahre war dies ein großer Teil der Softwareprobleme.
Denn am Ende des Tages ist es eine gute Annäherung an die Art, wie wir selbst Dinge modellieren. Der Zähler, der oft darauf angesprochen wird, ist, dass Computer kein Konzept von Objekten haben, es sind alles 1s und 0s, aber diese Analyse ist so leer wie zu sagen, dass alles menschliche Denken nichts anderes ist als Neuronen und elektrische Impulse (was es wahrscheinlich ist, aber es ist) nur nicht eine nützliche Art, die Dinge anzuschauen).
Sie mögen also keine Vererbung? Ich auch nicht. Die Vererbung von Verhalten ist die Wiederverwendung von Code durch den armen Mann. Die Vererbung der Schnittstelle ist andererseits großartig, weil sie uns Polymorphismus gibt.
Sie mögen keine ORMs? Niemand zwingt dich, sie zu benutzen. Es gibt einen Konflikt zwischen OOP und RDMS, von dem ich glaube, dass er nicht leicht zu beheben ist, und die meisten ORMs versuchen, dies zu lösen, sind ziemlich naiv. Die Einschränkungen von ORM sind kein Fehler in OOP.