Ich habe ein Factory-Objekt ChallengeManager , um Instanzen eines Challenge -Objekts für ein Spiel zu generieren, das ich gerade erstelle. Es gibt viele Herausforderungen. Die Konstruktoren für jede Challenge -Klassenableitung sind unterschiedlich, jedoch gibt es eine gemeinsame Schnittstelle zwischen ihnen, die in der Basisklasse definiert ist.
Wenn ich manager.CreateChallenge() aufruft, gibt es eine Instanz von Challenge zurück, was einer der abgeleiteten Typen ist.
Idealerweise möchte ich den Code für die Objektkonstruktion in der abgeleiteten Klasse selbst behalten, so dass der gesamte Code, der sich auf dieses Objekt bezieht, gemeinsam lokalisiert wird. Beispiel:
%Vor% Jetzt muss mein ChallengeManager.CreateChallenge() -Aufruf nur noch die Klasse entscheiden, die MakeChallenge() aufrufen soll. Die Implementierung der Konstruktion ist in der Klasse selbst enthalten.
Unter Verwendung dieses Paradigmas muss jede abgeleitete Klasse eine statische Methode MakeChallenge() definieren. Da es sich bei der Methode jedoch um eine statische Methode handelt, kann ich hier kein Interface verwenden und benötige es.
Es ist keine große Sache, da ich leicht daran denken kann, jeder abgeleiteten Klasse die richtige Methodensignatur hinzuzufügen. Ich frage mich jedoch, ob es ein eleganteres Design gibt, das ich in Betracht ziehen sollte.
Ich mag das Muster sehr, das du beschreibst und benutze es oft. Die Art, wie ich es mache, ist:
%Vor% Dieses Muster hat viele schöne Eigenschaften. Niemand kann ein neues Challenge erstellen, weil es abstrakt ist. Niemand kann eine abgeleitete Klasse erstellen, da Challenge 's Standard-Ctor privat ist. Niemand kann auf ChallengeA oder ChallengeB zugreifen, weil sie privat sind. Sie definieren die Schnittstelle zu Challenge und das ist die einzige Schnittstelle, die der Client verstehen muss.
Wenn der Kunde ein A möchte, fragt er Challenge für eins, und sie bekommen es. Sie müssen sich nicht darum kümmern, dass A hinter den Kulissen von ChallengeA implementiert wird. Sie erhalten nur eine Challenge , die sie verwenden können.
Sie "dezentralisieren" die Fabrik, so dass jede Unterklasse selbst für die Erstellung verantwortlich ist.
Häufiger würden Sie eine zentrale Factory kennen, die über die möglichen Subtypen und deren Erstellung Bescheid weiß (oft genug, indem Sie einfach eine neue Instanz erstellen und diese Instanz als gemeinsame Schnittstelle oder gemeinsame Basisklasse zurückgeben). Dieser Ansatz vermeidet das Problem, das Sie derzeit haben. Ich sehe auch keinen Nutzen für Ihre derzeitige Vorgehensweise. Sie erhalten derzeit keine Kapselung oder Wiederverwendung von Code über die typische Implementierung einer Fabrik.
Weitere Informationen finden Sie unter
Tags und Links c# design-patterns factory-pattern