1 laboratorio di calcolo II AA 2003/04 nona settimana a cura di Domizia Orestano Dipartimento di Fisica Stanza tel. ( ) UNIVERSITA DEGLI STUDI ROMA TRE DIPARTIMENTO DI FISICA E. AMALDI

2 Design Patterns Il testo di riferimento (avanzato!): Design Patterns, Elements of Reusable Object- Oriented Software, di Gamma, Helm,Johnson e Vlissides, edito da Addison-Wesley Soluzioni per problemi ricorrenti di disegno del software. Si distinguono 3 tipi di strutture (patterns): creazionali (Creational Patterns): factory, singleton... strutturali (Structural Patterns): composite... funzionali (Behavioral Patterns): strategy, observer, visitor...

3 Elenco (da Creational Patterns Abstract FactoryCreates an instance of several families of classes BuilderSeparates object construction from its representation Factory MethodCreates an instance of several derived classes PrototypeA fully initialized instance to be copied or cloned SingletonA class of which only a single instance can exist

4 Elenco (da Structural Patterns AdapterMatch interfaces of different classes BridgeSeparates an objects interface from its implementation CompositeA tree structure of simple and composite objects DecoratorAdd responsibilities to objects dynamically FaçadeA single class that represents an entire subsystem FlyweightA fine-grained instance used for efficient sharing ProxyAn object representing another object

5 Elenco (da Behavioral Patterns Chain of Resp.A way of passing a request between a chain of objects CommandEncapsulate a command request as an object InterpreterA way to include language elements in a program IteratorSequentially access the elements of a collection MediatorDefines simplified communication between classes MementoCapture and restore an object's internal state ObserverA way of notifying change to a number of classes StateAlter an object's behavior when its state changes StrategyEncapsulates an algorithm inside a class Template MethodDefer the exact steps of an algorithm to a subclass VisitorDefines a new operation to a class without change

6 Factory (method) Struttura creazionale che consente di disaccoppiare lutilizzo di un oggetto dalla sua creazione. Grazie allereditarietà 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 lheader 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. Luso di una factory consentirebbe di spostare la dipendenza da Sonda rendendo anche il client main dipendente solo dalla classe base e dalla factory.

7 Factory: diagramma UML main creaCorpoCeleste: CorpoCeleste creaSonda: CorpoCeleste creaSatellite: CorpoCeleste corpoCeleste Sonda Satellite Di solito è una classe astratta

8 Singleton Struttura creazionale che consente di assicurarsi che di una classe esista ununica 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 lunicità. Si realizza rendendo privato il costruttore della classe Singleton, mantenendo tra gli attributi un puntatore alloggetto stesso e fornendo un metodo pubblico che costruisca loggetto qualora questo ancora non esista e ne restituisca sempre il puntatore. Lattributo puntatore e il metodo che lo restituisce devono essere dichiarati static per garantire laccesso globale ad un puntatore che deve assumere sempre lo stesso valore.

9 Singleton: diagramma UML user_code() { Singleton::instance()->specificService(...); } user_code() { Singleton::instance()->specificService(...); }

10 Composite Permette di descrivere oggetti organizzati gerarchicamente in strutture ad albero trattando in modo uniforme oggetti singoli e composti attraverso ununica interfaccia. La composizione può essere ricorsiva.

11 Esempio: esperimento ARGO-YBJ Limplementazione mediante una catena di aggregazioni porterebbe a duplicazioni di codice e sarebbe inefficiente

12 Composite: diagramma UML

13 Composite: diagramma UML di ARGO-YBJ

14 Esempio: calcolo della potenza dissipata in un rack di moduli di elettronica

15

16 Uso di Composite

17 class DaqComposite; // forward declaration class DaqComponent { public: DaqComponent() : parent_(0) {} virtual float power() const=0 protected: DaqComposite * parent_; }; #include DaqComponent.h class DaqLeaf: public DaqComponent { public: DaqLeaf(float ip=0): power_(ip) {} float power() const { return power_;} protected: float power_; }; DaqComponent.h DaqLeaf.h

18 #include DaqComponent.h class DaqComposite : public DaqComponent { public: typedef vector 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

19 Strategy Consente di prevedere luso di diversi algoritmi concreti, alternativi tra loro, facendo dipendere il client solo da una classe algoritmica astratta. Lalgoritmo da eseguire può essere scelto a run-time e si possono introdurre nuovi algoritmi senza modificare il client.

20 Strategy: diagramma UML

21 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 dellObserver 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 dallimplementazione concreta.

22 Observer: diagramma UML

23 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 nellambito di alcune applicazioni e non si vuole quindi appesantire la struttura nelle altre, quando le operazioni da compiere nelle diverse classi concrete sono differenti. Loggetto 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 della classe.

24 Visitor: diagramma UML