[Abstract Factory] Chiarimento sul design pattern

Paolovox

il 06 feb 2016, 23:02

7 risposte

Paolovox

Utente Attivo

Iscritto da: giu, 2014

Messaggi:: 344

[Abstract Factory] Chiarimento sul design pattern

06 feb 2016, 23:49

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

shodan
Molto attivo
Iscritto da
apr, 2010
Messaggi:
744
Re: [Abstract Factory] Chiarimento sul design pattern
08 feb 2016, 16:02
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.
Paolovox
Utente Attivo
Iscritto da
giu, 2014
Messaggi:
344
Re: [Abstract Factory] Chiarimento sul design pattern
08 feb 2016, 16:21
Ma nella OOP si può istanziare un oggetto (Product) e dichiararlo come tipo Interfaccia (AbstractProduct)?
shodan
Molto attivo
Iscritto da
apr, 2010
Messaggi:
744
Re: [Abstract Factory] Chiarimento sul design pattern
08 feb 2016, 16:52
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.
Paolovox
Utente Attivo
Iscritto da
giu, 2014
Messaggi:
344
Re: [Abstract Factory] Chiarimento sul design pattern
09 feb 2016, 09:40
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
shodan
Molto attivo
Iscritto da
apr, 2010
Messaggi:
744
Re: [Abstract Factory] Chiarimento sul design pattern
09 feb 2016, 14:08
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.
Paolovox
Utente Attivo
Iscritto da
giu, 2014
Messaggi:
344
Re: [Abstract Factory] Chiarimento sul design pattern
11 feb 2016, 20:52
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??
M
macchina20
Pochi posts
Iscritto da
gen, 2013
Messaggi:
10
Re: [Abstract Factory] Chiarimento sul design pattern
16 feb 2016, 15:14
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