Design Patterns - MathUniPDlocalconte/lezioni/Pattern(1e2).pdf · 2009-01-07 · Descrizione di un Design Pattern (2) Applicability What are the situations in which the design pattern

© Renato Conte - Design patterns - 1 / 67 -

Design Patterns Questa presentazione prende spunto dal testo

“Design Patterns” della banda dei quattro*

*(vedi bibliografia alla fine delle presentazioni)

Università di Padova

Facoltà di Scienze MM.FF.NN

Informatica - anno 2008-09

Corso di Ingegneria del Software


Pattern?

“ Nel gioco degli scacchi per essere:

• un principiante, basta conoscere le regole del gioco e le principali mosse;

• un discreto giocatore, bisogna riconoscere gli errori ed imparare alcune strategie di posizionamento;

• maestro, bisogna studiare le partite dei grandi maestri, individuarne i patternpattern nascosti, memorizzarli e applicarli finché diventano una seconda natura. ”

( da uno scritto di R.G.Martin, liberamente adattato )


Design Pattern

Ogni pattern descrive un problema che si ripete più e più volte nel nostro ambiente, descrive poi il nucleo della soluzione, in modo tale da poter essere riutilizzato

Un design pattern sistematicamente fissa, spiega e valuta progetti importanti e ricorrenti.


Pattern e Framework

I pattern descrivono strutture statiche e dinamiche di soluzioni già collaudate con successo che possono applicarsi ai nostri problemi e semplificare i nostri progetti I pattern supportano il riuso dell’architettura e della progettazione software

Un framework è un insieme integrato di componenti che forniscono lo scheletro di un’applicazione riusabile per uno specifico dominio applicativo. Un framework deve essere personalizzato.I framework supportano il riuso di progetti dettagliati e di codice già pronto

Insieme, design pattern e framework, aiutano a migliorare la qualità del software e riducono i tempi di sviluppo, cioè migliorano: il riuso, l’estensibilità, la modularità, le prestazioni


Come diventare un “Master Designer”Primo - imparare le regole:

AlgoritmiStrutture datiLinguaggi (di programmazione e di progettazione)

In seguito - conoscere i principi della programmazione e dell’analisi:Programmazione strutturataOO POOA OOD

Infine - studiare i progetti e le soluzioni degli esperti: I “Design pattern” devono essere compresi, memorizzati ed applicati

Esistono migliaia di pattern © Renato Conte - Design patterns - 6 / 67 -

Storia dei pattern‘77 - Il lavoro dell’architetto Christopher Alexander

‘80 - Kent Beck e i primi pattern in Smalltalk

‘91 - Tesi di dottorato di Gamma su ET++

‘92 - Pubblicazione di Coad sui pattern

‘92 - Pubblicazione di Johnson ( a OOPSLA)

‘93 - OOPSLA: workshop di Coad & Anderson

‘93 - Gruppo di discussione su WWW

‘94 - Prima conferenza PLoP

‘95 - Gang of four book (prima presentazione OOPSLA 93)

... e molto altro ...


Classificazione dei pattern del GoF

Factory Method

Abstract FactoryBuilderPrototypeSingleton

Adapter (class)

Adapter (object)BridgeCompositeDecoratorFacadeFlyweightProxy

InterpreterTemplate Method

Chain of Responsibility

CommandIteratorMediatorMementoObserverStateStrategyVisitor

Creazionali Strutturali Comportamentali

Scopo

ScopeClass

Object


Tipi di Design Pattern

Creazionale (Creational patterns)– Tratta l’argomento della configurazione ed inizializzazione di classi ed oggetti

Strutturale (Structural patterns)– Tratta l’argomento del disaccoppiamento tra interfacce ed implementazione delle classi e degli oggetti e della loro composizione

Comportamentale (Behavioral patterns)– Tratta l’argomento delle interazioni dinamiche tra gruppi di classi ed oggetti


Pattern Creazionali: aspetti progettuali coinvolti

(1) Factory Method– creazioni istanze di sottoclassi

(2) Abstract FactoryAbstract Factory– famiglie di oggetti

(3) Builder– creazione incrementale di oggetti complessi

(4) Prototype– clonazione di nuove istanze da prototipo

(5) Singleton – unica istanza


Pattern Strutturali: aspetti progettuali coinvolti (1)

(6) AdapterAdapter– adattamento interfaccia

(7) Bridge– disaccoppiamento astrazione / implementazione

(8) CompositeComposite– strutture per costruire aggregazioni di oggetti

(9) Decorator– estensione delle funzionalità di un oggetto in modo trasparente


Pattern Strutturali: aspetti progettuali coinvolti (2)

(10) FaFaççadeade– semplifica l’interfaccia ad un sottosistema

(11) Flyweight– condivisione per gestire numerosi oggetti

(12) Proxy– un oggetto approssima un altro


Pattern Comportamentali: aspetti progettuali coinvolti (1)

(13) Interpreter– interprete di un linguaggio per semplici grammatiche

(14) Template MethodTemplate Method– gestione di un algoritmo con passi definiti da sottoclassi

(15) Chain of Responsibility – disaccoppiamento mittente destinatario (lista destinatari)

(16) Command– gestione comandi per un oggetto



(17) IteratorIterator– per l’accesso sequenziale su aggregati di oggetti

(18) Mediator– permette un basso accoppiamento tra oggetti che interagiscono

(19) Memento– cattura e ripristina lo stato interno di un oggetto

(20) ObserverObserver– aggiornamenti automatici su oggetti dipendenti da un altro oggetto © Renato Conte - Design patterns - 14 / 67 -


(21) State– oggetto il cui comportamento dipende dal suo stato

(22) Strategy– astrazione per la selezione di algoritmi

(23) Visitor– operazioni applicate ad elementi di una struttura di oggetti eterogenei


Descrizione di un Design Pattern (1) tratto da: http://hillside.net/patterns/writing/GOFtemplate.htm

(trad.§1.3)Pattern Name (Scope, Purpose)The pattern's name conveys the essence of the pattern succinctly. A good name is vital, because it will become part of your design vocabulary.

IntentA short statement that answers the following questions: What does the design pattern do? What is its rationale and intent? What particular design issue or problem does it address?

Also Known AsOther well-known names for the pattern, if any.

MotivationA scenario that illustrates a design problem and how the class and object structures in the pattern solve the problem. The scenario will help you understand the more abstract description of the pattern that follows.


Descrizione di un Design Pattern (2)

ApplicabilityWhat are the situations in which the design pattern can be applied? What are examples of poor designs that the pattern can address? How can you recognise these situations? Structure & ParticipantsThe classes and/or objects participating in the design pattern and their responsibilities.

CollaborationsHow the participants collaborate to carry out their responsibilities.

ConsequencesHow does the pattern support its objectives? What are the tradeoffs and results of using the pattern? What aspect of system structure does it let you vary independently?


Descrizione di un Design Pattern (3)

ImplementationWhat pitfalls, hints, or techniques should you be aware of when implementing the pattern? Are there language-specific issues?

Sample Code and UsageCode fragments that illustrate how you might implement the pattern in C++ , Smalltalk, Java.Program Listing

Known UsesExamples of the pattern found in real systems. We include at least two examples from different domains.

Related PatternsWhat design patterns are closely related to this one? What are the important differences? With which other patterns should this one be used?


Alcuni esempi di design pattern


Facade Patternstrutturale

(scritto anche Façade)

• Fornisce un’interfaccia unificata per un insieme di interfacce presenti in un sottosistema

• Façade definisce una interfaccia a più alto livello di

astrazione che rende il sottosistema più semplice da utilizzare


Façade Pattern: motivazioni d’utilizzo

• Si usa un oggetto Façade per avere una singola e semplice interfaccia, al posto di più interfacce complesse

• Minimizza la comunicazione e la dipendenza tra sottosistemi

• Promuove l’accoppiamento lasco fra un sottosistema ed i suoi client.


Struttura e significato di un Façade Pattern

Subsystem Classes

Façade

Client Classes

Subsystem Classes

Client Classes


Esempio applicativo di Façade Pattern

Compiler

Scanner

Parser

Token

ProgNode

ProgNodeBuilder

RISCCG

StackMachineCG

Statement Node

Expression Node

Variable NodeCompiler Subsystem Classes

Compile()

CodeGenerator


Partecipanti del Façade Pattern

• Façade (compiler):– conosce le classi nel sottosistema che sono responsabili di

una richiesta– delega le richieste dei client agli oggetti appropriati nel

sottosistema• Subsystem Classes (scanner, parser, ...):

– implementano le funzionalità del sottosistema.– Non hanno alcuna conoscenza dell’esistenza del Facade;

cioè non mantengono alcun riferimento ad esso.


Es. codice per Façade

class Compiler { public: Compiler(); void Compile( istream&, BytecodeStream& );}; void Compiler::Compile ( istream& input, BytecodeStream& output )

{ Scanner scanner( input ); ProgramNodeBuilder builder; Parser parser; parser.Parse(scanner, builder); RISCCodeGenerator generator(output); ProgramNode* parseTree = builder.GetRootNode(); parseTree->Traverse(generator);}


Adapter Patternstrutturale

detto anche Wrapper

Converte l’interfaccia di una classe in un’altra interfaccia richiesta dal cliente (risolve l’incompatibilità d’interfaccia)

Usato quando vogliamo riutilizzare classi in una applicazione che prevede l’uso (riuso) di classi con differenti interfacce (e noi non vogliamo cambiare le interfacce delle classi già esistenti )


Stuttura dell’Adapter Pattern usando l’ereditarietà multipla

Client TargetRequest()

AdapteeSpecificRequest()

AdapterRequest()

{implementation}

call SpecificRequest()


Stuttura dell’Adapter Pattern usando la composizione

Client TargetRequest()

AdapteeSpecificRequest()

AdapterRequest()

+adaptee

SpecificRequest()


Esempio d’utilizzo dell’ Adapter Pattern

Editor ShapeBoundingBox()

CreateManipulator()

TextViewGetExtent()

LineShapeBoundingBox()

CreateManipulator()

TextShapeBoundingBox()

CreateManipulator()

text

*

return new Text Manipulator

return text -> GetExtent()


Partecipanti dell’Adapter Pattern

• Target ( Shape ): Definisce l’interfaccia specifica del dominio utilizzata dal client

• Client ( DrawingEditor ): collabora con oggetti compatibili con l’interfaccia Target.

• Adaptee ( TextView ): individua un’interfaccia esistente che deve essere adattata

• Adapter ( TextShape ): adatta l’interfaccia di Adaptee all’interfaccia Target


Codice Adapter Pattern

class Shape //target { public: Shape(); virtual void BoundingBox( Point& bottomLeft, Point& topRight ) const; virtual Manipulator * CreateManipulator() const;};

class TextView //adaptee { public: TextView(); void GetOrigin(Coord& x, Coord& y) const; void GetExtent(Coord& width, Coord& height) const; virtual bool IsEmpty() const;};


Codice Adapter Pattern

class TextShape : public Shape, private TextView //adapter{ public: TextShape(); virtual void BoundingBox( Point& bottomLeft, Point& topRight ) const; virtual bool IsEmpty() const; virtual Manipulator* CreateManipulator() const;};

class TextShape : public Shape //adapter{ public: TextShape(); virtual void BoundingBox( Point& bottomLeft, Point& topRight ) const; virtual bool IsEmpty() const; virtual Manipulator* CreateManipulator() const;private: TextView * text; };


Composite Pattern strutturale

• Per comporre oggetti in strutture ad albero per rappresentare gerarchie “parte-tutto”.

• Consente ai client di trattare oggetti singoli e composizioni in modo uniforme.


Struttura di Composite Pattern in UML

Component {abstract}Operation()Add(Component)Remove(Component)GetChild(int)

Leaf

Operation()

Composite

Operation()Add(Component)Remove(Component)GetChild(int)

Per tutti i g in Componentg.Operation()

1..*Client

children

Alternativa...

0..*Alternativa


Esempio di un Composite Pattern

GraphicDraw()Add(Graphic)Remove(Graphic)GetChild(int)

Line TextRect.

Draw() Draw()Draw()

PictureDraw()Add(Graphic)Remove(Graphic)GetChild(int)

Per tutti i g in graphicsg.Draw()

1..*graphicsClient


Esempio di una istanza di composizioni

compositeA: Picture

:Line { leaf } :Rect. { leaf } compositeB: Picture

:Line { leaf }

:Circle { leaf }

la: Line { leaf } lb: Line { leaf } lc: Line { leaf }

compositeC: Picture


Partecipanti

• Component (graphic):– Dichiara l’interfaccia per gli oggetti della

composizione.– Implementa i metodi comuni a tutti i componenti– Dichiara un’interfaccia per l’accesso e la gestione

dei suoi componenti figli.– (Opzionale) definisce un’interfaccia o un metodo per

poter accedere al componente padre


Partecipanti

• Leaf (line, text, circle, ...):– Rappresenta gli oggetti foglia della composizione (oggetti

primitivi).

• Composite (picture):– Definisce il comportamento per i componenti che hanno

figli.– Memorizza i componenti figli

• Client: – Manipola gli oggetti della composizione utilizzando

l’interfaccia Component (Graphics).


Template Method Pattern comportamentale

• Permette che la struttura di un algoritmo non cambi al variare delle implementazioni

• Definisce alcune parti di un algoritmo (parte invariante), e lascia alle sottoclassi il compito di implementare le parti che possono variare


Struttura di un Template Method Pattern

templateMethod()templateMethod()primitiveOp1( ) {abstract}primitiveOp2( ) {abstract}

AbstractClass

ConcreteClass

primitiveOp1()primitiveOp2()

Usa op. astratte

primitiveOp1()primitiveOp2()

...


FrameworkFramework

Esempio Template MethodTemplate Method Pattern

OpenDocument( )OpenDocument( )AddDocument( )DoCreateDocument( ) {abstract}

Application {abstract}

MyApplication

DoCreateDocument()

Save( ) Open( ) Close( ) DoRead( ) {abstract}

Document {abstract}

MyDocumentDoRead()

*

metodo “gancio”da ridefinire


Esempio di codice C++

class Application // abstract{ public: void OpenDocument(const char*); void AddDocument(const char*); virtual Document* DoCreateDocument(const char*) = 0;};

void Application::OpenDocument (const char* name) { Document* doc = DoCreateDocument( name ); if (doc) { doc->Open(); doc->DoRead(); }}


Iterator Patterncomportamentale

detto anche Cursore

• Fornisce un modo per accedere sequenzialmente agli elementi di un aggregato (o oggetto composito), senza esporne la struttura

• Muove la responsabilità per accedere e navigare nell’aggregato, dall’aggregato stesso all’oggetto iteratore


Iterator Pattern: motivazioni

• Si può decidere di attraversare un aggregato in diversi modi

• Si possono avere più iteratori indipendenti sullo stesso aggregato.

• L’aggregato non necessita di modificare la sua interfaccia per permettere vari tipi di attraversamento


Esempio: più oggetti iteratori su lista

FilteringListIterator

First()Next()IsDone(): booleanCurrentItem(): Element

index

list

List

Count() Append(Element) Remove(Element)

…

ListIterator

First()Next()IsDone(): booleanCurrentItem(): Element

index

list


Alcuni problemi con gli iteratori


ConcreteSkipList

CreateIterator()

Struttura di un Iterator Pattern in UMLAbstractList

CreateIterator()

Iterator {abstract}

First()Next()IsDone(): booleanCurrentItem(): element

ConcreteListIteratorConcreteList

CreateIterator()

return new ConcreteListIterator(this)

Client

ConcreteSkipListIterator

{ instantiate }

{ instantiate }

link

link


Struttura di un Iterator Pattern in UML

Aggregate {abstract}

CreateIterator()

ConcreteAggregate

CreateIterator()

Iterator {abstract}

First()Next()IsDone(): booleanCurrentItem(): element

ConcreteIterator

return new ConcreteIterator(this)

Client

{ instantiate }


Partecipanti di un Iterator Pattern

• Iterator (AbstractIterator): definisce una interfaccia per accedere ed navigare tra gli elementi.

• Concrete Iterator: implementa l’interfaccia dell’iteratore e mantiene traccia della posizione corrente durante l’attraversamento

• Aggregate: definisce l’interfaccia per creare l’oggetto iteratore

• Concrete Aggregate: implementa l’interfaccia per la creazione dell’iteratore che restituisce l’appropriato iteratore concreto


Codice C++

class AbstractList // Aggregate{ public: List(); virtual Iterator * CreateIterator() const = 0; long Count() const;

// ......// ........

}; class Iterator // Abstract{ public: virtual void First() = 0; virtual void Next() = 0; virtual bool IsDone() const = 0; virtual Item CurrentItem( ) const = 0;protected: Iterator();};


Codice C++

// Metodo della lista concreta

Iterator * ConcreteList::CreateIterator( ) const { return new ListIterator( this );}

class ListIterator : public Iterator{ public: ListIterator( const List* aList ); virtual void First(); virtual void Next(); virtual bool IsDone() const; virtual Item CurrentItem() const; // ...... private: const List * ptrList; long current;};


Abstract Factory Patterncreazionale

detto anche Kit

Fornisce un’interfaccia per la creazione di famiglie di oggetti correlati o dipendenti senza specificare le rispettive classi concrete


Motivazioni di Abstract Factory Pattern

Talvolta abbiamo sistemi che supportano differenti rappresentazioni dipendenti da fattori esterni.

Questo pattern provvede un’interfaccia per il client, così il client può ottenere uno specifico oggetto attraverso questa interfaccia astratta.

Per esempio:• quando un sistema deve poter essere configurato scegliendo tra più famiglie di prodotti• quando un sistema deve essere indipendente dalla modalità di rappresentazione dei suoi prodotti


Abstract Factory Pattern

AbstractFactory

CreateProductA()CreateProductB()

ConcreteFactory1 ConcreteFactory2 ProductA1 ProductA2

AbstractProductA

Client

ProductB1 ProductB2

AbstractProductB




Esempio di Abstract Factory Pattern

WidgetFactory

CreateScrollBar()CreateWindow()

Create Window() CreateScrollBar()

Create Window() CreateScrollBar()

Motif WidgetFactory PMWidgetFactory PMWindow MotifWindow

Window

Client

PMScrollBar MotifScrollBar

ScrollBar

{ instantiate }

{ instantiate }UNIX GUI

IBM Pres.Man.


Partecipanti di Abstract Factory Pattern

• Abstract Factory ( WidgetFactory ):– Dichiara una interfaccia per le operazioni astratte di creazione di

oggetti prodotto.• Concrete Factory ( MotifWidgetFactory, PMWidgetFactory ):

– Implementa le operazioni di creazione degli oggetti• Abstract Product ( Window, ScrollBar ):

– Dichiara un’interfaccia per un generico prodotto• Concrete Product( PMWindow, PMScrollBar, MotifWidgeWindow, ... ):

– Definisce un oggetto prodotto che dovrà essere creato dalla corrispondente Factory concreta. (Implementa la Abstract Product interface).

• Client: – Usa solo le interfacce (o classi astratte) Abstract Factory e Abstract

Product


Observer Patterncomportamentale

detto anche Dependents, Publish-Subscribe

Definisce una dipendenza uno a molti tra oggetti, in modo tale che se un oggetto cambia il suo stato tutti gli oggetti dipendenti da questo sono aggiornati automaticamente


Observer Pattern

Un effetto collaterale al partizionamento di un sistema in gruppi di classi collaboranti, è il bisogno di mantenere un buon livello di consistenza tra le classi correlate.

La consistenza, però, non deve essere ottenuta a scapito dell’accoppiamento, che deve mantenersi basso, altrimenti la riusabilità viene compromessa

Con l’observer pattern si mantiene un alto livello di disaccoppiamento


Esempio di problema da risolvere con l’Observer Pattern

a b c60

yx

503030

2010

z 801010 a b ca

bc

a = 50%b = 30%c = 20%

notifica di modifica

richieste di modifiche

Interfaccia utenteInterfaccia utente

Struttura datiStruttura dati

Subject


Struttura dell’Observer Pattern

SubjectAttach(Observer)Detach(Observer)

Notify( )Notify( )

ConcreteSubject

subjectState

GetState()SetState()

for all o in observers { o -> Update( ); }

ObserverUpdate( )Update( )

ConcreteObserver

Update( )observerState =subject->GetState()

observerState

return subjectState

1..*

• un soggetto può avere un qualsiasi numero di osservatori dipendenti• tutti gli osservatori sono avvertiti quando il soggetto cambia di stato

Updateinterface

subject


Esempio di Observer Pattern

SubjectAttach(Observer)Detach(Observer)

Notify( )

ClockTimer

time

GetTime( )SetTime( )

Tick( )

for all o in observers { o -> Update( ); }

ObserverUpdate( )

AnalogClock

Call Notify()

1..*

Updateinterface

DigitalClock

Update( )

observerState

Update( )

observerState observerState =subject->GetTime()


Codice C++

class Observer { public: virtual ~ Observer(); virtual void Update( Subject* theChangedSubject ) = 0;protected: Observer( );};

class Subject { public: virtual ~Subject(); virtual void Attach( Observer* ); virtual void Detach( Observer* ); virtual void Notify( );protected: Subject();private: List <Observer*> * listObservers;};


Codice C++

void Subject::Attach (Observer* o) { listObservers->Append(o);}

void Subject::Detach (Observer* o) { listObservers ->Remove(o);}

void Subject::Notify () { ListIterator<Observer*> i ( listObservers );

for (i.First(); ! i.IsDone(); i.Next()) { i.CurrentItem()->Update(this); }

}


Collaborazioni (diag.seq.)

SetState( )

Notify( )

GetState( )

Update( )

Update( )

GetState( )

aConcreteSubject aConcreteObserver anotherConcreteObserver

abc

a b c

a = 50%b = 30%c = 20%


Partecipanti di Observer Pattern• Subject:

– Conosce i suoi numerosi osservatori (observers).– Possiede una interfaccia per aggiungere e togliere “oggetti osservatore”– Invia un “avviso” ai suoi osservatori quando il suo stato cambia.

• Observer: – Definisce una interfaccia per l’aggiornamento per gli osservatori concreti.

• Concrete Subject:– Memorizza lo stato che interessa gli osservatori

• Concrete Observer:– Mantiene una referenza all’oggetto Subject – memorizza lo stato che si mantiene consistente con lo stato del Subject.– Implementa l’interfaccia di notifica.


Bibliografia

Gamma, Erich Richard Helm, Ralph Johnson, John Vlissides (GoF):“Design PatternsDesign Patterns” Reading, Massachusetts: Addison-Wesley. 1995Edizione italiana: Addison-Wesley. Pearson education Italia. 2002

Grady Booch, James Rumbaugh, Ivar Jacobson““The Unified Modeling Language Reference Manual”The Unified Modeling Language Reference Manual” , Addison Wesley, (1999).

Ivar Jacobson, Grady Booch, James Rumbaugh ““The Unified Software Development Process”The Unified Software Development Process”,Addison Wesley, (1999).


Riferimenti nel WebInformazioni varieInformazioni varie: Hillside Patterns Home Page http://hillside.net/patterns

PLoP PLoP (Pattern Languages of Programs Conference)http://jerry.cs.uiuc.edu/~plop/

OOPSLA OOPSLA (Conference On Object-Oriented Programming, Systems, Languages and Applications)(l’indirizzo cambia di anno in anno)www.cis.uab.edu/info/OOPSLA-DSM03/

TutorialTutorialwww.cs.wustl.edu/~schmidt/tutorials-patterns.htmlhttp://st-www.cs.uiuc.edu/users/patterns/patterns.html

OMG UML - OMG UML - UML Reference manual www.www.omgomg.org/.org/umluml//


Riferimenti nel Web

Linda Rising's bookLinda Rising's book The Pattern Almanachttp://www.awlonline.com/product

wikiwikihttp://c2.com/cgi-bin/wiki

PatternPattern Depot Depothttp://www.patterndepot.com/put/8

Open directoryOpen directory http://www.dmoz.org/Computers/Programming/Patterns_and_Anti-Patterns/

Documents

Design Patterns - MathUniPDlocalconte/lezioni/Pattern(1e2).pdf · 2009-01-07 · Descrizione di un Design Pattern (2) Applicability What are the situations in which the design pattern