Jede ausgereifte MVC-Anwendung hat ein Modell, das außer Kontrolle geraten ist. Die Tabelle hat 20 Spalten; sie speichert Benutzereinstellungen und Systeminformationen; sie versendet E-Mail-Benachrichtigungen und schreibt andere Modelle in die Datenbank. Das Modell umfasst so viel Anwendungslogik, dass jedes neue Feature wahrscheinlich durch sie hindurch muss. Es ist die Klasse, die Entwickler jedes Mal stöhnen lässt, wenn sie sie öffnen.
Wie konnte es soweit kommen?
Web-Anwendungen haben in der Regel einen einzigen Zweck: die Anzeige eines einzigen Datentyps – vielleicht ist es Artikel für ein Online-Journal oder Kleidungsartikel für einen Modehändler. MVC-Anwender übernehmen häufig Konzepte aus ihren Produkt-Whiteboarding-Sitzungen und übertragen diese direkt in Datenbankmodelle. Wir beginnen also mit einem Datenbankmodell, das ein zentrales Konzept der Anwendung darstellt. Wenn weitere Geschäftsanforderungen entstehen, ist es am einfachsten, diese durch das Hinzufügen von Spalten zum bestehenden Modell zu berücksichtigen. Wenn Sie dies im Laufe der Zeit umsetzen, erhalten Sie ein Gottes Objekt.
Das Problem bestand von Anfang an darin, die auf Produktebene skizzierten, lockeren Konzepte in den Code zu integrieren. Softwareentwickler sollten sich darüber im Klaren sein, dass die Konzepte, die Menschen im Alltag und Denken verwenden, äußerst ungenau und voller impliziter Annahmen sind. Das Hervorheben impliziter Annahmen ist oft die wichtigste Aufgabe eines Softwareentwicklers. Daher ist es ein Wunder, dass wir diese Konzepte von der Produktebene übernehmen und in unseren Code einbetten. Es bedeutet nur, versteckte Randfälle zu identifizieren, die eine klärende Logik in die bestehende Klasse integrieren müssen.
Der Begriff Volkspsychologie ist hier aufschlussreich. Alltagspsychologie bezieht sich auf die angeborenen, lose spezifizierten Theorien, die Menschen über das Funktionieren anderer Menschen haben und die sie nutzen, um Motivationen abzuleiten und Verhalten vorherzusagen. Diese „Alltags“-Theorien funktionieren im Kontext des menschlichen Alltagslebens recht gut, sind aber wissenschaftlich nicht fundiert und enthalten blinde Flecken. In ähnlicher Weise werden in der Softwarebranche „Alltags-Objektmodelle“ verwendet. Dies sind die informellen Konzepte, die Menschen konstruieren, um mit anderen Menschen über Software zu diskutieren – die Worte, die Produktmanager mit Softwareentwicklern verwenden, die Kästchen, die auf das Whiteboard gezeichnet werden. Sie funktionieren recht gut, wenn man Konzepte mit anderen Menschen diskutiert, die in ihren Interpretationen großzügig sein können, aber in sich zusammenfallen können, wenn sie als Code formalisiert werden. Diese Konzepte sind ein nützlicher Ausgangspunkt, um die Produktfunktionen zu formulieren, aber aus einer OO-Perspektive sind sie zu weit gefasst, um als Klassen verwendet zu werden. Sie neigen dazu, Logik anzuhäufen, da sie implizit einen so großen Teil des Problembereichs umfassen.
So wie die erste Hürde beim Programmierenlernen darin besteht, Gedanken explizit als Schritte eines Algorithmus zu formulieren, müssen erfahrene Softwareentwickler gängige Objektmodelle in explizite Komponenten zerlegen, die als Klassen verwendet werden können. Im Produktbereich beginnen wir vielleicht mit einem allgemeinen „Benutzer“-Konzept, entdecken aber bei genauerem Hinsehen verschiedene Logikelemente, die besser als separate Klassen funktionieren – eine Abrechnungspräferenz, ein aktueller Status oder Benachrichtigungseinstellungen. Jedes dieser Elemente benötigt eine eigene Logik, um die Produktanforderungen zu erfüllen. Wenn wir diese nicht trennen, um Platz für die Logik zu schaffen, entsteht unnötiger Datenmüll.
Bei der Datenmodellierung geht es oft darum, Geschäftskonzepte in Software zu kodieren. Tatsächlich geht es jedoch darum, Modellklassen als Werkzeuge zum Aufbau eines Systems zu verwenden. Codebasen lassen sich oft besser verwalten, wenn große Modelle in Komponenten zerlegt werden, die jeweils einen bestimmten Teil der Domänenlogik abdecken.