Metodo di fabbrica rispetto al modello di progettazione metodo di fabbrica

2

Al momento sto studiando modelli di design tratti dal libro (che, sebbene non abbia provato nient'altro, trovo eccellenti) Head First Design Patterns.

Sono confuso su due concetti: il metodo di fabbrica e il modello di progettazione del metodo di fabbrica .

Stavo cercando di capire cosa significa ognuno, e sono arrivato a una conclusione. Mi piacerebbe sapere se le mie definizioni sono esatte.

Il metodo Factory è un metodo che ha lo scopo di fare una cosa: creare un oggetto di un supertipo specifico e restituirlo. Può o non può prendere un parametro e può o meno decidere di usare le istruzioni if quale tipo di oggetto concreto creare.

Ad esempio, questo è un metodo factory:

public Hat createHat(String hatColor){

    Hat hat;

    if (hatColor.equals("red")) hat = new RedHat();
    else if (hatColor.equals("blue")) hat = new BlueHat();
    else if (hatColor.equals("green")) hat = new GreenHat();
    else hat = new DefaultHat();

    return hat;

}

Il metodo di fabbrica Modello di progettazione è denominato il metodo di fabbrica.

Questo modello fornisce un modo specifico per incapsulare la creazione dell'oggetto dal client.

Funziona in questo modo: il pattern è un sistema di due classi, Creator e ConcreteCreator . Il Creatore è una classe abstract e ConcreteCreator è una sottoclasse di tale classe.

Il lavoro di ConcreteCreator : crea un oggetto e restituiscilo utilizzando un metodo factory . Deve solo contenere questo metodo.

Il lavoro del Creatore - manipola e usa l'oggetto ricevuto dalla sua sottoclasse, il ConcreteCreator, e di solito lo restituisce al client.

È fatto così:

Il Creatore contiene un metodo abstract , la sua firma è qualcosa come SupertypeObject createObject() . Ogni volta che ha bisogno di un oggetto di tipo SupertypeObject , chiama createObject() .

Il fatto è che createObject() è come ho detto abstract . È compito del ConcreteCreator implementare questo metodo.

In questo modo, l'implementazione di createObject() è nascosta dal Creatore. Non sa cosa ottiene l'oggetto concreto , ma sa per certo che è di tipo SypertypeObject .

In questo modo, un client può usare l'oggetto Creator per creare oggetti di qualche supertipo, ma gli oggetti concreti creati dipenderanno dalla sottoclasse. Così dichiarando ShoeFactory factory = new CaliforniaStyleShoesFactory() , la factory produrrà scarpe in stile california, mentre ShoeFactory factory = new NYStyleShoesFactory() farà sì che factory generi scarpe stile NY. Poiché l'implementazione della creazione degli oggetti concreti dipende da ConcreteCreator.

Codice da dimostrare:

Class Client(){

    public static void main(String[] args){

        ShoeFactory factory;
        Shoe shoe;

        factory = new NYStyleShoeFactory();
        shoe = factory.makeShoe();
        System.out.println(shoe.getDescription()); // "A NY style shoe".

        // ShoeFactory's makeShoe() invokes createShoe() in the subclass, receives a Shoe
        // (doesn't know the concrete type of the Shoe. Depends on the subclass) and
        // does manipulations on it.
        // Returns the Shoe to the client.

        factory = new CaliforniaStyleShoeFactory():
        shoe = factory.makeShoe();
        System.out.println(shoe.getDescription()); // "A California style shoe".

}

}

La mia comprensione dei due concetti è accurata? Grazie

    
posta Aviv Cohn 21.03.2014 - 12:08
fonte

2 risposte

2

Sì, hai ragione.

Il pattern è chiamato così perché descrive una soluzione conosciuta e ben accettata usando un metodo factory.

Lo schema avrebbe potuto essere denominato "XXXX". Non importa.

Riguardo al commento di @ pdr su ciò che descrivi essere veramente una "fabbrica astratta", le seguenti immagini chiariscono la differenza, il metodo di fabbrica è esattamente ciò che descrivi:

Le immagini sono tratte da questo PDF tratto da questo sito . È stato realizzato da un ingegnere del software con il nome di Jason McDonald .

    
risposta data 21.03.2014 - 17:01
fonte
0

Hai detto qualcosa in un commento che porta evidenziazione e spiegazione.

How can one method be a pattern?

Mentre la maggior parte dei modelli di progettazione sono modelli di classi o oggetti e in che modo tutti si relazionano tra loro, questo è vero solo per i modelli di progettazione orientati agli oggetti . Il tema degli schemi di progettazione ha un'applicabilità ben oltre, e ci sono alcuni schemi di progettazione, come factory o interface , che si applicano molto bene alle implementazioni usando un singolo metodo o funzione.

Ad esempio, possiamo usare entrambi in un semplice programma JavaScript funzionale. Diciamo che abbiamo qualcosa di simile a ciò che segue, per chiamare un oggetto ActiveX che la nostra azienda utilizza su una Intranet.

var oNeat = new ActiveXObject("OurCompany.NeatThing");
oNeat.DoStuff();

Sembra semplice, tranne che possiamo avvolgere entrambe le righe sopra in una coppia di rispettive pattens.

function GetNeatThing() {
  return new ActiveXObject("OurCompany.NeatThing");
}

function DoStuff(onWhat) {
  if(onWhat && onWhat.DoStuff) {
    onWhat.DoStuff();
  }
}

e quindi la nostra chiamata diventa semplicemente:

var oNeat = GetNeatThing();
DoStuff(oNeat);

Sebbene ciò non ci porti molto da solo, otteniamo una modularità significativamente migliore. Se spostiamo le funzioni GetNeatThing e DoStuff nel loro file js e li usiamo al posto dei riferimenti codificati, finiamo con tutti i vantaggi di avere una fabbrica e un'interfaccia.

(Specificamente, potremmo cambiare il progID del nostro NeatThing, o anche spostarlo da ActiveX a qualcosa di simile a un server Web. E potremmo persino cambiare il modo in cui funziona, rinominando l'atroce metodo "DoStuff" in qualcosa più descrittivo, pur non infrangendo il codice esistente.)

    
risposta data 21.03.2014 - 17:32
fonte

Leggi altre domande sui tag