Transcript Laboratorio di calcolo II

UNIVERSITA’ DEGLI STUDI ROMA TRE
DIPARTIMENTO DI FISICA “E. AMALDI”
laboratorio di calcolo II
AA 2003/04
nona settimana
a cura di
Domizia Orestano
Dipartimento di Fisica
Stanza 159 - tel. (06 5517) 7281
www.fis.uniroma3.it/~orestano
[email protected]
1
Design Patterns
Soluzioni per problemi ricorrenti di disegno del software.
Il testo di riferimento (avanzato!): Design Patterns, Elements of Reusable ObjectOriented Software, di Gamma, Helm,Johnson e Vlissides, edito da Addison-Wesley
Si distinguono 3 tipi di strutture (patterns):
•creazionali (Creational Patterns): factory, singleton ...
•strutturali (Structural Patterns): composite...
•funzionali (Behavioral Patterns): strategy, observer, visitor...
2
Elenco (da www.dofactory.com)
Creational Patterns
Abstract Factory Creates an instance of several families of classes
Builder Separates object construction from its representation
Factory Method
Creates an instance of several derived classes
Prototype
A fully initialized instance to be copied or cloned
Singleton
A class of which only a single instance can exist
3
Elenco (da www.dofactory.com)
Structural Patterns
Adapter Match interfaces of different classes
Bridge
Separates an object’s interface from its implementation
Composite
A tree structure of simple and composite objects
Decorator
Add responsibilities to objects dynamically
Façade A single class that represents an entire subsystem
Flyweight
Proxy
A fine-grained instance used for efficient sharing
An object representing another object
4
Elenco (da www.dofactory.com)
Behavioral Patterns
Chain of Resp.
A way of passing a request between a chain of objects
Command
Encapsulate a command request as an object
Interpreter
A way to include language elements in a program
Iterator Sequentially access the elements of a collection
Mediator Defines simplified communication between classes
Memento
Capture and restore an object's internal state
Observer
A way of notifying change to a number of classes
State
Alter an object's behavior when its state changes
Strategy Encapsulates an algorithm inside a class
Template Method Defer the exact steps of an algorithm to a subclass
Visitor
Defines a new operation to a class without change
5
Factory (method)
Struttura creazionale che consente di disaccoppiare l’utilizzo di un
oggetto dalla sua creazione.
Grazie all’ereditarietà e al polimorfismo un client (ad esempio il
programma main o un altro oggetto) può manipolare un oggetto
derivato dipendendo (e quindi includendo la dichiarazione!) solo
dalla classe base. La dipendenza (e quindi la necessità di includere
l’header file) dalla classe derivata è indispensabile solo per la
costruzione degli oggetti.
Esempio: nel problema del sistema solare il client SistemaSolare
tratta solo dei CorpiCelesti. La classe Sonda è nota solo al main che
costruisce esplicitamente gli oggetti. L’uso di una factory
consentirebbe di spostare la dipendenza da Sonda rendendo anche il
client main dipendente solo dalla classe base e dalla factory.
6
Factory: diagramma UML
Client
main
Factory
AbstractProduct
createProduct1 () : AbstractProduct
creaCorpoCeleste:
CorpoCeleste
createProduct2 () : AbstractProduct
creaSonda: CorpoCeleste
creaSatellite: CorpoCeleste
corpoCeleste
ConcreteProduct1
Sonda
Di solito è una
classe astratta
ConcreteProduct2
Satellite
7
Singleton
Struttura creazionale che consente di assicurarsi che di una classe
esista un’unica istanza (un unico oggetto) e che ne fornisce un
accesso globale (da qualsiasi blocco del programma).
Serve per realizzare una struttura dati visibile da tutto il programma
e garantirne l’unicità.
Si realizza rendendo privato il costruttore della classe Singleton,
mantenendo tra gli attributi un puntatore all’oggetto stesso e
fornendo un metodo pubblico che costruisca l’oggetto qualora
questo ancora non esista e ne restituisca sempre il puntatore.
L’attributo puntatore e il metodo che lo restituisce devono essere
dichiarati static per garantire l’accesso globale ad un puntatore
che deve assumere sempre lo stesso valore.
8
Singleton: diagramma UML
Singleton
_instance : Singleton
instance () : Singleton
specificService ()
if (_instance==0)
_instance = new Singleton();
return _instance;
user_code()
{
Singleton::instance()->specificService(...);
}
9
Composite
Permette di descrivere oggetti organizzati gerarchicamente in
strutture ad albero trattando in modo uniforme oggetti singoli e
composti attraverso un’unica interfaccia. La composizione può essere
ricorsiva.
10
Esempio: esperimento ARGO-YBJ
L’implementazione
mediante una catena
di aggregazioni porterebbe
a duplicazioni di codice
e sarebbe inefficiente
11
Composite: diagramma UML
Client
Component
operation( )
1..*
_children
Composite
operation( )
Leaf
operation( )
for c in all _children
c->operation();
12
Composite:
diagramma UML
di ARGO-YBJ
13
Esempio: calcolo della potenza
dissipata in un rack di moduli di
elettronica
14
15
Uso di
Composite
16
class DaqComposite; // forward declaration
class DaqComponent {
public:
DaqComponent() : parent_(0) {}
virtual float power() const=0
protected:
DaqComposite * parent_;
};
DaqComponent.h
#include “DaqComponent.h”
class DaqLeaf: public DaqComponent {
public:
DaqLeaf(float ip=0): power_(ip) {}
DaqLeaf.h
float power() const { return power_;}
protected:
float power_;
};
17
#include “DaqComponent.h”
class DaqComposite : public DaqComponent {
public:
typedef vector<DaqComponent *> VC;
typedef VC::const_iterator CIter;
DaqComposite(){}
float power() const {
tp =0;
CIter p=components.begin();
CIter pe=components.end();
while (p!=pe) {tp+=(*p)->power(); ++p;}
return tp;
}
protected:
VC components;
};
DaqComposite.h
18
Strategy
Consente di prevedere l’uso di diversi algoritmi concreti,
alternativi tra loro, facendo dipendere il client solo da una classe
algoritmica astratta.
L’algoritmo da eseguire può essere scelto a run-time e si possono
introdurre nuovi algoritmi senza modificare il client.
19
Strategy: diagramma UML
{
...
Strategy* s;
s->doAlgorithm();
...
}
Strategy
Client
doAlgorithm( )
ConcreteStrategyA
doAlgorithm( )
ConcreteStrategyB
doAlgorithm( )
ConcreteStrategyC
doAlgorithm( )
20
Observer
Definisce una relazione tra oggetti che consente di notificare la
variazione dello stato di un oggetto a tutti gli altri in modo
automatico.
Si usa quando due oggetti devono evolvere in modo correlato,
quando non si sappia quanti oggetti devono essere modificati in
seguito alla variazione di stato di un oggetto o quando non si
vogliano introdurre vincoli stretti tra di essi.
Lo stato dell’Observer dipende dallo stato del Subject. Il Subject
notifica a tutti gli Observer registrati che il suo stato è cambiato.
Ogni Observer si aggiorna in maniera che dipende
dall’implementazione concreta.
21
Observer: diagramma UML
Observer
Subject
_observers
update( )
_observers : Observer
attach (Observer)
notify ()
0..*
for all o in _
observables
o->update();
ConcreteObserver
ConcreteSubject
_status : Status
_subject
_status : Status
_subject . ConcreteSubject
update( )
status( )
return _status;
_status =
_subject->status();
22
Visitor
Permette di aggiungere funzionalità ad una classe senza modificarne
la struttura.
Si usa quando si hanno delle classi che definiscono la struttura degli
oggetti la cui interfaccia deve essere “congelata” e si vuole
mantenere la possibilità di aggiungervi dei metodi, quando tali
metodi servono solo nell’ambito di alcune applicazioni e non si
vuole quindi appesantire la struttura nelle altre, quando le operazioni
da compiere nelle diverse classi concrete sono differenti.
L’oggetto visitato ha un metodo che, ricevendo il puntatore di un
visitor, invoca un metodo del visitor passandogli il puntatore a se
stesso e rendendo quindi tale metodo equivalente ad un membro
23
della classe.
Visitor: diagramma UML
Client
Visitor
visit1 (ConcreteElement1)
visit2 (ConcreteElement2)
Element
accept (Visitor)
ConcreteElement1
ConcreteVisitor1
ConcreteVisitor2
visit1 (ConcreteElement1)
visit2 (ConcreteElement2)
visit1 (ConcreteElement1)
visit2 (ConcreteElement2)
ConcreteElement2
accept (Visitor v)
accept (Visitor v)
v->visit1(this)
v->visit2(this)
24