Perché il modello di progettazione del metodo di produzione è più utile di avere classi e chiamarle singolarmente?

Perché il tuo esempio non è abbastanza complicato. Per uno scenario così semplice, non ha nemmeno senso usare uno schema avanzato.

Ma se devi conoscere più del prodotto per costruire A, B o C, e non puoi avere accesso diretto a quella conoscenza, allora è utile. Quindi stai usando la fabbrica per fungere da centro di conoscenza per la produzione di oggetti necessari.

Forse quegli oggetti hanno bisogno di un riferimento a qualche oggetto X, che la fabbrica può fornire, ma il tuo codice nel luogo in cui vuoi costruire A, B o C non può o non deve avere accesso a X. Forse quando hai X tu crei A e B ma se hai il tipo Y allora crei C.

Considera anche che alcuni oggetti potrebbero necessitare di 20 dipendenze da creare; cosa poi? Andare a caccia di quelle dipendenze in un posto dove non dovrebbero essere accessibili potrebbe essere problematico.

Un modello di fabbrica è solitamente più complesso di quello. Una fabbrica decide su determinati criteri quale istanza da creare / restituire. Invece, quando non usi la fabbrica, il codice verrà utilizzato ripetutamente in diverse posizioni nel tuo codice.

Ad esempio, considera quanto segue: devi caricare i dati da un DB, ma hai un DB centrale per l'integrazione con molti dati e uno più piccolo in memoria su ogni dev-PC. Nel tuo codice chiedi a una fabbrica di ottenere un a handle di DB e la factory restituisce uno di quelli che dipendono ad es. un file di configurazione.

Il modello del metodo di fabbrica astrae il processo decisionale dalla classe chiamante. Questo ha diversi vantaggi:

Riutilizzo. Se voglio creare un'istanza in molti posti, non devo ripetere le mie condizioni, quindi quando vengo ad aggiungere una nuova classe, non corro il rischio di perdere uno.

Test delle unità. Posso scrivere 3 test per la fabbrica, per assicurarmi che restituisca i tipi corretti alle condizioni corrette, quindi la mia classe chiamante deve solo essere testata per vedere se chiama la fabbrica e poi i metodi richiesti sulla classe restituita. Non ha bisogno di sapere nulla sull'implementazione della fabbrica stessa o delle lezioni concrete.

Estensibilità. quando qualcuno decide di aggiungere una nuova classe D a questo stabilimento, nessuno dei codici chiamante, né i test di unità o l'implementazione, devono mai essere comunicati. Creiamo semplicemente una nuova classe D ed estendiamo il nostro metodo di produzione. Questa è la definizione stessa di Principi Open-Closed .

È anche possibile creare una nuova classe factory e renderle sostituibili a caldo, se la situazione lo richiede, ad esempio, se si desidera essere in grado di attivare e disattivare la classe D durante il test. Ho incontrato questa situazione solo una volta, ma è stato estremamente utile.

Come è stato detto, il modello di fabbrica non è sempre la strada da percorrere. Ma, ovunque tu veda l'istanza condizionale, dovresti dargli un momento di riflessione.

I principali vantaggi del modello Factory sono duplici:

1. I luoghi che richiedono un'implementazione del prodotto non hanno bisogno di sapere come costruirne uno. La fabbrica detiene tali informazioni.

   Vuoi sapere quali argomenti passare al costruttore particolare? O quali dipendenze devi iniettare? O come registrare la classe di implementazione con il database dopo che è stato completamente configurato? No? Lascia che la fabbrica si occupi di tutte queste cose.

2. I luoghi che richiedono un'implementazione del prodotto non hanno bisogno di sapere al momento della descrizione del modulo (ad esempio, al momento della compilazione) qual è il nome della classe di implementazione.

   Pertanto, a non deve avere nulla a che fare con A ; il "cosa costruire" può essere descritto in termini di proprietà non funzionali desiderate e non solo del nome. Questo è molto più flessibile.

Il rovescio della medaglia è che dove sai cosa fare e come farlo, ottieni più complessità quando usi una fabbrica. La soluzione è semplice: non usare una fabbrica quando non ha senso!

Mi piacerebbe pensare ai modelli di design in termini di classi come "persone" e schemi sono modi in cui le persone parlano tra loro.

Quindi, per me il modello di fabbrica è come un'agenzia di assunzione. Hai qualcuno che avrà bisogno di un numero variabile di lavoratori. Questa persona potrebbe conoscere alcune informazioni di cui hanno bisogno nelle persone che assumono, ma il gioco è fatto.

Quindi, quando hanno bisogno di un nuovo dipendente, chiamano l'agenzia assumente e dicono loro di cosa hanno bisogno. Ora, per assumere effettivamente qualcuno, devi conoscere un sacco di cose: benefici, verifica dell'idoneità, ecc. Ma la persona che assume non ha bisogno di sapere nulla di tutto questo - l'agenzia di assunzione si occupa di tutto ciò.

Allo stesso modo, l'utilizzo di una Factory consente al consumatore di creare nuovi oggetti senza dover conoscere i dettagli di come sono creati, o quali sono le loro dipendenze - devono solo fornire le informazioni che effettivamente desiderano.

Cortesia

Il pattern Factory è il modello di disegno più abusato e abusato.

Mi sono imbattuto in numerosi casi in cui una classe Factory è codificata quando un semplice costruttore sarebbe adeguato.

Non utilizzare una classe di fabbrica a meno che: -

• Dipende da una risorsa esterna ma non sai ancora quale sia esattamente.
• La costruzione è costosa e tu vuoi costruire una volta e riutilizzarla più volte.
• La costruzione di una nuova istanza dipende da quali istanze sono già state costruite (ad esempio, il tuo può avere solo cinque connessioni, oppure, dovresti usare un numero di identificazione della connessione più dell'ultimo numero usato).

Utilizza il metodo Factory quando si crea un'istanza di una sottoclasse e il codice client non dovrebbe essere responsabile della decisione su quale sottoclasse viene istanziata.

È utile perché impedisce di dover modificare il codice client quando è necessario modificare quale classe viene istanziata. La modifica del codice esistente è una cattiva pratica, in quanto tipicamente soggetta a errori.

Un esempio potrebbe avere sottoclassi, in cui ognuna ordina i dati in ordine crescente, ma in un modo diverso. Ogni modo è ottimale per un particolare tipo di dati. Ad esempio: dati parzialmente ordinati, dati che sono numeri ecc. Il codice cliente è una classe che gestisce solo la stampa di dati. Avere un codice che decide quale classe di ordinamento viene istanziata nella classe client lo renderebbe una classe complessa. In altre parole, avendo più di una responsabilità, in questo caso, decidere quale classe di classificazione è ottimale e stampare i dati. Inserendo il codice che decide quale classe di ordinamento viene istanziata in una classe Factory, separa i dubbi in modo che non sia necessario cambiare la classe client ogni volta che è necessario cambiare la sottoclasse che viene istanziata.

È un modo per coprirti il culo, se puoi prevedere le modifiche che fai da te in linea su come o quale classe viene istanziata, allora le classi di fabbrica hanno senso da usare. Ti aiuta a mantenere le tue lezioni focalizzate sulla loro unica responsabilità e di conseguenza ti assicurano meno probabilità di dover modificare il codice esistente che non è correlato.