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 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 s i 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 sull’esperienza degli autori a quel tempo. Più di 250 utilizzati oggi nel campo dell’object 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 l’interfaccia 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 Fissat alla compilazione
DESIGN PATTERN
Struttura di un design pattern Un design paern è costuio da: il nome, una o due parole che siano il più possibile rappresenatve del paern sesso; il problema, ovvero la descrizione della siuazione alla quale si può applicare il paern. Può comprendere la descrizione di classi o di problemi di progeazione specifci, come anche una lisa di condizioni perché sia necessario l'utlizzo del paern; la soluzione, che descrive gli element costutvi del progeo con le relazioni e relatve implicazioni, senza però addenrarsi in una specifca implemenazione. Il conceo è di presenare un problema asrao e la relatva confgurazione di element adaa a risolverlo; le conseguenze, i risulat e i vincoli che derivano dall'applicazione del paern. Sono ondamenali in quano possono essere l'ago della bilancia nella scela dei paern: le conseguenze comprendono considerazioni di empo e di spazio, possono descrivere implicazioni del paern con alcuni linguaggi di programmazione e l'impao con il reso del progeo. L'uso di paern nella descrizione di alri paern dà origine ai cosidde linguaggi di paern.
DESIGN PATTERN Creazionale Abstract Factory
Crea un istanza di più famiglie di classi
Builder
Separa la costruzione dell’oggetto della sua rappresentazione
Factory Method
Crea un istanze di classi derivati
Prototype
Creare nuovi oggetti a partire da istanza prototipo
Singleton
Una classe con una sola istanza
ABSTRACT FACTORY Obiettivo Fornire un’interfaccia 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 d’interfaccia look and feel , per esempio Motif e Presentation Manager , che difiniscono diverse modalità di presentazione e comportamento per gli elementi (widget) dell’interfaccia utente (finestre, barra di scorrimento, pulsanti ).
ABSTRACT FACTORY
ABSTRACT FACTORY: partecipanti AbstractFactory • dichiara un’interfaccia per le operazioni di creazione di oggetti prodotto astratti.
ConcreteFactory
• implementa le operazioni di creazione degli oggetti prodotto.
AbstractProduct
• dichiara un interfaccia per una tipologia di oggetti prodotto concreti.
ConcreteProduct
• definisce un oggetto prodotto che dovrà essere creato dalla corrispondente factory concreta. • Implementa l’interfaccia AbstractProduct
Client
• utilizza soltanto le interfacce dichiarate dalle classi AbstractFactory .
ABSTRACT FACTORY: esempio
ABSTRACT FACTORY: conseguenze • Promuove coerenza nell’utilizzo 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 d’interfaccia look and feel, per esempio Motif e Presentation Manager, che difiniscono diverse modalità di presentazione e coportamento per gli elementi (widget) dell’interfaccia 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 • cosruisce un oggeo utlizzando l'ineraccia Builder.
Product
• rappresena l'oggeo complesso e include le classi che defniscono le part che lo compongono, includendo le ineracce per assemblare le part nel risulao 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 l’Abstract 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 d’interfaccia look and feel, per esempio e sempio Motif e Presentation Manager, che difiniscono diverse modalità di presentazione e coportamento per gli elementi (widget) dell’interfaccia utente (finestre, barra di scorrimento, pulsanti).
Factory method
Factory method: partecipanti ConcreteProduct
implemena l'ineraccia di Produc. Creator
dichiara il acory mehod che riorna un oggeo di tpo Produc e lo può chiamare per creare un oggeo di tpo Produc; il creaor può defnire un'implemenazione del acory mehod che riorna un oggeo ConcreeProduc di deaul. ConcreteCreator
ridefnisce il acory mehod per ornare un'isanza di un ConcreeProduc
Factory method: esempio
Prototype: esempio è il nome di un design paern creazionale utlizzao per creare nuovi ogge clonando un oggeo iniziale, deo appuno prootpo. A dierenza di alri paern come Absrac acory o Facory mehod permee di specifcare nuovi ogge a empo d'esecuzione ( run-tme), utlizzando un gesore di prootpi ( prooype manager ) per salvare e reperire dinamicamene le isanze degli ogge desiderat.
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 dell’unicità dell’istanza a un momento dato. • il tempo – vi assicurate dell’unicità 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() {
DESIGN PATTERN Strutturale Adapter
Match interfacce di classi diversi
Bridge
Separa l’interfaccia dell’oggetto della sua implementazione
Composite
Struttura ad albero per oggetti simpleci e composti
Decorator
Aggiunge responsabilità a oggetti inamicamente
Façade
Una sola classe che rappresenta un intero sotto-sistema
Flyweight Proxy
Uso della condivisione per supportare in modo efficiente istanza di oggetti a granularità fine un oggetto rappresentando un altro oggetto
ADAPTOR Obiettivo
Convertire l’interfaccia di una classe in un’altra
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 l’evoluzione 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ì
ADAPTOR
ADAPTOR: partecipanti Target • definisce l’interfaccia 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 l’interfaccia di Adaptee all’interfaccia 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 l’efficienza
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 d’insieme è calcolato secondo il metodo seguente: somma prezzi partite (composte o no) meno 10% • il codice barre è specifico a ciascuno prodotto venduto • Nome descrittivo dell’insieme è il descrittivo di ciascuno + insieme.
COMPOSITE
COMPOSITE: partecipanti Component • dichiara l’interfaccia per gli oggetti della composizione. • implementa il comportamento per default per l’interfaccia comune di tutte le classe. • dichiara una interfaccia per accedere e gestire i componenti figli.
Foglio
• rappresenta l’oggetto foglia nella composizione. Non ha figli. • definisce il comportamento per gli oggetti primitivi nella composizione.
Composite
• definisce il comportamento dei componenti avendo figli. • memorizza i figli. • realizza le operazioni per accedere ai figli.
Client • Manipolano gli oggetti della composizione a traverso l’interfaccia component.
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 un’intera 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. L’oggetto contenitore è chiamato decorator .
DECORATOR
DECORATOR: partecipanti Component • definisce l’interfaccia 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 all’interfaccia 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.
Modo per passare richieste tra catena di oggetti
Command
Incapsula una comanda di richiesta ad un oggetto
Interpreter
Modo to includere la grammatica di elementi in un programma
Iterator
Accesso sequenziale ad elementi di una collezione
Mediator
Definisce delle comunicazione semplice tra classi
Memento
Cattura e ripristina lo stato interno di un oggetto
Observer
Modo per segnalare il cambiamento ad un numero di classi
State
Altera il comportamento di un oggetto quando il suo stato cambia
Strategy
Incapsula un algoritmo in una classe
Template Method
lascia che le sottoclassi ridefiniscano alcuni passi dell’algoritmo
Visitor
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 all’esterno la struttura interna dell’oggetto composito.
ITERATOR
ITERATOR Iterator • Definisce un interfaccia per accedere e attraversare una sequenza di elementi.
ConcreteIterator
• implementa l’interfaccia Iterator . • Tiene traccia della posizione corrente nell’attraversamento dell’oggetto composito.
Aggregate
• Definisce un interfaccia per la creazione di un oggetto Iterator.
ConcreteAggregate • Implementa l’interfaccia per la creazione di Iterator restituendo un’istanza del ConcreteIterator appropriato.
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
