Factory Pattern, ein anderes Pattern oder gar kein Pattern?

8

Ich habe 2 Fälle, ob eine Methode als Factory Design Pattern betrachtet werden kann, dieses Beispiel ist in C #, altought, kann auf andere Programmiersprachen angewendet werden:

%Vor%

Die Methode StandardStudent() liefert immer ein neues Objekt desselben Typs, die SpecialityStudent(...) , kann neue Objekte aus verschiedenen Klassen mit derselben Oberklasse / demselben Basistyp zurückgeben. Beide Methoden sind absichtlich nicht virtuell.

Die Frage ist, sind beide Methoden "Factory Design Pattern"?

Ich vermute, dass SpecialityStudent(...) ist, aber StandardStudent() nicht. Wenn die zweite nicht ist, kann als ein anderes Designmuster betrachtet werden?

    
umlcat 30.06.2011, 23:45
quelle

4 Antworten

3

Ich denke nicht, dass es weder ein FactoryMethod noch AbstractFactory Muster verbieten dem Benutzer, einen Parameter zu verwenden, um einen Typ für die Creator-Methode anzugeben. Trotzdem solltest du mindestens zwei Dinge in deinem Design berücksichtigen:

  1. Factory-Methoden sind nützlich, um den Client nicht über den konkreten Typ des erstellten Objekts zu informieren. Aus meiner Sicht ist es nicht falsch, den Typ des zu erstellenden Objekts explizit anzugeben, aber achten Sie darauf, nicht zu viel Wissen über die Client-Klassen zu haben, um Objekte durch die Factory zu konstruieren.
  2. Beide Factory-Methoden geben ein Ninja-Objekt zurück, aber einige Ihrer erweiterten Ninjas deklarieren zusätzliche Methoden, die der Client nicht kennt. Wenn Ihr Client diese Methoden explizit verwenden muss, müssen Sie vielleicht etwas über Ihr Design nachdenken.
Heisenbug 01.07.2011 00:01
quelle
2

Ich denke, das sieht tatsächlich wie ein Anti-Pattern aus. Es gibt wirklich nichts, was einen Konsumenten dieses Codes daran hindern könnte, die speziellen Ninjas direkt zu instantiieren. Welchen Nutzen hat die Verwendung der Ninja Schule? Ich denke, der Sinn des Factory-Musters besteht darin, den Prozess der Instantiierung eines Objekts zu kapseln, so dass Sie die Details des Konsumenten verbergen können. Jedes Mal, wenn Sie eine Änderung an der "Erstellungs" -Logik vornehmen, wird niemandem der Code verletzt. Und es sieht einfach nach einer schlechten Idee aus, alle Typen in einem Enum zu haben. Ich habe keinen konkreten Grund, diesen Anspruch zu untermauern, außer "es fühlt sich falsch an".

Nachdem ich das Abstrakte-Fabrik-Muster durchgelesen habe, kann ich sehen, wie man es zu einer abstrakten Fabrik machen könnte, aber ich sehe keinen Nutzen angesichts der Semantik Ihrer Objekte. Ich denke, wenn Sie eine Ninja-Fabrik haben möchten, müssten Sie die einzelnen Konstruktoren geschützt oder intern machen, so dass sie nicht direkt vom Consumer-Code aufgerufen werden können.

    
Roly 01.07.2011 01:25
quelle
2

Beide Methoden können als Fabriken betrachtet werden. Aber die zweite ist ein wenig peinlich zu benutzen:

%Vor%

Sie haben bereits nach einem Flyer gefragt, also sollten Sie nicht casten müssen. Eine bessere Option könnte sein, die Enum zu eliminieren und nach dem genauen Ninja zu fragen, den du willst:

%Vor%

Eine weitere Sache, die du in deinem Design beachten solltest, ist: Was, wenn du einen unsichtbaren Ninja willst, der fliegen kann? Oder ein Katana Ninja, der auch Sterne wirft? Das wird deine Hierarchie durcheinander bringen und deine Überzeugung in Frage stellen in der Vererbung.

>     
Jordão 01.07.2011 11:40
quelle
0

Es ist fast eine Fabrikmethode. Ich würde etwas tun wie:

%Vor%     
Ray Tayek 01.07.2011 02:27
quelle