wake-up-neo.net

Perché abbiamo bisogno del modello astratto di design di fabbrica?

La maggior parte della definizione dice:

Una fabbrica astratta fornisce un'interfaccia per creare famiglie di oggetti correlati senza specificare le loro classi concrete

Qual è l'uso del modello astratto di fabbrica in quanto possiamo realizzare il compito creando l'oggetto della stessa classe concreta. Perché abbiamo un metodo factory che crea oggetto di classe Concrete?

Forniscimi qualche esempio di vita reale in cui devo implementare il modello abstractFactory?

115
Amit
212
Mark Seemann

Un esempio di vita reale per l'utilizzo del modello Abstract Factory è fornire l'accesso ai dati a due diverse origini dati (ad esempio un database SQL e un file XML). Sono disponibili due diverse classi di accesso ai dati (un gateway per il datastore). Entrambi ereditano da una classe base che definisce i metodi comuni da implementare (ad esempio Carica, Salva, Elimina).

L'origine dati da utilizzare non deve modificare il modo in cui il codice client recupera la sua classe di accesso ai dati. La tua fabbrica astratta sa quale fonte di dati deve essere utilizzata e restituisce un'istanza appropriata su richiesta. La factory restituisce questa istanza come tipo di classe base.

22
Johannes Rudolph

Se ti capisco bene, la domanda è: perché abbiamo sia il metodo Factory sia i modelli factory astratti. È necessaria una fabbrica astratta quando diverse classi polimorfiche hanno una diversa procedura di istanziazione. E vuoi che un modulo crei istanze e le usi, senza conoscere alcun dettaglio sull'inizializzazione degli oggetti. Ad esempio, si desidera creare Java che eseguono alcuni calcoli. Ma alcuni di essi fanno parte dell'applicazione, mentre il bytecode di altri dovrebbe essere letto dal DB. D'altra parte, perché hai bisogno del metodo factory? D'accordo, quella factory astratta si sovrappone ma, in alcuni casi, è molto meno codice da scrivere, avere meno classi e interfacce rende il sistema più facile da comprendere.

5
David Gruzman

Qual è l'uso del modello astratto di fabbrica in quanto possiamo realizzare il compito creando l'oggetto della stessa classe concreta. Perché abbiamo un metodo factory che crea oggetti di classe Concrete?

In assenza di Abstract Factory , il Cliente deve conoscere i dettagli delle classi concrete. Questo accoppiamento stretto è stato rimosso con Abstract Factory .

Ora Metodo di fabbrica espone un contratto, che il cliente deve usare. Puoi aggiungere più prodotti alla tua fabbrica aggiungendo nuovi prodotti, che implementano l'interfaccia esposta con il Metodo di fabbrica.

Fare riferimento a queste domande SE correlate per una migliore comprensione:

Qual è la differenza di base tra i modelli Factory e Abstract Factory?

Intent:

Fornire un'interfaccia per la creazione di famiglie di oggetti correlati o dipendenti senza specificare le loro classi concrete.

Puoi capire Intento, Struttura, Elenco di controllo e Regole empiriche di Riassunto Modello di fabbrica da questo articolo creazione di sorgenti .

Elenco di controllo:

  1. Decidi se indipendenza dalla piattaforma e i servizi di creazione sono l'attuale fonte di dolore.
  2. Mappa una matrice di piattaforme contro prodotti.
  3. Definire a interfaccia di fabbrica che consiste in un metodo di fabbrica per prodotto.
  4. Definire a factory classe derivata per ogni piattaforma che incapsula tutti i riferimenti al nuovo operatore.
  5. client deve ritirare tutti i riferimenti a nuovi e utilizzare gli metodi di fabbrica per creare gli oggetti prodotto.
3
Ravindra babu

Le fabbriche astratte sono ottime per supportare più piattaforme mantenendo unificata la tua base di codice. Supponiamo di avere un grande programma Qt o GTK + o .NET/Mono che si desidera eseguire su Windows, Linux e OSX. Ma hai una funzione che è implementata in modo diverso su ogni piattaforma (forse tramite l'API kernel32 o una funzione POSIX).

public abstract class Feature
{
    public abstract int PlatformSpecificValue { get; }

    public static Feature PlatformFeature
    {
        get
        {
            string platform;
            // do platform detection here
            if (platform == "Win32")
                return new Win32Feature();
            if (platform == "POSIX")
                return new POSIXFeature();
        }
    }

    // platform overrides omitted
}

Con questa fabbrica astratta, la tua interfaccia utente non ha bisogno di sapere nulla sulla piattaforma attuale.

Feature feature = Feature.PlatformFeature;
Console.WriteLine(feature.PlatformSpecificValue);
2
piedar

Se si osservano i motivi di progettazione, quasi tutti possono essere resi ridondanti. Ma quale modello significa un approccio comunemente usato per una soluzione a un tipo simile di problemi. Un modello di progettazione fornisce un approccio o una soluzione a livello di progettazione a una serie di problemi di progettazione simili. L'utilizzo del modello di progettazione consente di risolvere il problema e quindi di consegnarlo più rapidamente.

1
Kangkan

è facile, immaginando di avere un codice che funzioni con l'astrazione, è necessario creare astrazioni e non classi concrete.

Dovresti sempre lavorare contro le astrazioni perché puoi modificare meglio il codice.

Questo è un buon esempio: http://en.wikipedia.org/wiki/Abstract_factory_pattern#C.2

1
Pablo Castilla

Penso che ci sia un posto per un modello di fabbrica astratto piuttosto che un semplice modello di fabbrica in luoghi in cui le tue istanze sono molto complicate, troppo complicate e brutte per una singola fabbrica e troppo complicate per la comprensione dell'interfaccia utente.

Supponiamo che questo sia un marchio TYPE_A, non una singola classe. Supponiamo che esista una famiglia di 100 tipi di classi simili di tipo A e che sia necessario creare un'istanza di un oggetto da esse. Immagina che siano necessarie informazioni sofisticate per ottenere l'oggetto corretto da una marca di molti tipi simili di oggetti e in questa entità oggetto devi sapere esattamente quali parametri mettere a punto e come metterli a punto.

Nella fabbrica speciale per questo marchio li faremo differenziare e ottenere l'oggetto esatto da istanziare e anche come istanziarlo. lo sapremo in base agli input della rete (diciamo di che colore è disponibile nel negozio online) e di altre applicazioni e servizi in esecuzione in background (parametri che l'IU non è a conoscenza di essi).

E forse domani avremo un'altra famiglia di diciamo type_B e type_C per istanziare. Quindi l'interfaccia utente avrà "if else" per sapere se l'utente desidera un "tipo_A", "tipo_B" o "tipo_C" - ma le classi delle fabbriche decideranno esattamente quale classe del tipo (dalla famiglia) costruire, e come ottimizzarlo: quali valori impostare sui suoi parametri o inviare al suo appaltatore. Tutto ciò, in base a molti parametri di cui l'interfaccia utente non è a conoscenza. Tutto questo sarà troppo per una singola classe di fabbrica.

1
Udi Reshef

Trovo il modello di Fabbrica astratta sopravvalutato.

Prima di tutto, non succede che spesso che tu abbia una serie di interrelati tipi che vuoi istanziare.

In secondo luogo, il livello di riferimento indiretto (astrazione) fornito da interfacce normalmente è sufficiente quando si lavora con l'iniezione di dipendenza.

L'esempio tipico di WindowsGui vs MacGui vs ... dove avresti un WindowsButton, MacButton, WindowsScrollBar, MacScrollbar, ecc. È spesso più facile da implementare definendo concrete Pulsanti, barre di scorrimento, ecc. Usando Visitor e/o modello di interprete per fornire un comportamento effettivo.

0
eljenso

Supponi di creare a.jar e che qualcun altro usi il tuo vaso e desideri usare un nuovo oggetto concreto nel tuo codice. Se non stai usando la factory astratta, allora deve modificare il tuo codice o sovrascriverlo. Ma se stai usando la fabbrica astratta, allora può fornire una fabbrica e passare al tuo codice e tutto va bene.

Versione raffinata: considera lo scenario qui sotto : Qualcun altro ha scritto un framework. Il framework utilizza una fabbrica astratta e alcune fabbriche concrete per creare molti oggetti in fase di esecuzione. In questo modo è possibile registrare facilmente la propria fabbrica nel framework esistente e creare i propri oggetti. Il framework è chiuso alle modifiche ed è ancora facile da estendere a causa del modello astratto di fabbrica.

0
Adrian Liu

Si tratta di dipendenze. Se non ti interessa l'accoppiamento stretto e le dipendenze, non hai bisogno di una fabbrica astratta. Ma sarà importante non appena si scrive un'applicazione che richiede manutenzione.

0
Daniel

Questo modello è particolarmente utile quando il client non sa esattamente quale tipo creare. Ad esempio, supponiamo che uno Showroom che vende esclusivamente telefoni cellulari ottenga una query per gli smartphone realizzati da Samsung. Qui non conosciamo il tipo esatto di oggetto da creare (supponendo che tutte le informazioni per un telefono siano racchiuse nella forma di un oggetto concreto). Ma sappiamo che stiamo cercando smartphone fabbricati da Samsung. Queste informazioni possono essere effettivamente utilizzate se il nostro progetto ha un'implementazione astratta in fabbrica.

Comprensione e implementazione del modello astratto di fabbrica in C #

0
Amir Shabani

Per rispondere direttamente alla tua domanda, puoi probabilmente scappare senza utilizzare un tale modello di progettazione.

Tuttavia, tieni presente che la maggior parte dei progetti nel mondo reale si evolve e desideri fornire un qualche tipo di estensibilità per rendere il tuo progetto a prova di futuro.

Dalla mia esperienza, il più delle volte, viene implementata una Fabbrica e man mano che il progetto cresce viene trasformato in modelli di progettazione più complessi come una Fabbrica astratta.

0
BlueTrin