Sei sulla pagina 1di 17

Pattern?

Universit di Padova
Facolt di Scienze MM.FF.NN

Nel gioco degli scacchi per essere:

Informatica - anno 2008-09


Corso di Ingegneria del Software

Design Patterns
Questa presentazione prende spunto dal testo
Design Patterns
della banda dei quattro*

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 pattern nascosti, memorizzarli e applicarli
finch diventano una seconda natura.
( da uno scritto di R.G.Martin, liberamente adattato )

*(vedi bibliografia alla fine delle presentazioni)


Renato Conte - Design patterns - 1 / 67 -

Renato Conte - Design patterns - 2 / 67 -

Pattern e Framework

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.

Renato Conte - Design patterns - 3 / 67 -

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 dellarchitettura e della progettazione
software
Un framework un insieme integrato di componenti che forniscono lo
scheletro di unapplicazione 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,
lestensibilit, la modularit, le prestazioni
Renato Conte - Design patterns - 4 / 67 -

Come diventare un Master Designer

Storia dei pattern

Primo - imparare le regole:


Algoritmi
Strutture dati
Linguaggi (di programmazione e di progettazione)

77 - Il lavoro dellarchitetto Christopher Alexander

In seguito - conoscere i principi della programmazione e dellanalisi:


Programmazione strutturata
OO P
OOA OOD

92 - Pubblicazione di Coad sui pattern

80 - Kent Beck e i primi pattern in Smalltalk


91 - Tesi di dottorato di Gamma su ET++

Infine - studiare i progetti e le soluzioni degli esperti:


I Design pattern devono essere compresi, memorizzati ed applicati

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)

Esistono migliaia di pattern


Renato Conte - Design patterns - 5 / 67 -

Classificazione dei pattern del GoF

... e molto altro ...


Renato Conte - Design patterns - 6 / 67 -

Tipi di Design Pattern

Scopo
Creazionali

Class

Strutturali

Comportamentali

Factory Method

Adapter (class)

Interpreter
Template Method

Abstract Factory
Builder
Prototype
Singleton

Adapter (object)
Bridge
Composite
Decorator
Facade
Flyweight
Proxy

Chain of Responsibility

Scope

Object

Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor

Renato Conte - Design patterns - 7 / 67 -

Creazionale (Creational patterns)


Tratta largomento della configurazione ed
inizializzazione di classi ed oggetti
Strutturale (Structural patterns)
Tratta largomento del disaccoppiamento tra interfacce
ed implementazione delle classi e degli oggetti e della loro
composizione
Comportamentale (Behavioral patterns)
Tratta largomento delle interazioni dinamiche tra
gruppi di classi ed oggetti
Renato Conte - Design patterns - 8 / 67 -

Pattern Creazionali: aspetti progettuali coinvolti


(1) Factory Method
creazioni istanze di sottoclassi

(3) Builder
creazione incrementale di oggetti complessi
(4) Prototype
clonazione di nuove istanze da prototipo

(7) Bridge
disaccoppiamento astrazione / implementazione
(8) Composite
strutture per costruire aggregazioni di oggetti
(9) Decorator
estensione delle funzionalit di un oggetto in modo trasparente

Renato Conte - Design patterns - 9 / 67 -

Pattern Strutturali: aspetti progettuali coinvolti

(1)

(6) Adapter
adattamento interfaccia

(2) Abstract Factory


famiglie di oggetti

(5) Singleton
unica istanza

Pattern Strutturali: aspetti progettuali coinvolti

Renato Conte - Design patterns - 10 / 67 -

Pattern Comportamentali: aspetti progettuali coinvolti

(1)

(2)

(10) Faade
semplifica linterfaccia ad un sottosistema

(11) Flyweight
condivisione per gestire numerosi oggetti

(12) Proxy
un oggetto approssima un altro
Renato Conte - Design patterns - 11 / 67 -

(13) Interpreter
interprete di un linguaggio per semplici grammatiche

(14) Template 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
Renato Conte - Design patterns - 12 / 67 -

Pattern Comportamentali: aspetti progettuali coinvolti

(2)

Pattern Comportamentali: aspetti progettuali coinvolti


(3)

(17) Iterator
per laccesso 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) Observer
aggiornamenti automatici su oggetti dipendenti da un altro oggetto
Renato Conte - Design patterns - 13 / 67 -

Descrizione di un Design Pattern (1)


tratto da: http://hillside.net/patterns/writing/GOFtemplate.htm
(trad.1.3)

(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
Renato Conte - Design patterns - 14 / 67 -

Descrizione di un Design Pattern (2)

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.

Applicability
What 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?

Intent
A 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?

Structure & Participants


The classes and/or objects participating in the design pattern and their
responsibilities.
Collaborations
How the participants collaborate to carry out their responsibilities.

Also Known As
Other well-known names for the pattern, if any.
Motivation
A 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.
Renato Conte - Design patterns - 15 / 67 -

Consequences
How 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?
Renato Conte - Design patterns - 16 / 67 -

Descrizione di un Design Pattern (3)


Implementation
What pitfalls, hints, or techniques should you be aware of when
implementing the pattern? Are there language-specific issues?
Sample Code and Usage
Code fragments that illustrate how you might implement the pattern in
C++ , Smalltalk, Java.
Program Listing

Alcuni esempi di design pattern

Known Uses
Examples of the pattern found in real systems. We include at least two
examples from different domains.
Related Patterns
What design patterns are closely related to this one? What are the
important differences? With which other patterns should this one be
used?
Renato Conte - Design patterns - 17 / 67 -

Facade Pattern

Renato Conte - Design patterns - 18 / 67 -

Faade Pattern: motivazioni dutilizzo

strutturale

(scritto anche Faade)


Fornisce uninterfaccia unificata per un insieme di
interfacce presenti in un sottosistema
Faade definisce una interfaccia a pi alto livello di
astrazione che rende il sottosistema pi semplice da
utilizzare
Renato Conte - Design patterns - 19 / 67 -

Si usa un oggetto Faade per avere una singola e


semplice interfaccia, al posto di pi interfacce
complesse
Minimizza la comunicazione e la dipendenza tra
sottosistemi
Promuove laccoppiamento lasco fra un sottosistema ed
i suoi client.
Renato Conte - Design patterns - 20 / 67 -

Struttura e significato di un Faade Pattern


Client Classes

Esempio applicativo di Faade Pattern

Client Classes

Compiler
Compile()
Scanner

Faade

CodeGenerator

Token

Parser
ProgNodeBuilder

RISCCG
ProgNode

StackMachineCG

Statement Node
Expression Node
Subsystem Classes

Subsystem Classes

Variable Node

Compiler Subsystem Classes


Renato Conte - Design patterns - 21 / 67 -

Renato Conte - Design patterns - 22 / 67 -

Es. codice per Faade

Partecipanti del Faade Pattern


class Compiler
{ public:

Faade (compiler):

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 dellesistenza del Facade;
cio non mantengono alcun riferimento ad esso.

Renato Conte - Design patterns - 23 / 67 -

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);
}
Renato Conte - Design patterns - 24 / 67 -

Stuttura dellAdapter Pattern usando


lereditariet multipla

Adapter Pattern
strutturale
detto anche

Client

Wrapper

Target

Adaptee

Request()

SpecificRequest()

Converte linterfaccia di una classe in unaltra interfaccia


richiesta dal cliente (risolve lincompatibilit
dinterfaccia)
Usato quando vogliamo riutilizzare classi in una
applicazione che prevede luso (riuso) di classi con
differenti interfacce (e noi non vogliamo cambiare le
interfacce delle classi gi esistenti )

Adapter

{implementation}

Request()

Renato Conte - Design patterns - 25 / 67 -

Renato Conte - Design patterns - 26 / 67 -

Esempio dutilizzo dell Adapter Pattern

Stuttura dellAdapter Pattern usando la composizione

Client

Target

Editor

Request()

call SpecificRequest()

Shape

TextView

BoundingBox()
CreateManipulator()

GetExtent()

Adaptee
SpecificRequest()

text

Adapter
Request()

+adaptee
SpecificRequest()

Renato Conte - Design patterns - 27 / 67 -

LineShape

TextShape

BoundingBox()
CreateManipulator()

CreateManipulator()

BoundingBox()

return text -> GetExtent()


return new Text Manipulator

Renato Conte - Design patterns - 28 / 67 -

Partecipanti dellAdapter Pattern


Target ( Shape ): Definisce linterfaccia specifica del dominio
utilizzata dal client
Client ( DrawingEditor ): collabora con oggetti compatibili con
linterfaccia Target.
Adaptee ( TextView ): individua uninterfaccia esistente che
deve essere adattata
Adapter ( TextShape ): adatta linterfaccia di Adaptee
allinterfaccia 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;
};

Renato Conte - Design patterns - 29 / 67 -

Renato Conte - Design patterns - 30 / 67 -

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;
};
Renato Conte - Design patterns - 31 / 67 -

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.

Renato Conte - Design patterns - 32 / 67 -

Struttura di Composite Pattern in UML

Esempio di un Composite Pattern

Alternativa

0..*
Component

Client

{abstract}

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

children

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

Operation()

Draw()
Add(Graphic)
Remove(Graphic)
GetChild(int)

Alternativa...

1..*

Composite

Leaf

Graphic

Client

Line

Rect.

Text

Draw()

Draw()

Draw()

1..*
graphics

Picture
Draw()
Add(Graphic)
Remove(Graphic)
GetChild(int)

Per tutti i g in Component


g.Operation()

Per tutti i g in graphics


g.Draw()

Renato Conte - Design patterns - 33 / 67 -

Renato Conte - Design patterns - 34 / 67 -

Esempio di una istanza di composizioni


Partecipanti
compositeA: Picture

Component (graphic):
Dichiara linterfaccia per gli oggetti della
composizione.

:Line

{ leaf }

Implementa i metodi comuni a tutti i componenti

compositeB: Picture

:Rect. { leaf }

Dichiara uninterfaccia per laccesso e la gestione


dei suoi componenti figli.

:Circle { leaf }
compositeC: Picture
:Line
la: Line

{ leaf }

lb: Line

{ leaf }

lc: Line

{ leaf }

(Opzionale) definisce uninterfaccia o un metodo per


poter accedere al componente padre

{ leaf }

Renato Conte - Design patterns - 35 / 67 -

Renato Conte - Design patterns - 36 / 67 -

Partecipanti

Template Method Pattern

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
linterfaccia Component (Graphics).

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

Renato Conte - Design patterns - 37 / 67 -

Renato Conte - Design patterns - 38 / 67 -

Esempio Template Method Pattern


Struttura di un Template Method Pattern
AbstractClass
templateMethod()
primitiveOp1( ) {abstract}
primitiveOp2( ) {abstract}

Framework

Usa op. astratte

Application {abstract}

primitiveOp1()
primitiveOp2()

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

...

Document {abstract}
*

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

metodo gancio
da ridefinire

MyApplication

ConcreteClass
primitiveOp1()
primitiveOp2()

DoCreateDocument()

Renato Conte - Design patterns - 39 / 67 -

MyDocument
DoRead()

Renato Conte - Design patterns - 40 / 67 -

Esempio di codice C++

Iterator Pattern

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();
}
}

comportamentale

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
nellaggregato, dallaggregato stesso alloggetto
iteratore

Renato Conte - Design patterns - 41 / 67 -

Iterator Pattern: motivazioni

Renato Conte - Design patterns - 42 / 67 -

Esempio: pi oggetti iteratori su lista


list
FilteringListIterator

Si pu decidere di attraversare un aggregato in


diversi modi

List

Si possono avere pi iteratori indipendenti sullo


stesso aggregato.

Count()
Append(Element)
Remove(Element)

Laggregato non necessita di modificare la sua


interfaccia per permettere vari tipi di
attraversamento
Renato Conte - Design patterns - 43 / 67 -

index
list

First()
ListIterator
Next()
IsDone(): boolean
index
CurrentItem(): Element
First()
Next()
IsDone(): boolean
CurrentItem(): Element

Renato Conte - Design patterns - 44 / 67 -

Struttura di un Iterator Pattern in UML

Alcuni problemi con gli iteratori

AbstractList

Iterator

CreateIterator()

{abstract}

First()
Next()
IsDone(): boolean
CurrentItem(): element

Client
{ instantiate }
ConcreteList
link

CreateIterator()

ConcreteListIterator

return new ConcreteListIterator(this)

Renato Conte - Design patterns - 45 / 67 -

Struttura di un Iterator Pattern in UML

Aggregate

Iterator

{abstract}

CreateIterator()

Client

ConcreteAggregate

{ instantiate }

CreateIterator()

link

ConcreteSkipListIterator

Renato Conte - Design patterns - 46 / 67 -

Partecipanti di un Iterator Pattern

{abstract}

First()
Next()
IsDone(): boolean
CurrentItem(): element

{ instantiate }

CreateIterator()

ConcreteSkipList

ConcreteIterator

Iterator (AbstractIterator): definisce una interfaccia


per accedere ed navigare tra gli elementi.
Concrete Iterator: implementa linterfaccia
delliteratore e mantiene traccia della posizione corrente
durante lattraversamento
Aggregate: definisce linterfaccia per creare loggetto
iteratore
Concrete Aggregate: implementa linterfaccia per la
creazione delliteratore che restituisce lappropriato
iteratore concreto

return new ConcreteIterator(this)


Renato Conte - Design patterns - 47 / 67 -

Renato Conte - Design patterns - 48 / 67 -

Codice C++

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();
};
Renato Conte - Design patterns - 49 / 67 -

// 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;
};
Renato Conte - Design patterns - 50 / 67 -

Motivazioni di Abstract Factory Pattern

Abstract Factory Pattern


creazionale

detto anche Kit


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

Renato Conte - Design patterns - 51 / 67 -

Talvolta abbiamo sistemi che supportano differenti


rappresentazioni dipendenti da fattori esterni.
Questo pattern provvede uninterfaccia 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

Renato Conte - Design patterns - 52 / 67 -

Esempio di Abstract Factory Pattern

Abstract Factory Pattern

Client

WidgetFactory

AbstractFactory

Client

CreateScrollBar()
CreateWindow()
Window

CreateProductA()
CreateProductB()
AbstractProductA

ConcreteFactory1

ConcreteFactory2

CreateProductA()
CreateProductB()

CreateProductA()
CreateProductB()

ProductA1

ProductA2

Motif WidgetFactory

PMWidgetFactory

Create Window()
CreateScrollBar()

Create Window()
CreateScrollBar()

PMWindow

MotifWindow

ScrollBar
AbstractProductB

IBM Pres.Man.
UNIX GUI

{ instantiate }
PMScrollBar
ProductB1

MotifScrollBar

ProductB2

{ instantiate }
Renato Conte - Design patterns - 53 / 67 -

Renato Conte - Design patterns - 54 / 67 -

Partecipanti di Abstract Factory Pattern

Abstract Factory ( WidgetFactory ):


Dichiara una interfaccia per le operazioni astratte di creazione di
oggetti prodotto.

Concrete Factory ( MotifWidgetFactory, PMWidgetFactory ):

Abstract Product ( Window, ScrollBar ):

Implementa le operazioni di creazione degli oggetti


Dichiara uninterfaccia 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

Renato Conte - Design patterns - 55 / 67 -

Observer Pattern
comportamentale

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

Renato Conte - Design patterns - 56 / 67 -

Esempio di problema da risolvere con lObserver Pattern

Observer Pattern

Interfaccia utente
a b c
x 6030 10
y 503020
z 8010 10

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 dellaccoppiamento, che deve mantenersi
basso, altrimenti la riusabilit viene compromessa

Struttura dati

Con lobserver pattern si mantiene un alto livello di


disaccoppiamento

notifica di modifica
a = 50%
b = 30%
c = 20%

Subject

Renato Conte - Design patterns - 57 / 67 -

richieste di modifiche

Renato Conte - Design patterns - 58 / 67 -

Struttura dellObserver Pattern

Esempio di Observer Pattern

un soggetto pu avere un qualsiasi numero di osservatori dipendenti


tutti gli osservatori sono avvertiti quando il soggetto cambia di stato

Subject

1..*

Attach(Observer)
Detach(Observer)
Notify( )

Observer
Update( )

Update
interface

Subject

1..*

Observer

Attach(Observer)
Detach(Observer)
Notify( )

Update
interface

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

for all o in observers


{ o -> Update( ); }

AnalogClock
observerState =
subject->GetState()

Update( )
subject
ConcreteSubject
GetState()
SetState()

observerState =
subject->GetTime()

observerState

ConcreteObserver

observerState

ClockTimer

GetTime( )
SetTime( )
Tick( )

return subjectState

Update( )

time

DigitalClock
Call Notify()

observerState
Update( )

subjectState

Renato Conte - Design patterns - 59 / 67 -

Renato Conte - Design patterns - 60 / 67 -

Codice C++

Codice C++

class Observer

void Subject::Attach (Observer* o)


{
listObservers->Append(o);
}

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

void Subject::Detach (Observer* o)


{
listObservers ->Remove(o);
}

protected:
Observer( );

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

};

void Subject::Notify ()
{
ListIterator<Observer*> i ( listObservers );
for (i.First(); ! i.IsDone(); i.Next())
{ i.CurrentItem()->Update(this);

Renato Conte - Design patterns - 61 / 67 -

Collaborazioni

Renato Conte - Design patterns - 62 / 67 -

(diag.seq.)

Partecipanti di Observer Pattern

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

aConcreteSubject

aConcreteObserver

Subject:
Conosce i suoi numerosi osservatori (observers).

anotherConcreteObserver

Possiede una interfaccia per aggiungere e togliere oggetti osservatore

SetState( )

Invia un avviso ai suoi osservatori quando il suo stato cambia.

Observer:
Definisce una interfaccia per laggiornamento per gli osservatori concreti.

Notify( )

Concrete Subject:
Memorizza lo stato che interessa gli osservatori

Update( )

GetState( )

Concrete Observer:
Mantiene una referenza alloggetto Subject
memorizza lo stato che si mantiene consistente con lo stato del Subject.
Implementa linterfaccia di notifica.

Update( )
GetState( )

Renato Conte - Design patterns - 63 / 67 -

Renato Conte - Design patterns - 64 / 67 -

Riferimenti nel Web

Bibliografia

Informazioni varie:
varie Hillside Patterns Home Page
http://hillside.net/patterns

Gamma, Erich Richard Helm, Ralph Johnson, John Vlissides (GoF):


Design Patterns Reading, Massachusetts: Addison-Wesley. 1995
Edizione italiana: Addison-Wesley. Pearson education Italia. 2002

Grady Booch, James Rumbaugh, Ivar Jacobson


The Unified Modeling Language Reference Manual ,
Addison Wesley, (1999).
Ivar Jacobson, Grady Booch, James Rumbaugh
The Unified Software Development Process,
Process
Addison Wesley, (1999).
Renato Conte - Design patterns - 65 / 67 -

Riferimenti nel Web


Linda Rising's book The Pattern Almanac
http://www.awlonline.com/product
wiki
http://c2.com/cgi-bin/wiki
Pattern Depot
http://www.patterndepot.com/put/8
Open directory
http://www.dmoz.org/Computers/Programming
/Patterns_and_Anti-Patterns/

Renato Conte - Design patterns - 67 / 67 -

PLoP (Pattern Languages of Programs Conference)


http://jerry.cs.uiuc.edu/~plop/
OOPSLA (Conference On Object-Oriented Programming, Systems,
Languages and Applications)
(lindirizzo cambia di anno in anno)
www.cis.uab.edu/info/OOPSLA-DSM03/
Tutorial
www.cs.wustl.edu/~schmidt/tutorials-patterns.html
http://st-www.cs.uiuc.edu/users/patterns/patterns.html
OMG UML - UML Reference manual
www.omg.org/uml/
Renato Conte - Design patterns - 66 / 67 -