Ist es verwirrend, diese Klasse eine "Fabrik" zu nennen?

Question

Mein Verständnis von einem Werk ist, dass sie die Instanziierung konkreter Klassen kapselt, die alle eine gemeinsame abstrakte Klasse oder Schnittstelle erben. Dadurch kann der Client von der Entscheidung, welche konkrete Klasse erstellt werden soll, entkoppelt werden, was wiederum bedeutet, dass Sie konkrete Klassen zu Ihrem Programm hinzufügen oder aus ihm entfernen können, ohne den Code des Clients ändern zu müssen. Möglicherweise müssen Sie die Fabrik ändern, aber die Fabrik ist "zweckgebunden" und hat eigentlich nur einen Grund, sich zu ändern - eine konkrete Klasse wurde hinzugefügt/entfernt.

Ich habe einige Klassen erstellt, die die Instanziierung von Objekten tatsächlich kapseln, aber aus einem anderen Grund: Die Objekte sind schwer zu instanziieren. Im Moment nenne ich diese Klassen "Fabriken", aber ich befürchte, dass das eine falsche Bezeichnung ist und andere Programmierer, die sich meinen Code ansehen, verwirren könnte. Meine "Factory"-Klassen entscheiden nicht, welche konkrete Klasse instanziiert werden soll, sondern sie garantieren, dass eine Reihe von Objekten in der richtigen Reihenfolge instanziiert wird und dass die richtigen Klassen an die richtigen Konstruktoren übergeben werden, wenn ich new() .

Zum Beispiel habe ich für ein MVVM-Projekt, an dem ich arbeite, eine Klasse geschrieben, um sicherzustellen, dass meine SetupView richtig instanziiert wird. Es sieht in etwa so aus:

public class SetupViewFactory
{
    public SetupView CreateView(DatabaseModel databaseModel, SettingsModel settingsModel, ViewUtilities viewUtilities)
    {
        var setupViewModel = new SetupViewModel(databaseModel, settingsModel, viewUtilities);
        var setupView = new SetupView();
        setupView.DataContext = setupViewModel;
        return setupView;
    }
}

Ist es verwirrend, dies eine "Fabrik" zu nennen? Sie entscheidet nicht zwischen mehreren möglichen konkreten Klassen, und ihr Rückgabetyp ist keine Schnittstelle oder ein abstrakter Typ, aber sie kapselt die Objektinstanziierung.

Wenn es keine "Fabrik" ist, was ist es dann?

---

bearbeiten

Einige Leute haben vorgeschlagen, dass dies tatsächlich das Builder-Muster ist.

Die Definition des Builder-Musters aus dofactory ist wie folgt:

Trennen Sie die Konstruktion eines komplexen Objekts von seiner Darstellung, so dass derselbe Konstruktionsprozess verschiedene Darstellungen erzeugen kann.

Auch das scheint ein wenig weit hergeholt zu sein. Was mich stört, sind die "unterschiedlichen Darstellungen". Mein Ziel ist es nicht, den Prozess der Erstellung einer Ansicht zu abstrahieren (nicht, dass das nicht ein lohnendes Ziel wäre). Ich versuche einfach, die Logik für die Erstellung einer bestimmten Ansicht an einem Ort zu platzieren, so dass ich bei einer Änderung der Bestandteile oder des Prozesses zur Erstellung dieser Ansicht nur diese eine Klasse ändern muss. Das Builder-Pattern scheint wirklich zu sagen: "Lass uns einen allgemeinen Prozess für die Erstellung von Views erstellen, dann kannst du denselben grundlegenden Prozess für jede View, die du erstellst, befolgen." Schön, aber das ist einfach nicht das, was ich hier tue.

---

Bearbeiten 2

Ich habe gerade ein interessantes Beispiel in einem Wikipedia-Artikel über Dependency Injection .

Unter "Manually Injected Dependency" enthält sie die folgende Klasse:

public class CarFactory {

    public static Car buildCar() {
        return new Car(new SimpleEngine());
    }

}

Dies ist fast genau die Verwendung, die ich habe (und, nein, ich habe den Wiki-Artikel nicht geschrieben :)).

Interessanterweise ist dies der Kommentar nach diesem Code:

Im obigen Code übernimmt das Werk die Verantwortung für den Zusammenbau des Fahrzeugs und baut den Motor in das Fahrzeug ein. Dadurch muss das Auto nicht mehr wissen, wie man einen Motor herstellt, allerdings muss die CarFactory nun über die Konstruktion des Motors Bescheid wissen. Man könnte eine EngineFactory erstellen, aber das schafft nur Abhängigkeiten zwischen den Fabriken. Das Problem bleibt also bestehen, wurde aber zumindest verschoben in Fabriken ou Bauherr Objekte. (meine Hervorhebung)

Das zeigt mir, dass ich zumindest nicht der Einzige bin, der daran gedacht hat, eine Klasse zu erstellen, die dabei hilft, Dinge in eine andere Klasse zu injizieren, und ich bin auch nicht der Einzige, der versucht hat, diese Klasse eine Fabrik zu nennen.

Answer 1

Es sieht für mich so aus, als ob das, was Sie da haben, eher eine Bauherr Muster als ein Fabrik Muster.

Answer 2

Das klingt für mich nicht viel anders als ein Konstruktor für eine Instanz von SetupView. Vielleicht wurde zu viel Code-Kontext aus Ihrem Beispiel ausgelassen, aber ich sehe nicht, warum das, was Sie da haben, nicht einfach als Konstruktor geschrieben werden könnte, und die Argumente als Args an den Konstruktor übergeben werden.

Rein nach den GoF-Mustern zu urteilen, verfehlt es meiner Meinung nach aus zwei Gründen das Ziel von Factory:

1. es gibt keine Familie von verwandten/abhängigen Objekten
2. die konkrete Klasse ist in der Tat spezifiziert

Was Builder betrifft, so fehlt es meiner Meinung nach an der Varianz der Produkte.

Wenn ich Design Patterns unterrichte, sage ich den Studenten, dass sie nicht nur die Absicht eines Musters betrachten sollen, wenn sie versuchen, die "beste Eignung" zu bestimmen, sondern vielmehr die Anwendbarkeit und die Struktur/Beteiligten berücksichtigen sollen. Die Absicht kann Ihnen helfen, Dinge auszuschließen, aber Anwendbarkeit und Struktur/Beteiligte sind das, was Ihnen helfen wird, sich zurechtzufinden.

Wenn Sie herausfinden können, welcher Teil Ihres Entwurfs die verschiedenen Rollen der Beteiligten in der (abstrakten) Fabrik oder im Builder erfüllt, dann haben Sie gute Argumente für die Verwendung dieser Nomenklatur geliefert.

Answer 3

GoF nennen es " Bauherr "

Answer 4

Ich denke, es ist eine "Fabrik". Wenn ich mir die Klassendeklaration ansehe, freue ich mich zu sehen, dass es sich um eine "Factory" handelt, und zwar um eine "Factory" von SetupView-Objekten. Ich weiß also, dass diese Factory mir konkrete und korrekt erstellte SetupView-Instanzen liefern wird.

Answer 5

Eine "Factory" ist alles, was die Instanziierung von neuen Objekten kapselt. Warum, oder was die Objekte sind, spielt keine Rolle. Die häufigste Verwendung ist die von Ihnen beschriebene, aber auch andere Zwecke, die nicht auf diese Beschreibung passen, können als "Factory" bezeichnet werden. Die grundlegende Idee (die wohl nur der pingeligste oder pingeligste Entwickler missverstehen würde) ist, dass das Ding neue Objekte für Sie instanziiert...