Pattern Abstract Factory

Summary un design pattern che separa la responsabilità di istanziare una famiglia di oggetti dalla responsabilità di scegliere quale famiglia di oggetti istanziare.

Conosciuto anche come

Kit.

Intento

Il design pattern Abstract Factory definisce un'interfaccia ("AbstractFactory") tramite cui istanziare famiglie (famiglia 1, 2, ...) di oggetti (AbstractProductA, AbstractProductB, ), tra loro correlati o comunque dipendenti, senza indicare da quali classi concrete (ProductA1 piuttosto che ProductA2, ...). La scelta delle classi concrete è delegata ad una classe derivata (ConcreteFactory1 per la famiglia 1, ConcreteFactory2 per la famiglia 2, ...).

Note:

l'utilizzatore (Client) conosce solo l'interfaccia per creare le famiglie di prodotti (AbstractFactory) ma non la sua implementazione concreta (ConcreteFactory1 per la famiglia 1, ConcreteFactory2 per la famiglia 2, ...);
il meccanismo di scelta della famiglia di classi da istanziare (ConcreteFactory1 piuttosto che ConcreteFactory2) esula da questo design pattern.

La classe ConcreteFactory1 o ConcreteFactory2 che determina quale famiglia usare è stabilita a run-time quindi questo design pattern è classificato rispetto allo scopo (vedi ClassificazioneDeiDesignPattern#ClassiOggetti) come rivolto agli oggetti. Rispetto al fine questo questo design pattern è classificato tra i ClassificazioneDeiDesignPattern#Creazionali .

Diagramma UML

Un'altro diagramma equivalente qui .

Motivazione

Un framework può aver bisogno di supportare per una certa funzionalità diverse famiglie di classi in alternativa o può offrire la possibilità di configurare quale famiglia di classi utilizzare tra quelle disponibili (ConcreteFactory1 piuttosto che ConcreteFactory2) . Inoltre può aver bisogno di garantire che le classi di una famiglia (ProductA1, ProductB1, ... ) vengano usate in modo consistente con altre classi della stessa famiglia e non mischiate con classe equivalenti di un'altra famiglia.

Questa necessità è assolta dal design pattern Abstract Factory che isola le classi concrete di una famiglia (ProductA1, ProductB1, ProductC1, ... ) dal suo utilizzatore (Client) e rende facile aggiungere o sostituire una famiglia (aggiungendo o sostituendo ConcreteFactory1, ConcreteFactory2, ...)

Esempi d'uso in .NET

Il .NET 2.0 System.Data.Common.DbProviderFactory ha il ruolo di AbstractFactory con

System.Data.Odbc.OdbcFactory
System.Data.OleDb.OleDbFactory
System.Data.OracleClient.OracleClientFactory
System.Data.SqlClient.SqlClientFactory

che hanno il ruolo dei ConcreteFactoryX mentre

DbCommand
DbConnection
DbDataAdapter
DbParameter
...

hanno il ruolo degli AbstractProductX.

La scelta di quale ConcreteFactoryX istanziare invece è ottenuta applicando il PatternFactoryMethod ad opera di DbProviderFactories.

Note sulla implementazione in .NET

Del codice .NET di esempio è disponibile qui .

Relazione con altri design pattern

La classe ConcreteFactory è solitamente a singola istanza e quindi viene implementato solitamente col PatternSingleton oppure con una classe statica.

Le classi di AbstractFactory spesso sono implementate con metodi che sono PatternFactoryMethod oppure anche come PatternPrototype.

Vedi la mappa della RelazioneTraDesignPattern.

Approfondimenti

Quando per una famiglia di classi c'è la necessità di supportare una nuova classe, fare questa aggiunta è un'operazione onerosa perché richiede di modificare l'interfaccia AbstractFactory e tutte le classi che la richiamano o la ereditano. Una soluzione meno sicura ma più flessibile (vedi TipizzazioneForteODebole) consiste nel prevedere un metodo della AbstractFactory che accetta come parametro il nome dell'oggetto da creare e internamente lo istanzia in modo dinamico (ad esempio tramite Reflection).

Domande di approfondimento

il meccanismo di scelta della famiglia di classi da istanziare (ConcreteFactory1 piuttosto che ConcreteFactory2) con quale design pattern può essere implementato?

Link

VediAnche CatalogoDeiDesignPattern