[Abstract Factory] Chiarimento sul design pattern

di il
7 risposte

[Abstract Factory] Chiarimento sul design pattern

Il diagramma UML del pattern si può vedere al link:
https://upload.wikimedia.org/wikipedia/commons/9/9d/Abstract_factory_UML.svg

Non capisco perchè il client debba implementare anche le interfacce AbstractProduct.
Se facciamo ad esempio:

AbstractFactory fac = new AbstractFactory();
Product mioprod = fac.createProductA();
mioprod.vegeta();
Tramite la factory, istanziamo il prodotto desiderato ed utilizziamo i suoi metodi, senza dover importare le interfacce.
Quale contratto deve rispettare il client con le interfacce AbstractProduct??

Buon weekend

7 Risposte

  • Re: [Abstract Factory] Chiarimento sul design pattern

    Più o meno questo:
    
    AbstractFactory fac = new AbstractFactory();
    AbstractProductA mioprod = fac.createProductA(choice); // 1 per ProductA1, 2 per ProductA2 etc
    mioprod.vegeta();
    
    Tramite una flag scegli il tipo di prodotto concreto desiderato e accedi a esso tramite l'interfaccia comune.
  • Re: [Abstract Factory] Chiarimento sul design pattern

    Ma nella OOP si può istanziare un oggetto (Product) e dichiararlo come tipo Interfaccia (AbstractProduct)?
  • Re: [Abstract Factory] Chiarimento sul design pattern

    Se Product discende da AbstractProduct, si: è la base della OOP.
    Quello che non si può fare è:
    
    AbstractFactory fac = new AbstractFactory();
    AbstractProductB mioprod = fac.createProductA(choice); // 1 per ProductA1, 2 per ProductA2 etc
    mioprod.vegeta();
    
    visto che ProductA non discende da AbstractProductB. La cosa fallisce.
  • Re: [Abstract Factory] Chiarimento sul design pattern

    Ok capito. Giustamente non si può fare perchè non c'è nessuna derivazione tra interfaccia B e A.
    Quindi ricapitolando se ho ben capito è lecito istanziare un oggetto dichiarandolo col tipo dell'interfaccia e utilizzarne tutti i metodi.

    Ancora non ho ben capito i vantaggi che ne traggo. Il client o front-end non importa direttamente le classi Productx, ma lo recupera dalla factory e tramite l'interfaccia può utilizzarlo.

    Ciao buona giornata
  • Re: [Abstract Factory] Chiarimento sul design pattern

    Il client o front-end non importa direttamente le classi Productx, ma lo recupera dalla factory e tramite l'interfaccia può utilizzarlo.
    Il vantaggio è proprio questo: il client non sa con che unità concreta ha a che fare, ma comunica attraverso un'interfaccia.
    Per cui se l'entità concreta dovesse cambiare, il codice client non dovrebbe essere riscritto come avverrebbe usando direttamente le entità concrete.
  • Re: [Abstract Factory] Chiarimento sul design pattern

    Ora è tutto chiaro. Ad esempio il client ha la possibilità di poter scegliere da un factory degli algoritmi di ordinamento per poi utilizzarli.
    Utilizzando un approccio OOP Abstract Factory potrebbe avere una situazione del genere:
    
    SortFactory sf = new SortFactory();
    SortAlgorithm sa = sf.create(mergeSort);
    sa.sort(array);
    
    In questo modo il client non conoscerà mai le implementazioni degli algoritmi di ordinamento e neppure se in futuro verranno modificati.

    Questo approccio OOP è utile anche per questioni di sicurezza??
  • Re: [Abstract Factory] Chiarimento sul design pattern

    Paolovox ha scritto:


    Ma nella OOP si può istanziare un oggetto (Product) e dichiararlo come tipo Interfaccia (AbstractProduct)?
    Certo, se Product implementa l'interfaccia AbstractProduct puoi tranquillamente fare in questo modo:
    AbstractProduct p = new Product();
    Credo che sia la base della programmazione ad oggetti e personalmente ritengo sia l'ideale dichiarare quando puoi elementi con tipo astratto, in modo che se in futuro cambierai l'implementazione dei metodi questo non toccherà l'interfaccia (ovviamente a patto di non modificarne nome, tipo di ritorno e parametri).
Devi accedere o registrarti per scrivere nel forum
7 risposte