Stefano Russo » 14.Design pattern creazionali. Esempi

Design pattern creazionali

I design pattern creazionali astraggono il processo di istanziazione.

Consentono di rendere il sistema indipendente da come gli oggetti sono creati, rappresentati e delle relazioni di composizione tra essi.

Se basati su classi, utilizzano l’ereditarietà per modificare la classe istanziata.

Se basati su oggetti, delegano l’istanziazione ad altri oggetti.

Incapsulano la conoscenza relativa alle classi concrete utilizzate dal sistema.

Nascondono come le istanze delle classi sono create e assemblate.

Design pattern creazionali

Alcuni creational patterns catalogati:

• Abstract Factory: un oggetto che serve a creare istanze di altri oggetti;
• Factory Method: un oggetto che serve a creare istanze di diverse classi derivate;
• Prototype: istanza completa di un oggetto che serve per essere clonato o copiato;
• Singleton: un oggetto che restituisce una sola istanza di se stesso.

Pattern creazionali

Esempi di creational patterns illustrati in dettaglio nel seguito:

• Abstract Factory;
• Factory Method;
• Singleton.

Abstract Factory – Motivazione

Si consideri un’applicazione la cui interfaccia grafica fornisce all’utilizzatore aspetti diversi a cui sono associati comportamenti diversi dei widget (scroll bar, finestre, bottoni).

Affinchè l’applicazione possa fornire diversi aspetti e comportamenti (look-and-feel) occorre che i widget non siano codificati per il particolare aspetto: istanziare delle classi specifiche dei widget per ogni aspetto complicherebbe il successivo cambio di aspetto.

Abstract Factory – Motivazione

WidgetFactory è una classe astrattale cui sottoclassi implementano le operazioni per creare il widget appropriato per il particolare aspetto.

I client creano i widget utilizzando solo l’interfaccia WidgetFactory e senza avere alcuna conoscenza delle classi che implementano i widget per un particolare aspetto.

Abstract Factory – Motivazione

Abstract Factory – Applicabilità

Usiamo un Abstract Factory quando:

• un sistema deve essere indipendente da come i suoi prodotti sono creati, composti e rappresentati;
• un sistema deve essere configurato con uno di tante famiglie di prodotti;
• si vuole fornire una libreria di classi di prodotti e si vuole rivelare solo la loro interfaccia, non la loro implementazione.

Abstract Factory – Struttura

Abstract Factory – Partecipanti

AbstractFactory -Dichiara un’interfaccia per operazioni che creano prodotti astratti.
ConcreteFactory - Implementa le operazioni per creare oggetti prodotto concreti: solitamente istanziata come un singleton.
AbstractProduct - Dichiara un’interfaccia per un tipo di oggetto prodotto.
ConcreteProduct - Definisce un oggetto prodotto che deve essere creato con la corrispondente ConcreteFactory.

Abstract Factory – Conseguenze

Vantaggi

• Isola le classi concrete: tutte le manipolazioni client-side sono fatte tramite interfacce astratte.
• Semplifica lo scambio di famiglie di prodotti: basta cambiare la ConcreteFactory.
• Favorisce la consistenza tra i prodotti: semplifica la cooperazione tra oggetti della stessa famiglia.

Svantaggi

• Supportare nuovi tipi di prodotto è difficile.
• Occorre riscrivere la AbstractFactory e tutte le sottoclassi.

Abstract Factory – Implementazione

Solitamente un’applicazione richiede un’unica istanza di ConcreteFactory per cui viene solitamente implementata come un Singleton.

AbstractFactory è solo un’interfaccia per la creazione dei prodotti che devono poi essere creati da ConcreteFactory; ciò può essere realizzato attraverso un factory method.

È possibile utilizzare dei metodi parametrizzati per specificare il particolare oggetto da creare, come per i factory method.

Factory Method – Scopo

Definisce un’interfaccia per creare un oggetto, ma lascia decidere alle sottoclassi quale classe istanziare.

Lascia che una classe deleghi l’istanziazione alle sottoclassi.

Factory Method – Motivazione

Si consideri un framework per applicazioni che lavorano su documenti di diverso tipo.

Abbiamo due astrazioni: Application e Document.

La classe Application è responsabile della gestione di Document.

Ma Application sa quando creare un documento, ma non il tipo di Document da creare.

A sua volta, il framework deve istanziare classi, ma vede solo classi astratte che non può istanziare.

Factory Method – Applicabilità

Il pattern Factory Method è utilizzato quando:

• una classe non conosce a priori il tipo di oggetti da creare;
• una classe vuole che siano le sue sottoclassi a specificare gli oggetti da creare;
• le classi delegano le responsabilità a delle sottoclassi “di aiuto”.

Factory Method – Struttura

Factory Method – Partecipanti

Product (Document)

• Definisce l’interfaccia degli oggetti che il Factory Method crea.

ConcreteProduct (MyDocument)

• Implementa l’interfaccia Product.

Creator (Application)

• Dichiara il factory method, che restituisce un oggetto di tipo Product.
• Potrebbe anche definire una implementazione di default del Factory Method che restituisca un oggetto di default ConcretProduct;

ConcreteCreator (MyApplication)

• Effettua l’override di factory method per restituire un’istanza di un ConcreteProduct.

Factory Method – Conseguenze

Vantaggi

La creazione di oggetti in una classe con un factory method è più flessibile della creazione diretta di un oggetto, per cui le sottoclassi sono agevolate nella creazione di versioni estese degli oggetti;

Connette gerarchie di classi parallele: classi che delegano responsabilità ad altre classi.

Factory Method – Conseguenze

Svantaggi potenziali

I clients devono derivare la classe Creator solo per creare un particolare oggetto ConcreteProduct.

Factory Method – Implementazione

Creator è una classe astratta che dichiara un Factory Method astratto e ConcreteCreator lo implementa.

Creator definisce una implementazione di default per Factory Method.

Factory Methods parametrizzati:

Singleton – Scopo

Assicura che una classe abbia una sola istanza e fornisce un punto globale di accesso ad essa.

Singleton – Motivazione

In alcuni casi è importante che una classe abbia esattamente un’istanza.

Una variabile esterna fa sì che l’oggetto sia accessibile, ma non impedisce che siano istanziati più oggetti.

La classe stessa è responsabile di avere traccia della sua unica istanza e fornire un modo per accedere a tale istanza.

Singleton – Applicabilità

Il Singleton va usato quando:

• deve esserci esattamente una istanza di una classe e deve essere accessibile ai clients da un punto di accesso globale;
• l’unica istanza deve essere estensibile con subclassing e i clients devono essere capaci di usare una istanza estesa senza modificare il loro codice.

Singleton – Struttura

Singleton – Partecipanti

Singleton

• Definisce un’operazione Istance() che consente ai clients di accedere la sua unica istanza;
• Instance() è un metodo di classe (i.e. static);
•  può essere responsabile di creare la sua propria unica istanza.

Singleton – Conseguenze

Accesso controllato all’unica istanza.

Un sostituto elegante per variabili esterne (consente di evitare l’”inquinamento” del name space con numerose variabili esterne).

Il Singleton può essere esteso per consentire un numero variaible di istanze.

Singleton – Implementazione

Una tecnica per garantire che vi sia una sola istanza della classe consiste nel nascondere l’operazione di creazione in una operazione di classe (funzione static) e rendendo il costruttore protected.

Singleton – Implementazione

Nel caso di sottoclassi, occorre fare in modo che l’unica istanza della classe derivata sia accessibile in modo che i client possano utilizzarla.

Una possibile soluzione nel determinare il Singleton che si intende utilizzare nell’operazione Istance():

Singleton* Singleton::Instance() {
if(condition)
_instance= new particularInstance;
}