Bei der Datenbankprogrammierung gibt es eine Technik namens "Normalisierung", die Sie mit den Daten durchführen, die Sie speichern möchten.

Hat jemand versucht, dieses Konzept auf das Objektdesign anzuwenden? Wie hast du? Wie ist es gelaufen?

Bearbeiten: Zum Erweitern / Verdeutlichen ist die Datenbanknormalisierung mehr als eine Reihe von Prinzipien zur Reduzierung der Redundanz. Es gibt tatsächlich Schritte und Phasen, die Sie durchlaufen, und zumindest mäßig objektive Maßnahmen, die Ihnen mitteilen, in welcher Phase Sie sich befinden. Das Objektdesign hat seine eigenen Prinzipien, und es gibt das Konzept des Geruchs dass du in XX-Form0,1,2 bist ... etc ... und Methoden, um auf die am nächsten "normalisierte" Ebene zu gelangen?

Während einige der zugrunde liegenden Spannungen, die die Datenbanknormalisierung vorantreiben, in einem OO-System nicht vorhanden sind, sind es einige. Diese haben zu OO-Entwurfsmustern und -Prinzipien geführt, die in gewisser Weise mit der Normalisierung vergleichbar sind, zumindest insofern, als OO-Systeme mit relationalen Datenbanken vergleichbar sind. Beispielsweise:

• Grundsatz der einheitlichen Verantwortung
• Trennung von Bedenken
• Einmal und nur einmal , auch bekannt als DRY

Mit anderen Worten, hat jemand versucht, Datenbanknormalisierungstechniken auf OOP anzuwenden? Nein, da OOP bereits Lösungen für die gemeinsamen Probleme bietet, die durch die Normalisierung für relationale Datenbanken gelöst werden.

Ja, ja ich habe

Ich habe über dieses Thema lange geschwiegen; Es ist Zeit, sich zu äußern.

• Hat jemand versucht, dieses Konzept auf das Objektdesign anzuwenden?

Ja. Ich arbeite seit über 20 Jahren an der Formalisierung der Objektnormalisierung (und damit der zugrunde liegenden objektorientierten Theorie).

• Wie hast du?

Durch die Erkenntnis, dass Daten und Code zumindest theoretisch austauschbar sind. Dies bedeutet, dass die Prinzipien der Normalisierung und der relationalen Operationen sowohl für Code als auch für Daten gelten können.

• Wie ist es gelaufen?

Bisher hat es ziemlich gut geklappt - ich glaube, die gewonnenen Erkenntnisse waren die "Geheimwaffen" meiner Fähigkeiten in den Bereichen Design, Analyse und Refactoring.

Ich habe darüber vorher noch nichts öffentlich gesagt, weil ich dachte, dass ich irgendwann Zeit haben würde, die Recherche abzuschließen - und die implizierten Werkzeuge selbst zu produzieren.

Aber ich bin zu dem Schluss gekommen, dass ich mit allem anderen, was in meinem Leben passiert, was wichtiger, lustiger und / oder rentabler ist, nicht die Zeit habe, die Forschung selbst abzuschließen. Je. Es besteht auch die erhebliche Möglichkeit, dass ich einfach nicht die erforderliche CS-theoretische Grundlage habe, um die Arbeit alleine zu erledigen.

Ich habe an der örtlichen Universität nachgefragt, ob ich einen oder zwei Doktoranden unterstützen möchte, wenn sie sich der Sache annehmen möchten, aber leider lehrt unsere örtliche Universität keine angemessene Grundlage für die Semantik von Programmiersprachen.

Es gab einige interessante Untersuchungen auf diesem Gebiet, aber alles, was mir bekannt ist, hat die Marke verfehlt. Entweder wird fälschlicherweise davon ausgegangen, dass die Normalisierung nicht für objektorientierte Modelle gilt, da sie aus einem relationalen Hintergrund stammt, oder es wird davon ausgegangen, dass die Normalisierung nur für die von Objekten definierten Daten gilt. Es gibt jedoch einige sehr interessante Near-Miss-Projekte ...

Das wirklich Interessante passiert, wenn Sie den Code normalisieren - was meiner Meinung nach die Grundlage für alle Umgestaltungen ist .

Jetzt denke ich, dass es das Beste ist, das Wort zu ergreifen, indem man vielleicht bittet, auf den DevDays 2011 in DC zu sprechen und herauszufinden, ob es eine Community gibt, die von diesem Zeug so begeistert ist wie ich.

Hier ein kleiner Vorgeschmack: Normalisierung ist der Prozess, etwas Minimales und Nicht-Redundantes zu machen. Das Don't Repeat Yourself (DRY) -Prinzip der objektorientierten Programmierung ist daher eine klare Manifestation der Ziele der Normalisierung. Ich glaube, ich kann zeigen, dass alle bekannten objektorientierten Entwurfs- / Programmierungs- / Umgestaltungsprinzipien die logische Folge der Objektnormalisierung sind. Ich denke, ich kann auch zeigen, dass es mit Systemen in Object Normal Form (ONF) interessantere Dinge gibt, als nur das Refactoring.

Dies begann als Kommentar zu Rein Henrichs exzellenter Antwort , wurde aber zu lang ...

Die Normalisierung gilt für relationale Daten. Es wird zur Vermeidung von Duplikaten verwendet, wodurch die Datenintegrität einfacher sichergestellt werden kann, da jedes Datum nur an einem Ort gespeichert wird. Sie normalisieren eine Datenbank, indem Sie Verstöße gegen ein normalisiertes Formular feststellen und korrigieren.

Objektorientierte Programmierung gilt für Operationen an Daten. Es ist dazu gedacht, Methoden zur Manipulation von Daten zusammenzufassen. Sie können ähnliche Techniken auf Klassen anwenden, um doppelte Methoden zu eliminieren, indem Sie sich beispielsweise ansehen, von welchen Daten die Operation manipuliert oder abhängt. Zum Beispiel würde 1NF in einer OO-Perspektive keine doppelten Operationen innerhalb einer Klasse haben. 3NF könnte einer guten Vererbungsstruktur entsprechen, in der häufig verwendeter Code zu einer Oberklasse gehört. Ich bin sicher, Sie könnten dort auch eine Stelle finden, an der die Abhängigkeitsinjektion angebracht werden kann. Sie erreichen ein besseres Design (obwohl bisher nichts Vergleichbares entdeckt wurde), indem Sie Verstöße gegen gute Designprinzipien und Refactoring feststellen.

Es gibt in keiner Welt wirklich algorithmische Methoden, um ein gutes Design zu erreichen. Wie Rein Hendrichs betont, gibt es viele Prinzipien, die potenzielle Probleme identifizieren können (auch bekannt als Codegerüche). Entwurfsmuster und Best Practices sind einige der Methoden, mit denen versucht wurde, sie anzugehen. Testgetriebene Entwicklungen versuchen, sie frühzeitig zu finden, indem sie den Code so ausführen, wie er extern sein wird. Genau wie bei der Datenbankentwicklung wird die beste Lösung mit Erfahrung und Analyse gefunden.

Ein sehr guter Ansatz zum Entwerfen von Geschäftsmodellobjekten, der der Normalisierung ähnelt, ist die UML-Modellierung in Farbe .

Es ist eine Designstrategie von Peter Coad, die dabei hilft, die Geschäftsmodellobjekte zu abstrahieren.

Leider ist das Buch - Java-Modellierung in Farbe mit UML: Enterprise-Komponenten und -Prozesse - ausverkauft und Sie können nur gebrauchte kaufen.

Über diese Technik gibt es im Internet einige Artikel.

Wenn Sie mit relationalem Design vertraut sind, finden Sie UML-Modellierung in Farbe als Orientierungshilfe:

• Peter Coads 'Modellieren in Farbe' - Notizen von Stephen R. Palmer

Haben Sie untersucht, ob Sie ORM-Java-Annotationen in Ihrem Code verwenden können, während Sie Ihr Klassendiagramm erstellen? Der Ruhezustand generiert die Datenbank, sobald die Modellierungsphase abgeschlossen ist. Das Diagramm ist in diesem Beispiel nur ein Betrachter des Codes.

Objektreferenzen oder -zeiger ähneln Fremdschlüsseln. Das ist so tief, wie ich bereit bin, darüber nachzudenken. :)

Eigentlich werde ich tiefer nachdenken. Wenn Sie Ihre Objekte mit einer Duplizierung von 0 Daten modellieren und Ihre Objekte "abfragen" und satzbasierte Aktualisierungen durchführen könnten, würde es keine Unterbrechung geben. Tatsächlich können Sie dies tun, indem Sie eine Objektkonsumentenbibliothek erstellen. Microsoft hat dies bereits berücksichtigt, ist jedoch die Richtung gegangen, dass die satzbasierte LINQ-Syntax Teil von C # über eine "Abfragebibliothek" wird.