Gibt es einen Namen oder eine bestimmte Regel für Objekte, die Objekte enthalten, die ... usw. enthalten? Ich arbeite mit einem komplexen System, das oft Objekte hat, die 5-10 Schichten tief laufen. Ein Grund, warum ich dafür höre, ist, dass ich viele Daten gleichzeitig vom Server zum Client übergebe. Gibt es dafür einen besseren Weg?
Bearbeiten: Es scheint, dass es eine Kombination von ein paar Anti-Muster ist. Das Domain-Modell sollte aufgeräumt werden, und die folgenden Antipatterns sind die Gerüche: Train Wreck Pattern, und Alles außer der Küche-Spüle-Karte
Sieht aus wie ein Domain-Modell, das sauer geworden ist (kein antipattern Name, BTW :) Es stammt von der Illusion, dass es so etwas wie ein wohldefiniertes Domänenmodell gibt. In Wirklichkeit gibt es einige Aspekte der Problemdomäne, die elegant modelliert werden können, aber auf der feineren Detailebene gibt es Ausnahmen für Ausnahmen und Sonderfälle für Spezialfälle, die jeweils für eine einzelne Dienstmethode spezifisch sind , die diese Eleganz zerstören.
Das Auftreten vieler verschachtelter Objekte ist oft das Ergebnis eines kontinuierlichen Prozesses, bei dem das Domänenmodell immer feiner granuliert wird, in der Hoffnung, dass jede Instanzvariable in verschiedenen Kontexten wiederverwendet werden kann. Es gibt einen Bruchpunkt, an dem der dogmatische Imperativ, jedes Domänenattribut wiederzuverwenden, keinen Sinn mehr macht.
Mein Ausweg besteht darin, aufzuhören, ein einheitliches Domänenmodell zu erstellen und Objekte zu verwenden, die speziell für jeden Serviceaufruf entworfen wurden. Diese Objekte können sich auf einige der gut definierten Domänenobjekte stützen, fügen jedoch spezifische Informationen separat und in einer Weise hinzu, die andere Serviceaufrufe nicht beeinträchtigen.
Ich kenne keinen Namen für diese Art von Objektbaum. Aber ein bekanntes Anti-Pattern ist das Train Wreck Pattern , das auftritt, wenn Code übermäßige Methodenverkettung verwendet.
%Vor%Es ist eine gute Faustregel, alles von
zu übernehmen %Vor%in eine Methode auf
%Vor% Nennen wir diese Methode performSomeActionDeepDownTheObjectTree() .
Der Begriff ist "Objektorientierung", wobei Sie große komplexe Probleme in kleinere Probleme zerlegen, indem Sie Klassen von Objekten definieren, von denen jede einen kleinen Teil des Problems einkapselt. Die Art und Weise, wie Objekte interagieren, erfolgt über die Nachrichtenübergabe, und Objekte finden andere Objekte, an die Nachrichten übergeben werden sollen, indem sie mit den Objekten beginnen, die sie enthalten.
Je größer und komplexer das Problem ist, desto mehr Arbeit müssen Sie tun, um es in überschaubare Teile zu zerlegen, so dass Sie mehr Ebenen von Objekten erhalten. Manchmal werden kleine einfache Probleme schlecht in eine große Anzahl von Objekten zerlegt, aber das macht die Objektorientierung selbst nicht zu einem Anti-Muster.
Das Hauptproblem besteht einfach darin, dass die Datenobjekte durch Verschachtelung zu groß werden und irrelevante Daten enthalten. Beispiel: Du sortierst Vögel und statt eines einfachen Vogelobjektes erhältst du einen Objektvogel mit Federn, Schnabel, möglichen Parasiten, Luft, möglichen HaustierenNestern, Krebs und Nahrungsmitteln, Nahrungsmitteln enthält Früchte, Insekten, Würmer, Samen, Samen enthält Eiche, Ulme , Distel, möglichTiere, die Kansensaat usw. usw. -
Die Alles außer der Küchenspüle Karte Anti-Muster ist wahrscheinlich am ehesten passen.
Bei einem komplexen Prozess mit vielen komplexen Regeln wird alles (Geschäftslogik, verwandte und nicht verwandte Verfahren usw.) in die Karte verschoben.
Der beste Weg, dies zu lösen, ist eine Filteroperation, bei der Sie eine stark typisierte Schnittstelle wie interface BirdList extends Iterable<Bird> {} angeben und das Abfragesystem eine Implementierung bereitstellt, die nur durch genug Daten unterstützt wird, um diese Schnittstelle zu unterstützen.
Ihre API könnte eine Reihe verschiedener Schnittstellen wie BirdList und BirdFeedingHabitMap , BirdNestingHabitMap usw. bereitstellen. Clients können eine Liste von Schnittstellen erstellen, die sie benötigen, und das Abfragesystem analysiert sie, ruft die Daten ab und verwendet Proxy-Klassen , um eine Implementierungsklasse zusammenzustellen, die die Abfrageergebnisse in einem Typ verfügbar macht -sicherer Weg.
Objekte mit Objekten, die ... etc enthalten
heißt eine Liste und vollkommen in Ordnung;)
Aber Sie haben Recht, lange Sequenzen von Methodenaufrufen sind alles andere als in Ordnung und ein sauberer Code-Geruch, der unangemessene Intimität genannt wird.
Unangemessene Intimität kann increase coupling, decrease cohesion , geht gegen die law of demeter und die Regel tell, don't ask .
Referenzen : Wenn Sie diese Begriffe nachschlagen, werden Sie eine fantastische Antwort finden. Besonders gut sind Cohesion and Coupling und das Buch Agile Softwareentwicklung, Prinzipien, Muster und Praktiken von Robert C. Martin .
Tags und Links java refactoring anti-patterns