mito modello di fabbrica

Question

Questo mi ha infastidito per un po ', e non ho nessun indizio se questo è un mito.

Sembra che uno schema di fabbrica possa alleviare il dolore di aggiungere una dipendenza per una classe.

Per esempio, in un libro, è qualcosa di simile

Si supponga di avere una classe denominata Order. Inizialmente non dipendeva da nulla. Quindi non ti sei preoccupato di usare una fabbrica per creare oggetti Ordine e hai semplicemente usato semplicemente nuovo per creare un'istanza degli oggetti. Tuttavia, ora è necessario che l'Ordine sia creato in associazione con un Cliente. Ci sono milioni di posti che devi cambiare per aggiungere questo parametro extra. Se solo tu avessi definito una fabbrica per la classe dell'Ordine, avresti incontrato il nuovo requisito senza lo stesso dolore.

In che modo non è la stessa pena aggiungere un parametro aggiuntivo al costruttore? Voglio dire che avresti ancora bisogno di fornire un argomento in più per la fabbrica e che è anche usato da milioni di posti, giusto?

Answer 1

Se l'utente è noto solo al momento, l'ordine viene creato, è possibile implementare una funzione getCurrentUser() che viene chiamata dalla fabbrica.
Se ciò è possibile, la funzione di fabbrica ovviamente vince. In caso contrario, non vi è alcun guadagno.

Se, in passato, non sapevi che ci sarebbe stato bisogno di un cliente, probabilmente non sapresti nemmeno se sia possibile implementare una funzione getCurrentUser(). Le possibilità di pagamento del metodo di produzione potrebbero non essere molto buone ma non sempre uguali a 0.

Answer 2

Dite la fabbrica della nuova dipendenza, e lasciare inserirlo per voi. La chiamata di metodo alla fabbrica dovrebbe rimanere invariata.

Answer 3

No, perché la dipendenza per la fabbrica deve essere iniettata tramite il costruttore delle fabbriche, e si sta costruendo la fabbrica in un unico posto, ma passandolo come dipendenza a tutto ciò che ha bisogno di creare un ordine. Le cose che stanno ricevendo ordini dalla fabbrica stanno ancora chiamando lo stesso metodo, CreateOrder() o qualsiasi altra cosa, e così il codice è invariato.

Le dipendenze dovrebbero essere collegati in un unico luogo, il composition root, e che dovrebbe essere l'unico luogo che ha bisogno di cambiare, di aggiungere la nuova dipendenza alla fabbrica

Answer 4

The factory pattern può alleviare il dolore di aggiunta una dipendenza, perché una fabbrica può contenere stato e, infatti, può incapsulare più dipendenze (ad esempio, invece di fornire tre dipendenze, tutti bisogno di invocare il costruttore di qualche oggetto, è ora forniscono solo un oggetto di fabbrica di singolo, dove la fabbrica contiene quelli tre oggetti che devono essere forniti al costruttore).

per fare un esempio, confrontare:

void DoIt(const DependencyA& a, const DependencyB& b) { 
    // NOTE: "x" is a contrived additional variable that we add here to 
    // justify why we didn't just pass DependencyC directly. 
    int x = ComputeX(); 
    std::unique_ptr<DependencyC> dependency_c(new DependencyC(a, b, x)); 
    dependency_c->DoStuff(); 
} 

E:

void DoIt(const DependencyCFactory& factory) { 
    int x = ComputeX(); 
    std::unique_ptr<DependencyC> dependency_c(factory->Create(x)); 
    dependency_c->DoStuff(); 
} 

Nota che la seconda versione richiesto un minor numero di dipendenze al metodo "DoIt". Ciò non significa che tali dipendenze non siano necessarie nell'intero programma (infatti, il programma utilizza ancora DependencyA e DependencyB nell'implementazione della fabbrica). Tuttavia, strutturandolo in questo modo, tale dipendenza può essere isolata solo dal codice di fabbrica, che semplifica l'altro codice, facilita la modifica delle dipendenze di DependencyC (ora solo la fabbrica, di per sé, deve essere aggiornata, non ogni luogo che crea un'istanza di DependencyC) e può anche avere alcuni vantaggi in termini di sicurezza (ad esempio se DependencyA e DependencyB sono sensibili come le password del database o le chiavi API, limitando il loro utilizzo in fabbrica riduce le possibilità di maltrattamento, rispetto ai casi in cui si passa in giro ovunque tu abbia bisogno di usare il databse o l'API, per esempio).

Nell'esempio riportato nel libro, il motivo per cui avere una fabbrica per il Order avrebbe aiutato è che avrebbe ridotto il numero di posti in cui il costruttore viene utilizzato direttamente; solo l'unico posto che ha creato la fabbrica avrebbe dovuto essere modificato per memorizzare Customer come un campo aggiuntivo della fabbrica; nessuno degli altri usi della fabbrica avrebbe bisogno di essere modificato. In confronto, senza l'uso della fabbrica, gli usi diretti del costruttore abbondano e ciascuno di essi deve essere aggiornato per ottenere in qualche modo l'accesso all'oggetto Customer.

Answer 5

Il vero vantaggio dell'utilizzo di una fabbrica è che si tratta di una facciata che nasconde proprio come si procede alla creazione di un oggetto che soddisfa il ruolo dell'ordine. Per essere più precisi, la Factory sa che stai facendo davvero un FooBarOrder, e nient'altro deve essere cambiato per passare dal creare sempre un FooBarOrder a volte creando un BarFooOrder. (Se Java consente di intercettare lo new e di creare una sottoclasse, non ci sarebbe bisogno di fabbriche, ma non abbastanza - ragionevolmente, per essere onesti - quindi bisogna averli. Sistemi di oggetti che consentono la sottoclasse della classe di classi sono più flessibili in questo senso.)