Leggevo la presentazione Design Patterns di Peter Norvig. Dalla diapositiva 13:
Dynamic version needs only the Window classes.
The classes themselves serve as factories
This works because classes are first-class values We can say
make(c)
Significa che Java e C # non hanno bisogno del modello di progettazione in fabbrica poiché possono passare il tipo di classe come variabile.
Eh, ti manca la parte chiave dell'offerta: We can say make(c) .
Sebbene sia possibile aggirare i tipi in Java e C #, non è possibile (sempre, sempre) istanziare un oggetto da quel tipo che si sta passando intorno. I tipi non sono garantiti per essere classi (piuttosto che interfacce, enumerazioni, delegati). I tipi non sono garantiti come concreti (come si fa a "fare" una classe astratta?). Non è garantito che i tipi abbiano costruttori predefiniti.
Anche in questo caso, puoi sempre passare un delegato che si adatta alla firma giusta e ti costruirà il tipo corretto. Questo è un approccio perfettamente valido e un cambiamento positivo nell'uso eccessivo delle fabbriche in molti luoghi.
Il problema è che spesso le fabbriche non sono solo di qualche tipo variabile da far girare. Più spesso, la tua fabbrica ha bisogno di ottenere alcune informazioni per creare l'istanza giusta. E molto spesso, il luogo che specifica quale fabbrica utilizzare non conosce quell'informazione (altrimenti potrebbe semplicemente creare l'istanza giusta e usarla).
Leggi altre domande sui tag design-patterns