Quali sono gli usi pratici del modello di metodo di fabbrica?

Question

Sono abbastanza nuovo in Design Pattern. Mi sono imbattuto in Factory Design Pattern. Ho capito che delega l'istanziazione alle sottoclassi. Ma non ho avuto l'effettiva applicazione del modello. In quali scenari è possibile utilizzare questo modello con buoni risultati. Ho sentito parlare di abusi di pattern e non vorrei indulgere in questo. Qualcuno può citare un esempio del mondo reale in cui è comunemente usato.

Answer 1

L'ho usato per i plug-in per le applicazioni ... in questo modo è possibile fare in modo che l'applicazione principale chiami il factory di classe per istanziare il plug-in specifico implementando l'interfaccia che hai sviluppato nella tua app principale. In questo modo, è possibile codificare la parte principale dell'applicazione senza dover necessariamente sapere cosa sarà collegato.

Answer 2

L'ho appena utilizzato in un'applicazione di pianificazione, in cui le attività da pianificare sono in assembly separati e lo scheduler non sa nulla delle attività ... Ottiene il nome dell'assembly in cui è definita l'attività da un'origine esterna, quindi carica l'assembly in modo dinamico, crea un'istanza di una classe nell'assieme utilizzando un'interfaccia ben definita. Un metodo factory nello scheduler, che prende il nome assembly come parametro di input, restituisce un'istanza della classe nell'assembly caricato ...

.. ma ci sono così tanti usi e modi per usare .. questo modello.

Answer 3

Il modello di fabbrica è molto utile per mappare una capacità in un gestore appropriato.

Answer 4

Supponiamo di disporre di una coda che contiene oggetti di tipo task.

Ora è possibile creare sottoclasse task per vari motivi. Se si caricano le attività da una fonte come un database, è possibile utilizzare una fabbrica per determinare il tipo di attività da caricare.

Ad esempio:

private IEnumerable<Task> GetTasks(DataTable Table){ 

    Task NewTask; 

    foreach(DataRow Row in Table){ 
    switch(tasktype){ 
     case tasktypes.TaskTypeA: 
     NewTask = NewTaskA(...); 
     break; 

     case TaskTypes.TaskTypeB: 
     NewTask = NewTaskB(...); 
     break; 
     ... 
    } 

    yield return NewTask; 
    } 
} 

In seguito si potrebbe quindi chiamare metodi virtuali sulle attività in coda, come "consumare" o "processo", per esempio.

Il vantaggio dell'approccio factory (in questo caso) è che è necessario solo attivare il tipo di attività una volta (quando l'attività viene creata) e lasciare che il polimorfismo gestisca la maggior parte di tutto il resto.

Answer 5

La necessità di utilizzare effettivamente i dettagli di implementazione più dolorosi descritti dal modello sono stati rimossi grazie al modo in cui C# funziona, ma la mia funzionalità DAL SQL passa attorno alle fabbriche oggetto (e ai comandi SQL) alle funzioni di utilità che utilizzano le fabbriche per generare oggetti. Se non stavo usando C#, suppongo che potrei invece aver usato una classe factory esplicita che ha generato gli oggetti.

Answer 6

vale a dire in uno dei 2 casi:

1. la classe non si conosce il tipo di oggetto che vuole creare, ma semplicemente vuole un oggetto che 'il lavoro'. EMF salta in mente mentre utilizza fortemente questo schema.
2. si desidera che le sottoclassi della classe determinino il tipo di oggetto da utilizzare. cioè stai scrivendo la tua classe genitore senza sapere quale prodotto concreto verrà creato, questa sarà la responsabilità del creatore concreto.