Ich habe ein Problem mit einer relativ großen Objekthierarchie wie folgt:
Wie Sie sehen können, ist die Hierarchie relativ komplex und an mindestens einer Stelle zyklisch (das Netzwerk hat viele Agenten mit einer Nachbarschaft, die ein Netzwerk hat). Im Moment verwende ich eine statische Konstrukt-Methode für eine GameFactory -Klasse, um die gesamte Hierarchie zu konstruieren, aber ich bin mir ziemlich sicher, dass dies der am wenigsten flexible Weg ist, dies zu tun!
Was ist das beste Muster für den Aufbau einer komplexen Hierarchie von Objekten? Ich habe die Muster Factory Method , Abstract Factory und Builder gelesen und ich denke, eines der Factory-Muster ist geeignet, aber ich weiß nicht, wie ich es auf eine so komplexe Hierarchie anwenden soll.
Wie ich es sehe, brauche ich viele Fabriken für jeden Teil des Systems, aber dies wird zu einer Sammlung von Fabrikklassen führen, die die Modellklassen spiegeln.
Bearbeiten: Aus der Diskussion in den bisherigen Vorschlägen wurde deutlich, dass ich mehr darüber erklärt haben sollte, warum Factors meine Objekthierarchien erstellen müssen, anstatt Konstruktoren selbst den Aufbau ihrer Abhängigkeiten zu erlauben.
Dies liegt daran, dass ich die Abhängigkeitsinjektion zur Unterstützung der testgesteuerten Entwicklung verwende. Ich gehe bei den Tests eine spottende Herangehensweise ein, die die Fähigkeit erfordert, Mocks zu injizieren, die die Abhängigkeiten eines Objekts darstellen. Daher muss ich new in allen Konstruktoren vermeiden.
Aus den bisherigen Vorschlägen scheint es eine Reihe von Möglichkeiten zu geben, dies zu tun:
Ich bin geneigt, den letzten Weg zu gehen. Was ist der Konsens über die beste Vorgehensweise in dieser Situation?
Bearbeiten: Ich widerrufe die aktuelle Antwort (die von Patrick Karcher), da jetzt, da der Fokus dieser Frage geklärt ist, keiner der Vorschläge vollständige Antworten ist.
Es ist wichtig zu verstehen, warum genau Sie eine Fabrik brauchen. Wie bei vielen "guten" Praktiken kann eine Fabrik bestimmte Vorteile bringen, die Sie manchmal wollen und die Sie nur erhalten, wenn Sie sie richtig verwenden.
Oft ist die factory eine andere Klasse in Ihrem Objektmodell. Zum Beispiel haben Sie oft einen Spieler , weil Sie eine Nachbarschaft mit einer Spieler Sammlung haben, und Sie durchlaufen diese, Sachen zu den Spielern machen. Oder Sie beginnen mit einem Netzwerk -Objekt. Oder (ich nehme an) Sie haben bereits einen Spieler von dem Sie eine Freundschaft erhalten und Sie erhalten den Spieler daraus. Eine Freundschaft ist also eine Factory für Player Objekte und ein Player ist eine Factory für Friendship Objekte!
Sie haben jedoch manchmal Grund für nicht domänenspezifische Factory-Objekte . Sie haben möglicherweise eine Factory-Klasse als Ausgangspunkt für Objekte, mit denen Sie Ihre Logik beginnen. Oft werden sie verwendet, wenn es viele knifflige Möglichkeiten gibt, einige Ihrer Objekte zu instanziieren und die Factory ist eine gute Möglichkeit, sie zu organisieren. Manchmal müssen Ihre Objekte beispielsweise mit einer Datenschicht und einem Benutzer und einem Kontext instanziiert werden, und eine Factory kann diese Dinge verwalten, Ihre Objekte erstellen und Sie davor bewahren, sich in vielen verschiedenen Konstruktoren wiederholen zu müssen. Manchmal kann die Fabrik automatisch gemeinsame Referenzen erzeugen, die Ihre verschiedenen Werkzeuge benötigen.
Es gibt eine Verwendung einer Fabrik, die schnell an Popularität gewinnt und eine besondere Erwähnung verdient. Dies ist die Verwendung einer Factory-Klasse, um eine Abhängigkeitsschicht hinzuzufügen , insbesondere für Komponententests .
Mein Rat: Wenn Sie keinen bestimmten Grund haben, ein Fabrikobjekt zu verwenden, machen Sie sich keine Sorgen. Erstellen Sie Ihre Objekte einfach mit guten Konstruktoren. Dann ist es natürlich, Eigenschaften hinzuzufügen, die verwandte Objekte zurückgeben; Das werden deine ersten Fabriken sein. Dies könnte ein gutes Beispiel dafür sein, wie Sie sich zunächst nicht um Entwurfsmuster kümmern müssen. Entwurfsmuster liefern keinen Erfolg. Sie machen. Muster, wie die verschiedenen Fabrikmuster, können das objektorientierte Grunddenken unterstützen, aber nicht ersetzen.
Haben Sie bestimmte Gründe dafür, warum Sie dedizierte Fabrikobjekte benötigen?
Wenn nichts variiert , d. Wenn Ihr Konstruktionsprozess fest ist, würde ich den einfachsten Weg empfehlen: Lassen Sie die Objekte selbst darauf achten, ihre abhängigen Objekte zu bauen, und stellen Sie Verbindungen her (möglicherweise bidirektional).
Beispiel: Für ein übergeordnetes Objekt mit einer Sammlung von untergeordneten Elementen kann das übergeordnete Objekt über eine addChild-Methode verfügen, die die Kohärenz der bidirektionalen Beziehung sicherstellt:
Wenn etwas variiert , wie Unterklassen als sollte in einigen Kontext verwendet werden, dann müssen Sie genau definieren, was variiert. Erst nachdem Sie Ihren genauen Bedarf gefunden haben, können die korrekten Muster erscheinen. : -)
Wir könnten mit dem letzten Teil helfen, aber Sie sind der einzige, der die erforderlichen Informationen geben kann ...; -)
KLE hat recht, wenn es anders geht, je nachdem wie statisch die Beziehungen sind. Ich würde hinzufügen, dass es für Factory-Klassen typisch ist, das Objektmodell zu spiegeln. Eine einfache Möglichkeit, sie als intelligentes Objekt zu betrachten, das wie die verschiedenen Klassen Ihres Modells verbindet.
Tags und Links design-patterns architecture design oop