DESIGN PATTERN

DESIGN PATTERN
Un design pattern pu essere definito "una soluzione progettuale generale a un problema ricorrente". Esso non una libreria o un componente di software riusabile, quanto una descrizione o un modello da applicare per risolvere un problema che pu presentarsi in diverse situazioni durante la progettazione e lo sviluppo del software.

DESIGN PATTERN
La nascita del "movimento" dei pattern in informatica si deve al celebre libro Design Patterns: Elementi per il riuso di software ad oggetti di Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides (1995). I quattro furono chiamati:

GoF : Gang of Four

Classifica dei design pattern

23 patterns basati sullesperienza degli autori a quel tempo. Pi di 250 utilizzati oggi nel campo dellobject oriented. Per organizzarli, il Gof gli organizza in 3 categorie di design pattern.

Creazionale Strutturale Comportamentale

I design pattern creazionali

Creazionale
I pattern creazionali nascondono i costruttori delle classi e mettono dei metodi al loro posto creando un'interfaccia. In questo modo si possono utilizzare oggetti senza sapere come sono implementati. Tipicamente, I dettagli della classe che verr istanziata cos, come e quando creata, -- sono incapsulati da una superclass abstract nascosti alla classe cliente, lacuale conosce solo la classe abstract o linterfaccia di implementazione. Il tipo specifico della classe concrete sconosciuto dalla classe cliente.

I design pattern strutturali

Strutturale
I pattern strutturali consentono di riutilizzare degli oggetti esistenti fornendo agli utilizzatori un'interfaccia pi adatta alle loro esigenze. Questi patterns riguardano come le classe ereditano gli uni gli altri o come sono composte da altre classi.

I design pattern comportamentali

Comportamentale
I pattern comportamentali forniscono soluzione alle pi comuni tipologie di interazione tra gli oggetti..

DESIGN PATTERN
Fissati alla compilazione

DESIGN PATTERN

Struttura di un design pattern

Un design pattern costituito da: il nome, una o due parole che siano il pi possibile rappresentative del patern stesso; il problema, ovvero la descrizione della situazione alla quale si pu applicare il patern. Pu comprendere la descrizione di classi o di problemi di progetazione specifci, come anche una lista di condizioni perch sia necessario l'utilizzo del patern; la soluzione, che descrive gli elementi costitutivi del progeto con le relazioni e relative implicazioni, senza per addentrarsi in una specifca implementazione. Il conceto di presentare un problema astrato e la relativa confgurazione di elementi adata a risolverlo; le conseguenze, i risultati e i vincoli che derivano dall'applicazione del patern. Sono fondamentali in quanto possono essere l'ago della bilancia nella scelta dei patern: le conseguenze comprendono considerazioni di tempo e di spazio, possono descrivere implicazioni del patern con alcuni linguaggi di programmazione e l'impato con il resto del progeto. L'uso di patern nella descrizione di altri patern d origine ai cosiddet linguaggi di patern.

DESIGN PATTERN
Creazionale
Abstract Factory Builder Factory Method Prototype Singleton Crea un istanza di pi famiglie di classi Separa la costruzione delloggetto della sua rappresentazione Crea un istanze di classi derivati Creare nuovi oggetti a partire da istanza prototipo Una classe con una sola istanza

ABSTRACT FACTORY
Obiettivo
Fornire uninterfaccia per la creazione di famiglie di oggetti correlati o dipendenti senza specificare quali siano le loro classi concrete.

Motivazione
Realizzazione di diverse implementazioni di una classe con possibilit al cliente di scegliere in modo semplice tra queste. Un sistema deve essere indipendente dalla modalit di creazione, composizione, rappresentazione dei suoi prodotti.

Esempio
Strumento per lo sviluppo dinterfaccia look and feel, per esempio Motif e Presentation Manager, che difiniscono diverse modalit di presentazione e comportamento per gli elementi (widget) dellinterfaccia utente (finestre, barra di scorrimento, pulsanti).

ABSTRACT FACTORY

ABSTRACT FACTORY: partecipanti

AbstractFactory
dichiara uninterfaccia per le operazioni di creazione di oggetti prodotto astratti.

ConcreteFactory AbstractProduct ConcreteProduct

implementa le operazioni di creazione degli oggetti prodotto. dichiara un interfaccia per una tipologia di oggetti prodotto concreti.

definisce un oggetto prodotto che dovr essere creato dalla corrispondente factory concreta. Implementa linterfaccia AbstractProduct utilizza soltanto le interfacce dichiarate dalle classi AbstractFactory.

Client

ABSTRACT FACTORY: esempio

ABSTRACT FACTORY: conseguenze

Promuove coerenza nellutilizzo dei prodotti

Isola le classi concrete

Aggiunta supporto per nuove tecnologie di prodotti difficile

BUILDER
Obiettivo
Separare la costruzione di un oggetto complesso dalla sua rappresentazione cosicch il processo di costruzione stesso possa creare diverse rappresentazioni.

Motivazione
Realizzazione di diverse implementazioni di una classe con possibilit al cliente di scegliere in modo semplice tra queste. L'algoritmo per la creazione di un oggetto complesso indipendente dalle varie parti che costituiscono l'oggetto e da come vengono assemblate

Esempio
Strumento per lo sviluppo dinterfaccia look and feel, per esempio Motif e Presentation Manager, che difiniscono diverse modalit di presentazione e coportamento per gli elementi (widget) dellinterfaccia utente (finestre, barra di scorrimento, pulsanti).

BUILDER

BUILDER: partecipanti
ConcreteBuilder
costruisce e assembla le parti del prodotto implementando l'interfaccia Builder; definisce e tiene traccia della rappresentazione che crea.

Director Product

costruisce un oggeto utilizzando l'interfaccia Builder. rappresenta l'oggeto complesso e include le classi che defniscono le parti che lo compongono, includendo le interfacce per assemblare le parti nel risultato fnale.

BUILDER: esempio

Builder conseguenze
Consente di variare la rappresentazione interna di un prodotto

Isola il codice per la costruzione e la rappresentazione

Migliore controllo del processo di costruzione

Simile al Abstract Factory ma il Builder si focalizza sulla costruzione di un oggetto complesso passo dopo passo, mentre lAbstract Factory pone enfasi su famiglie di oggetti prodotto.

Factory method
Obiettivo
fornisce un metodo per istanziare un'oggetto senza sapere a priori la sua esatta classe. Questo pattern raggiunge il suo scopo fornendo un'interfaccia per creare un oggetto, ma lascia che le sottoclassi decidano quale oggetto istanziare.

Motivazione
Realizzazione di diverse implementazioni di una classe con possibilit al cliente di scegliere in modo semplice tra queste. L'algoritmo per la creazione di un oggetto complesso indipendente dalle varie parti che costituiscono l'oggetto e da come vengono assemblate

Esempio
Strumento per lo sviluppo dinterfaccia look and feel, per esempio Motif e Presentation Manager, che difiniscono diverse modalit di presentazione e coportamento per gli elementi (widget) dellinterfaccia utente (finestre, barra di scorrimento, pulsanti).

Factory method

Factory method: partecipanti

ConcreteProduct implementa l'interfaccia di Product. Creator dichiara il factory method che ritorna un oggeto di tipo Product e lo pu chiamare per creare un oggeto di tipo Product; il creator pu defnire un'implementazione del factory method che ritorna un oggeto ConcreteProduct di default. ConcreteCreator ridefnisce il factory method per tornare un'istanza di un ConcreteProduct

Factory method: esempio

Prototype: esempio
il nome di un design pattern creazionale utilizzato per creare nuovi ogget clonando un oggeto iniziale, deto appunto prototipo. A diferenza di altri pattern come Abstract factory o Factory method permete di specifcare nuovi ogget a tempo d'esecuzione (run-time), utilizzando un gestore di prototipi (prototype manager) per salvare e reperire dinamicamente le istanze degli ogget desiderati.

SINGLETON
Obiettivo
Assicurarsi che una sola istanza esiste durante tutta la durata della vostra applicazione. Una sola nello spazio come nel tempo: lo spazio rappresentato dalla memoria siete certi dellunicit dellistanza a un momento dato. il tempo vi assicurate dellunicit a ognuna chiamata.

Esempio

Unica istanza per il sistema manager.

SINGLETON

Costruttore e deve essere privato

SINGLETON: implementazione
// Singleton pattern -- Structural example using System; // "Singleton" class Singleton { // Fields private static Singleton instance; // Constructor protected Singleton() {} // Methods public static Singleton Instance() { // Uses "Lazy initialization"

DESIGN PATTERN
Strutturale
Adapter Bridge Composite Decorator Faade Flyweight Proxy Match interfacce di classi diversi Separa linterfaccia delloggetto della sua implementazione Struttura ad albero per oggetti simpleci e composti Aggiunge responsabilit a oggetti inamicamente Una sola classe che rappresenta un intero sotto-sistema Uso della condivisione per supportare in modo efficiente istanza di oggetti a granularit fine un oggetto rappresentando un altro oggetto

ADAPTOR
Obiettivo Convertire linterfaccia di una classe in unaltra interfaccia richiesta dal cliente. Motivazione
A volte interfaccia progettata, con obiettivo di riuso, diversa da interfaccia richiesta (problema conformit a norme,). Non si dispone alla sorgente per modificare una libreria non adatta. Non dipendere di una implementazione. Permettere levoluzione del vostro progetto. Il problema si presenta ogni qual volta nel progetto di un si debbano utilizzare sistemi di supporto (come per esempio ) dotati di interfaccia non perfettamente compatibile con quelle richieste da applicazioni gi esistenti. Invece di dover riscrivere parte del sistema, oneroso e non sempre possibile se non si ha a disposizione il , pu essere comodo scrivere un Adapter che faccia da tramite tra le diverse interfacce, rendendole cos compatibili.

ADAPTOR

ADAPTOR: partecipanti
Target
definisce linterfaccia specifica del domiio utilizzata dal client.

Client
collabora con oggetti compatibili con interfaccia Target.

Adaptee
individua un interfaccia esistente che deve essere adattata.

ConcreteDecorator
adatta linterfaccia di Adaptee allinterfaccia Target.

ADAPTOR: esempio

ADAPTOR: conseguenze
Introduce solo un oggetto e non occorrono ulteriori indirezioni con puntatori per ottenere un riferimento all'oggetto adatto Non pu essere utilizzato quando si vuole utilizzare una classe e tutte le sue sottoclassi. l'indirizzino addizionale potrebbe ridurre lefficienza

BRIDGE
Obiettivo Il bridge pattern un design pattern che permette di separare l'interfaccia di una classe (che cosa si pu fare con la classe) dalla sua implementazione (come si fa). In tal modo si pu usare l'ereditariet per fare evolvere l'interfaccia o l'implementazione in modo separato. Motivazione
Oggetti concreti non conosciuti nella fase di design. Oggetti concreti dipendono da loro implementazione (SO,...)

BRIDGE

BRIDGE: esempio

BRIDGE: conseguenze
possibile evitare dei collegamenti permanenti tra un'astrazione e la sua implementazione ed possibile espandere facilmente la gerarchia con nuove coppie di classi. possibile combinare anche diversi tipi di oggetti senza dover ricompilare il codice sorgente.

COMPOSITE
Obiettivo
Modello di struttura arborescente di un insieme di componenti coerenti. Permette alla classe cliente di comporre e utilizzare in un modo coerente (unico) una gerarchica complessa di oggetti.

Esempio
Negozio di Sport: Prodotto tuta o tuta + scarpe o sopra tuta o sotto tutta il prezzo dinsieme calcolato secondo il metodo seguente: somma prezzi partite (composte o no) meno 10% il codice barre specifico a ciascuno prodotto venduto Nome descrittivo dellinsieme il descrittivo di ciascuno + insieme.

COMPOSITE

COMPOSITE: partecipanti
Component
dichiara linterfaccia per gli oggetti della composizione. implementa il comportamento per default per linterfaccia comune di tutte le classe. dichiara una interfaccia per accedere e gestire i componenti figli.

Foglio

rappresenta loggetto foglia nella composizione. Non ha figli. definisce il comportamento per gli oggetti primitivi nella composizione. definisce il comportamento dei componenti avendo figli. memorizza i figli. realizza le operazioni per accedere ai figli. Manipolano gli oggetti della composizione a traverso linterfaccia component.

Composite

Client

COMPOSITE: conseguenze

Composite pattern rende il cliente semplice: se la richiesta fatta ad una foglia, viene trattata direttamente, se alla composizione, viene delegata ai suoi figli Pu rendere il progetto troppo generico. Rende pi difficile limitare i componenti che fanno parte di una struttura composite.

DECORATOR
Obiettivo Aggiunta dinamica di responsabilit ad un oggetto. Motivazione Aggiunta di responsabilit ad un singolo oggetto non a unintera classe. Evitare di ereditare, la proliferazione di classe. Esempio Realizzazione interfaccia utente: per un testo, possibile aggiungere quando necessario, la barra di scorrimento e il bordo. Un approccio flessibile di racchiudere il componente da decorare in un altro. Loggetto contenitore chiamato decorator.

DECORATOR

DECORATOR: partecipanti
Component
definisce linterfaccia comune per gli oggetti a quale possono essere aggiunte responsabilit dinamicamente.

ConcreteComponent
definisce un oggetto a quale possono essere aggiunte responsabilit ulteriori.

Decorator
mantiene un riferimento a un oggetto Componente definisce un interfaccia conforme allinterfaccia di Component.

ConcreteDecorator
Aggiunge responsabilit al componente.

DECORATOR: esempio

dynamic scroll bar solution

DECORATOR: conseguenze
Maggiore flessibilit rispetto all'ereditariet statica Evita di definire classi troppo complesse nella gerarchia Un decorator e suo componente non sono identici

Grande quantit di piccoli oggetti

FACADE
Obiettivo
nella indica un oggetto che permette, attraverso un'interfaccia pi semplice, l'accesso a sottosistemi che espongono interfacce complesse e molto diverse tra loro, nonch a blocchi di codice complessi.

FACADE
Obiettivo
nella indica un oggetto che permette, attraverso un'interfaccia pi semplice, l'accesso a sottosistemi che espongono interfacce complesse e molto diverse tra loro, nonch a blocchi di codice complessi.

FACADE

FACADE: esempio

Esempio compilator

DESIGN PATTERN
Comportamentale
Chain of Resp. Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor Modo per passare richieste tra catena di oggetti Incapsula una comanda di richiesta ad un oggetto Modo to includere la grammatica di elementi in un programma Accesso sequenziale ad elementi di una collezione Definisce delle comunicazione semplice tra classi Cattura e ripristina lo stato interno di un oggetto Modo per segnalare il cambiamento ad un numero di classi Altera il comportamento di un oggetto quando il suo stato cambia Incapsula un algoritmo in una classe lascia che le sottoclassi ridefiniscano alcuni passi dellalgoritmo definisce una nuova operazione per una classe senza cambiamenti

ITERATOR
Obiettivo
Fornire un modo di accesso sequenziale agli elementi che formano un oggetto composito, senza esporre allesterno la struttura interna delloggetto composito.

ITERATOR

ITERATOR
Iterator
Definisce un interfaccia per accedere e attraversare una sequenza di elementi.

ConcreteIterator

Aggregate

implementa linterfaccia Iterator. Tiene traccia della posizione corrente nellattraversamento delloggetto composito. Definisce un interfaccia per la creazione di un oggetto Iterator. Implementa linterfaccia per la creazione di Iterator restituendo unistanza del ConcreteIterator appropriato.

ConcreteAggregate

Client

utilizza soltanto le interfacce dichiarate dalle classi AbstractFactory.

ITERATOR: esempio

ITERATOR: conseguenze
Oggetti compositi complessi possono essere attraversati in modo diversi. Con Iterator facile cambiare l'algoritmo di attraversamento

OBSERVER
Obiettivo
utilizzato per tenere sotto controllo lo stato di diversi oggetti. Se un oggetto cambia il suo stato, tutti gli oggetti dipendenti da questo saranno notificati e aggiornati automaticamente.

OBSERVER

OBSERVER: esempio

OBSERVER: conseguenze
Accoppiamento astratto fra Subject e Observer Aggiornamenti inattesi