Il modello di metodo di fabbrica è più flessibile di Simple Factory?

Question

Ho letto il libro Head First: Design Patterns, che ho trovato una buona introduzione ai modelli di progettazione. Tuttavia, ho una domanda su un reclamo che fanno nel Capitolo 4:

Essi definiscono il modello "Simple Factory" come segue (Java pseudocodice):

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; 
    } 
} 

La "Factory Method" è definito come segue (classe prodotto rimane la stessa e viene omesso):

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; 
    } 
} 

Poi gli autori vanno a sostenere che il pattern Factory Method è molto più flessibile di semplice fabbrica, perché mentre Simple Factory è "un solo colpo affare con il metodo factory stai creando un framework che le le sottoclassi decidono quale implementazione deve essere utilizzata "(pagina 135).

Ora non capisco perché sia ​​vero. Per come la vedo io, Simple Factory è, in un certo senso, leggermente flessibile rispetto al metodo Factory: è possibile creare una sottoclasse di Simple Factory (invece di sottoclasse lo Store) per ottenere sostanzialmente lo stesso comportamento. Se lo desideri, puoi perfino modificare il comportamento in fase di esecuzione! L'unico svantaggio di Simple Factory I potrebbe essere quando la creazione del prodotto dipende dalle variabili di stato della classe Store: è questo che gli autori chiamano flessibilità, o mi manca qualcosa?

Answer 1

Lei ha assolutamente ragione: ipotesi dell'autore è stata che non si ha intenzione di sottoclasse SimpleFactory, che non è un presupposto giusto fare (a meno che non SimpleFactory è contrassegnato final).

Poiché SimpleFactory non è definitivo, è possibile definirlo in una sottoclasse, ottenendo una maggiore flessibilità rispetto a un metodo di fabbrica, poiché SimpleFactory sostituisce l'ereditarietà con la composizione.

Un approccio ancora migliore sarebbe l'interfaccia SimpleFactory. Ciò consentirebbe di scegliere la composizione o l'ereditarietà in base alle tue preferenze, poiché un'interfaccia non ti limiterebbe nei casi in cui la tua classe Store ereditasse già una classe.

public interface SimpleFactory { 
    Product createProduct(); 
} 

Quindi è possibile utilizzare sia la composizione

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

o eredità/composizione combinata

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