design patterns parte 1 · design patterns introduzione (5/64) definizione di “design pattern”...

1

Design Patterns Parte 1

!

Design PatternsIntroduzione (1/64)

TerminologiaPrima di introdurre l'argomento conviene porsi una domanda sulla terminologia.... !

... cosa significa letteralmente “Design Patterns” ? !Osserviamo i significati che comunemente vengono attribuiti alla parola “pattern”:

3


Origini e storia

Fine degli anni 70: Christopher Alexander introduce il concetto di patterns nel settore dell'architettura. Il suo approccio prevedeva: !

" identificazione/descrizione della totalità di progetti di elevata qualità, " studio di differenti strutture progettate per risolvere lo stesso problema.

Identificando le similarità tra i progetti di alta qualità, utilizzò il termine “pattern” per riferirsi alle soluzioni progettuali nelle quali fossero presenti tali “similarità”. Rif. bibliografici:

" Towns, Buildings, Construction (Oxford University Press, 1977) " The Timeless Way of Building (Oxford University Press, 1979)

!Nel 1987, Kent Beck e Ward Cunningham applicarono le idee che Alexander aveva avuto per l'architettura allo sviluppo e al progetto di software. L'adozione dei software design patterns avviene nel 1994 grazie al libro edito dalla Addison Wesley:

“Design Patterns: Elements of Reusable Object-Oriented Software”

scritto dalla nota GoF[Gang of Four] : Gamma,Helm,Johnson,Vlissides.

4


Definizione di “Design Pattern” (1/3)

una prima “definizione” di Design Patterns

“Christopher Alexander descrive un pattern come una soluzione per un problema ricorrente in un determinato contesto e sistema di forze.”

soluzione = Esplicita lo scopo per cui i design patterns sono stati concepiti: essi servono per risolvere i problemi tipici di un dato ambito.! !

problema ricorrente = E' l'obiettivo di ogni design patterns: !dare una soluzione di elevata qualità e buon compromesso per i problemi che comunemente si presentano ai progettisti.! !

contesto = Si riferisce all'insieme di condizioni e situazioni in cui un dato pattern è applicabile.! !

sistema di forze = Rappresenta l'insieme di vincoli che si possono verificare in uno specifico contesto.

5



Cosa distingue un progettista esperto da uno alle prime armi ? !

L'esperto usa un bagaglio di pratiche e di soluzioni aquisite che gli consente di non dover risolvere ogni problema partendo dalle origini del contesto in cui opera.

!Quando un esperto trova una “buona” soluzione tenderà ad utilizzarla in tutti i contesti in cui essa risulta applicabile.

!Conseguentemente nei sistemi object oriented si possono identificare dei “patterns” ricorrenti intesi come “modelli di classi e oggetti interagenti”

per la risoluzione di una determinata classe di problemi. Tali patterns se identificati e formalizzati aiutano i progettisti a riusare

non solo il codice ma anche l'esperienza codificata nei precedenti progetti. !

Un progettista che è familiare con alcuni patterns può applicarli immediatamente senza doverli rispcoprire.

“I Design Patterns consentono di imparare dai successi altrui invece che dai propri fallimenti” M.Johnson

6



un pattern ha 4 elementi essenziali: [GoF]Nome del Pattern = Il nome del pattern è il modo con cui in una o due parole possiamo riferirci ad un problema, la sua soluzione e le conseguenze della sua applicazione.

Il Problema = Il problema descrive quando è possibile applicare il pattern. Esso cioè esplicita il “contesto” di cui si è prima discusso. Esso può includere una lista di condizioni che devono essere verificate affinchè abbia senso applicare il pattern.

La soluzione = descrive gli elementi che fanno parte del progetto, le loro relazioni, responsabilità e collaborazioni. Essa non descrive una specifica implementazione in quanto un pattern deve poter essere applicabile in diverse situazioni concrete.

Le conseguenze = Le conseguenze sono il risultato di trade-offs derivanti dall'applicazione del pattern. Esse sono di importanza critica nella valutazione di alternative di progetto e per la compresione di costi e benefici relative all'applicazione del pattern.


Descrivere i Design Patterns

Come descriviamo e documentiamo i design patterns ?Un approccio basato sulle sole notazioni grafiche è insufficiente in quanto aspetti fondamentali della descrizione risultano essere: - Le decisioni , le alternative ed i trade-off che hanno condotto ad una certa soluzione. - Esempi concreti di utilizzo da imparare e comparare ed usare. Il formato proposto da GoF, per ogni pattern fornisce le seguenti informazioni: - Nome del pattern e classificazione - Intento - Eventuali alias - Motivazione - Applicabilità - Struttura - Partecipanti - Collaborazioni - Conseguenze - Implementazione / Esempi di uilizzo - Usi conosciuti - Patterns correlati

8


Classificazione dei Design Patterns [GoF,1998]

Il catalogo presentato in GoF consta di 23 design patterns. Di seguito è riportata la classificazione operata dagli autori del libro del loro catalogo di patterns. !I criteri fondamentali per la classificazione dei design patterns sono i seguenti: !- Purpose (Obiettivo) L'obiettivo riflette il campo di applicazione del patterns. GoF individua le seguenti categorie : - Creazionali - Strutturali - Comportamentali - Scope (Contesto) L'ambito specifica se il pattern si applica alle classi o agli oggetti. S

cope

BridgeComposite

SingletonMemento

State

PurposeCreational Structural Behavioral

ClassFactory Method Adapter Interpreter

Template Method

Object

Abstract Factory Adapter Chain of ResponsabilityBuilder Command

Prototype IteratorDecorator Mediator

FacadeProxy Flyweight

Observer

StrategyVisitor

9

Design PatternsPatterns creazionali (8/64)

Introduzione" Un creational pattern rende un sistema indipendente da come gli oggetti

sono creati, composti e rappresentati; !" Esistono due temi ricorrenti circa i creational patterns:

– Incapsulare la conoscenza delle classi concrete che il sistema istanzia; – Nascondere il modo in cui le istanze di tali classi siano create e composte.

!" In definitiva, si introduce flessibilità circa cosa è stato creato, chi lo ha creato,

come lo ha creato, e dove. I design patterns creazionali che analizzeremo: !" Factory Method = Interfaccia per la creazione di oggetti. Delega alle

sottoclassi la decisione sulle classi concrete da istanziare. " Abstract Factory = Consente la creazione di oggetti senza il bisogno di

specificare le classi concrete che vengono istanziate. " Singleton = Consentire ad una determinata classe una sola istanza e fornire

per essa un solo punto di accesso. " Builder = Disaccoppiare l'algoritmo di creazione di un oggetto complesso dagli

aspetti specifici legati alla sua creazione.

10


Factory Method(1/6)

" Intento: definire un’interfaccia per la creazione di un oggetto, delegando alle sottoclassi la decisione su quali classi istanziare.

" Alias: Virtual Constructor " Motivazioni: Consideriamo un framework che supporta diversi tipi di documenti.

Le classi astratte Application e Document rappresentano l'infrastruttura del framework. Per creare un’applicazione per disegnare, occorre creare le classi DrawingApplication e DrawingDocument. Il pattern dunque consente di spostare all’esterno del framework la conoscenza di quale sottoclasse di documenti creare.

11


Factory Method(2/6)

" Applicabilità: il pattern può essere utilizzato quando: – una classe non può conoscere in anticipo la classe degli oggetti che deve

creare; – una classe desidera delegare alle proprie sottoclassi la responsabilità di

creare gli oggetti; – alcune classi delegano specifiche responsabilità ad una tra un insieme di

classi di supporto, e si vuole localizzare la conoscenza della classe di supporto a cui delegare.

" Structure:

12


Factory Method(3/6)

" Collaborazioni: – Il Creator si affida alle proprie sottoclassi per definire il Factory Method, in

maniera tale che questo ritorni un’appropriata istanza del ConcreteProduct. " Conseguenze:

– Creare agganci(“hooks”) alle sottoclassi – Creare un oggetto con un FactoryMethod invece che direttamente fornisce un grado di flessibilità superiore. Il FactoryMethod fornisce infatti alle sottoclassi un aggancio per produrre versioni estese di un oggetto;

– Collegare gerarchie di classi parallele – Consideriamo una gerarchia di classi che rappresentano figure geometriche. Supponiamo di voler implementare un operazione di “stretching” interattiva. Essa assume significati diversi su oggetti di tipo diverso. I problemi sono due:

" Memorizzazione dello stato

" Associazione della figura ad opportuno manipolatore che sa come operare su di essa.

13


Factory Method(4/6)

Il client deve istanziare direttamente le classi della gerarchia di prodotti per cui dipende da essa.

Il client conosce solo l'interfaccia Creator. La logica di creazione e la conoscenza delle classi della gerarchia di prodotti è nel FactoryMethod.

14


Factory Method(4/6)

Client

Client Client

Client

ClientClient

AbstractParent

SubClass1

SubClass2

SubClass3

Client ClientClient ClientClient

AbstractParent

SubClass1

SubClass2

SubClass3

15


Factory Method(6/6)

public Document CreateDocument(String type){ if (type.isEqual("html")) return new HtmlDocument(); if (type.isEqual("proprietary")) return new MyDocument(); if (type.isEqual("pdf")) return new PdfDocument (); }

16


Abstract Factory (1/6)

" Intento: Fornire un’interfaccia per creare famiglie di oggetti dipendenti senza specificare le classi concrete;

" Noto come: kit " Motivazioni: Come esempio possiamo riferirci ad un user interface toolkit che

supporta un certo numero di look-and-feel (es. Win32 GDI, QT, Gtk+, Motif), che definiscono differenti comportamenti e notazioni grafiche per gli elementi grafici come bottoni, scrollbars, checkboxes, radiobuttons, groupboxes etc. Per essere portabile una applicazione non dovrebbe utilizzare in maniera diretta gli oggetti grafici di uno specifico look-and-feel. Questo modo rende in seguito molto più costoso e laborioso sistituire il look&feel e/o portare l'applicazione su altri sistemi.

" Applicabilità: Quando sussiste una delle seguenti condizioni: " Il sistema software deve essere indipendende da come gli oggetti (che

nella terminologia del pattern sono i prodotti) sono creati, composti e rappresentati.

" Il sistema software deve essere configurato con famiglie multiple di prodotti.

" Una famiglia di prodotti è stata progettata per essere utilizzata nel suo insieme, e si vuole imporre questo vincolo.

" Si vuole fornire una libreria di prodotti rivelandone solo le interfacce.

17

" Struttura:



18



Partecipanti al pattern: !" AbstractFactory " dichiara un'interfaccia per le operazioni che creano un prodotto astratto. " ConcreteFactory " implementa le operazioni per creare prodotti concreti. " AbstractProducts " dichiara un'interfaccia per un tipo di prodotto. " ConcreteProducts " definisce un prodotto concreto creato dalla corrispettiva

factory. " Client " usa solo le interfacce dichiarate da AbstractFactory e

AbstractProduct. !

Collaborazioni !Una singola istanza di una classe ConcreteFactory viene creata a run-time. Questa ConcreteFactory consente di creare prodotti che hanno una particolare implementazione. Per creare prodotti differenti, l'utilizzatore del pattern deve scegliere un'altra ConcreteFactory. L'AbstractFactory delega infatti la creazione dei prodotti alle sue sottoclassi ConcreteFactory. !

19


Abstract Factory (4/6)!Conseguenze

1.Isola le classi concrete – Aiuta a controllare quali classi di oggetti l'applicazione istanzia. La responsabilità di creare oggetti è infatti tutta incapsulata nelle factories; questo consente al cliente di interagire con le sole interfacce astratte nel cui codice non compaiono i nomi delle classi prodotti concreti da istanziare.

!2.Consente di scambiare famiglie di prodotti facilmente – La classe di una

concrete factory appare una sola volta nel codice dell'applicazione: quando essa viene istanziata. Una famiglia di prodotti fa capo ad una sola factory per cui è molto semplice sostituirla: basta sostituire la factory che viene istanziata.

!3.Promuove la consistenza tra prodotti – Quando i prodotti di una famiglia sono

progettati per essere utilizzati insieme è importante che l'applicazione non tenti di istanziare prodotti da famiglie diverse contemporaneamente. Questo vincolo è molto facile da imporre mediate il pattern AbstractFactory.

!4.Supportare nuovi tipi di prodotti è oneroso – Estendere l'AbstractFactory

per produrre nuovi tipi di prodotto non è facile. Infatti l'interfaccia AbstractFactory fissa l'insieme dei prodotti che possono essere creati. Supportare nuovi prodotti impone di estendere l'interfaccia stessa e tutte le sue sottoclassi.

20


Singleton(1/2)

" Intento: Assicurarsi che una classe abbia soltanto un’istanza, e fornirne un unico punto di accesso

" Motivazioni: Ad esempio, mentre in un sistema è probabile vi siano più stampanti installate contemporaneamente, dovrebbe esserci soltanto un unico spool. Come assicurarsi che la classe spool abbia una sola istanza e che questa sia globalmente accessibile?

– Bisogna far si che la classe tenga traccia delle proprie istanze.

" Applicabilità: Il Singleton va utilizzato quando: – Deve esserci esattamente una singola istanza di una classe che deve

essere accessibile da un punto di accesso ben preciso; – Quando una singola istanza di una classa deve essere estensibile tramite

subclassing ed i client dovrebbero poter utilizzare l’istanza estesa senza modificare il proprio codice.

" Struttura:

21


Singleton(2/2)

" Collaborations: I client accedono all’istanza del Singleton tramite l’operazione di Instance del Singleton stesso.

" Conseguenze: – Accesso controllato all’istanza singola; – Name space ridotto; – Raffinamento di operazioni e rappresentazione delle stesse; – Possibilità di usare un numero variabile di istanze; – Maggiore flessibilità rispetto all’uso degli static member.

" Implementazione:

22


Singleton Esempio

23


Singleton Esempio

24


Singleton Esempio

vector<Virtual_Device*> Virtual_Device::_devices;//vector allocation !Virtual_Device::Virtual_Device ( std::string name ){ unique_name = name; };!bool Virtual_Device::isRegistered(std::string name) { ! vector<Virtual_Device*>::iterator i; ! for ( i = _devices.begin() ; i != _devices.end() ; ++i) { Virtual_Device* dev = *i; const std::string devName = dev->getUniqueName(); if (name == devName) return true; } return false; }

25


Singleton Esempiovoid Virtual_Device::registerDevice(Virtual_Device* dev) { _devices.push_back(dev); } void Virtual_Device::unregisterDevice(Virtual_Device* dev) { vector<Virtual_Device*>::iterator i,fDev; bool found = false; for ( i = _devices.begin() ; (i != _devices.end() && !found) ; ++i) { Virtual_Device* _dev = *i; if (_dev == dev) { found = true; fDev = i; } } if (found) _devices.erase(fDev); else throw DeviceNotFoundException(); } Virtual_Device* Virtual_Device::getDevice(std::string name){ vector<Virtual_Device*>::iterator i; for ( i = _devices.begin() ; i != _devices.end() ; ++i) { Virtual_Device* dev = *i; const std::string devName = dev->getUniqueName(); if (name == devName) return dev; } throw DeviceNotFoundException(); }

26


■ Builder: separare la costruzione di un oggetto complesso dalla relativa rappresentazione. Infatti l’algoritmo per la creazione di un oggetto complesso dovrebbe essere indipendente dalle componenti dell’oggetto stesso.Inoltre il processo di costruzione consente differenti rappresentazioni per l’oggetto

■ Prototype: Specificare il tipo di oggetti da creare utilizzando un’istanza prototipale, e creare nuovi oggetti copiando il prototipo. Il pattern va usato quando un sistema dovrebbe essere indipendente da come i prodotti sono creati e: !" Quando le classi da instanziare sono specificate a run-time; !" Quando le istanze di una classe possono trovarsi in soltanto una

(o poche) combinazioni di stati.

design patterns parte 1 · design patterns introduzione (5/64) definizione di “design pattern”...

Documents