Ist das Factory Method Pattern flexibler als Simple Factory?

Question

Ich habe das Buch Head First: Design Patterns gelesen, das ich für eine gute Einführung in Designmuster halte. Allerdings habe ich eine Frage zu einem Anspruch bekam sie in Kapitel machen 4:

Sie definieren den „Simple Factory“ Muster wie folgt (Java Pseudo-Code):

public abstract class Product 
{ 
// Product characteristics 
// Concrete Products should subclass this  
} 
public class SimpleFactory { 
    public Product createProduct(){ 
     // Return an instance of some subclass of Product 
    } 
} 
public class Store { 
    SimpleFactory factory; 
    public Product orderProduct(){ 
     Product product = factory.createProduct(); 
     // Do some manipulation on product 
     return product; 
    } 
} 

Die „Factory Method“ ist definiert wie folgt (Klasse Produkt bleibt gleich und wird weggelassen):

public abstract class Store { 
//Concrete Stores must subclass this and override createProduct() 
    public abstract Product createProduct(); 

    public Product orderProduct(){ 
     Product product = createProduct(); 
     // Do some manipulation on product 
     return product; 
    } 
} 

Dann auf die Autoren gehen zu behaupten, dass die Factory Method Pattern als einfache Fabrik viel flexibler ist, weil während einfache Fabrik „ein One-Shot-Deal Mit Factory-Methode erstellen Sie ein Framework, das le ts entscheiden die Unterklassen, welche Implementierung verwendet werden soll "(Seite 135).

Jetzt verstehe ich nicht, warum das wahr ist. Die Art, wie ich es sehe, Simple Factory ist in gewisser Hinsicht leicht mehr flexibel als Factory-Methode: Sie können die einfache Factory (anstelle der Unterklasse des Speichers) Unterklasse, um im Wesentlichen das gleiche Verhalten zu erhalten. Sie können sogar das Verhalten zur Laufzeit ändern, wenn Sie möchten! Der einzige Nachteil von Simple Factory, den ich mir vorstellen kann, ist, wenn die Produkterstellung von Zustandsvariablen der Store-Klasse abhängt: Ist das das, was die Autoren Flexibilität nennen, oder fehle ich etwas?

Answer 1

Sie haben völlig Recht: Autors zugrunde liegende Annahme ist, dass Sie nicht SimpleFactory Unterklasse werden, die keine faire Annahme zu machen (es sei denn SimpleFactory markiert final).

Da SimpleFactory nicht endgültig ist, können Sie sie definitiv subklassifizieren, wodurch mehr Flexibilität als bei einer Factory-Methode erzielt wird, da SimpleFactory Vererbung durch Komposition ersetzt.

Ein noch besserer Ansatz wäre SimpleFactory eine Schnittstelle zu machen. Auf diese Weise können Sie Komposition oder Vererbung nach Ihren Wünschen auswählen, da eine Schnittstelle Sie in Fällen nicht einschränkt, in denen Ihre Store-Klasse bereits eine Klasse erbt.

public interface SimpleFactory { 
    Product createProduct(); 
} 

Dann können Sie entweder Zusammensetzung

public class FactoryImpl implements SimpleFactory { 
    public Product createProduct(){ 
     // Return an instance of some subclass of Product 
    } 
} 
public class StoreComposition { 
    SimpleFactory factory = new FactoryImpl(); 
} 

oder Erbschaft/Zusammensetzung Combo

public class StoreInheritance implements SimpleFactory { 
    SimpleFactory factory = this; 
    public Product createProduct(){ 
     // Return an instance of some subclass of Product 
    } 
}