Design Pattern Comportamentali

Transcript

1 Design Pattern Comportamentali Focalizzano sul controllo del flusso tra oggetti Descrivono le comunicazioni tra oggetti Aiutano a valutare le responsabilità assegnate agli oggetti Suggeriscono modi per incapsulare algoritmi dentro classi Intento Definisce un oggetto che incapsula come un gruppo di oggetti interagisce Promuove lasco accoppiamento fra oggetti, poiché permette ad essi di non interagire direttamente Motivazione La distribuzione di responsabilità fra vari oggetti può risultare in molte connessioni fra oggetti Molte connessioni rendono un oggetto dipendente da altri e l intero sistema si comporta come se fosse monolitico Diminuire le dipendenze di una classe e renderla più generale Prof. E. Tramontana - Design Pattern - 7-Giu-10! 1! Prof. E. Tramontana - Design Pattern - 7-Giu-10! 2! Per la finestra di ricerca mostrata Ogni elemento visualizzato (testo, lista, bottone) è controllato da una corrispondente classe Ciascuna classe deve comunicare il suo stato alle altre per far aggiornare la visualizzazione Ciascuna classe (senza l uso del ) dovrà invocare i metodi di tutte le altre classi, e quindi ciascuna classe dipendente dalle altre Soluzione Isolare le comunicazioni (complesse) tra oggetti dipendenti creando una classe separata per esse definisce una interfaccia tra oggetti che comunicano Concrete implementa il comportamento cooperativo e coordina Colleague Colleague definisce un interfaccia per oggetti che devono comunicare ConcreteColleague conoscono il e comunicano con il quando avrebbero comunicato con altri ConcreteColleague <<interface>> <<interface>> Colleague Prof. E. Tramontana - Design Pattern - 7-Giu-10! 3! Concrete ConcreteColleague1 ConcreteColleague2 Prof. E. Tramontana - Design Pattern - 7-Giu-10! 4!

2 Conseguenze La maggior parte della complessità che risulta nella gestione delle dipendenze è spostata dagli oggetti cooperanti al. Questo rende gli oggetti più facili da implementare e mantenere Le classi Colleague sono più riusabili poiché la loro funzionalità fondamentale non è mischiata con il codice che gestisce le dipendenze Il codice del non è in genere riusabile poiché la gestione delle dipendenze implementata è solo per una specifica applicazione Prof. E. Tramontana - Design Pattern - 7-Giu-10! 5! // classe che implementa un Concrete public class WindowFind implements { // istanze di vari Colleague private TextButton fine = new TextButton("OK"); private TextButton canc = new TextButton("Cancel"); private TextBox searcher = new TextBox(); private ListBox categ = new ListBox(categs, 2); // metodo che attiva i controlli public void selectcateg(string s) { if (s.compareto(categs[0]) == 0) { subcateg.activate(); fine.deactivate(); categ.... public void init() { fine.deactivate(); canc.activate(); searcher. categ.deactivate(); public interface { // metodo che i Colleague possono invocare public void selectcateg(string s); // classe che implementa un ConcreteColleague public class TextButton extends Colleague { private String nome; private boolean active = false; public void activate() { active = true; public void deactivate() { active = false; public void show() { if (active) console.bold(); else console.normal(); console.print(x, y, nome); Prof. E. Tramontana - Design Pattern - 7-Giu-10! 6! State // classe che implementa un ConcreteColleague public class TextBox extends Colleague { private String content; private boolean active = false; public void activate() { active = true; public void deactivate() { active = false; public void show() { console.normal(); console.print(4, 1, content); public String takeinput() { mediator.selectcateg( console.takeinput()); // TextBox avvisa Concrete public class Colleague { protected mediator; public get() { return mediator; public void set( m) { mediator = m; Prof. E. Tramontana - Design Pattern - 7-Giu-10! 7! Intento Permette ad un oggetto di alterare il suo comportamento quando il suo stato cambia e sembra che l oggetto abbia cambiato la sua classe Applicabilità Il comportamento di un oggetto dipende dal suo stato e il comportamento cambia a run-time in dipendenza del suo stato Le operazioni da svolgere hanno rami condizionali e frammenti di codice che dipendono dallo stato Lo stato è spesso rappresentato dal valore di una variabile La soluzione inserisce ciascun ramo condizionale in una classe separata Prof. E. Tramontana - Design Pattern - 7-Giu-10! 8!

3 State Soluzione Inserire ogni ramo condizionale in una classe separata Context costituisce l interfaccia per i client, e mantiene un istanza di un ConcreteState che definisce lo stato corrente State definisce un interfaccia che incapsula il comportamento associato con un particolare stato ConcreteState implementa il comportamento associato con uno stato Conseguenze State Il comportamento associato ad uno stato è in una sola classe (ConcreteState) La logica che gestisce il cambiamento di stato è separata dai vari comportamenti ed è in una sola classe (Context), anziché (con istruzioni if o switch) sulla classe che implementa i comportamenti La separazione suddetta aiuta ad evitare stati inconsistenti poiché i cambiamenti di stato vengono decisi da una sola classe e non da tante Il numero di classi totale è maggiore, le classi sono più semplici Prof. E. Tramontana - Design Pattern - 7-Giu-10! 9! Prof. E. Tramontana - Design Pattern - 7-Giu-10! 10! State // TestOrologio e un Client public class TestOrologio { public static void main(string[] args) { Orario o = new Orario(); o.intodigital(); o.oraattuale(); // Orario ha il ruolo di Context public class Orario { private Orologio o; public void oraattuale() { o.displaytime(); public void intodigital() { o = new Digitale() public void intoanalog() { o = new Analogico() // Orologio definisce l'interfaccia State public interface Orologio { public void displaytime(); // Digitale ha il ruolo di un ConcreteState public class Digitale implements Orologio { public void displaytime() { Date d = Calendar.getInstance().getTime(); System.out.print( DateFormat.getDateTimeInstance().format(d)); Intento Aggiungere responsabilità ad un oggetto dinamicamente. Fornire un alternativa flessibile all implementazione di sottoclassi per estendere funzionalità Motivazione Si vogliono aggiungere responsabilità ad un oggetto, non all intera classe L aggiunta di resp. è trasparente, ovvero i client non devono cambiare Le responsabilità possono essere sottratte dinamicamente I possono essere annidati ricorsivamente, per aggiungere più responsabilità // Analogico ha il ruolo di un ConcreteState public class Analogico implements Orologio { A volte la creazione di sottoclassi non è praticabile. Un numero grande di public void displaytime() { estensioni produrrebbe un numero enorme di sottoclassi per gestire tutte le // implementa un comportamento combinazioni Prof. E. Tramontana - Design Pattern - 7-Giu-10! 11! Prof. E. Tramontana - Design Pattern - 7-Giu-10! 12!

4 Esempio Si vuol aggiungere la proprietà Bordo ad un componente Se si eredita dalla classe Bordo, gli oggetti della sottoclasse avranno questa proprietà, ma non si avrà flessibilità Non posso avere oggetti senza tale proprietà Alternativa flessibile, inserire il componente dentro un oggetto che aggiunge Bordo L oggetto che racchiude, chiamato, manda la richiesta al componente e aggiunge altre attività prima o dopo l invio della richiesta Soluzione Component definisce l interfaccia per gli oggetti che possono avere aggiunte le responsabilità dinamicamente ConcreteComponent definisce un oggetto su cui poter aggiungere responsabilità mantiene un riferimento all oggetto Component e definisce un interfaccia conforme a quella di Component inoltra le richieste al suo oggetto Component e può fare altre operazioni prima e dopo l inoltro della richiesta Concrete implementa la responsabilità aggiunta al ConcreteComponent Prof. E. Tramontana - Design Pattern - 7-Giu-10! 13! Prof. E. Tramontana - Design Pattern - 7-Giu-10! 14! Struttura Esempio Ho alcuni prodotti, ad es. Biglietto, ognuno con un nome ed un costo; ho diversi modi di calcolare il costo di questi prodotti, in base a come uso gli sconti e alle percentuali IVA Voglio poter combinare a runtime sconti diversi sui diversi prodotti Prof. E. Tramontana - Design Pattern - 7-Giu-10! 15! Prof. E. Tramontana - Design Pattern - 7-Giu-10! 16!

5 Esempio Esempio // Biglietto e' un ConcreteComponent public class Biglietto implements Prodotto { public void printname() { System.out.print("Biglietto n "); return 100.0; // Tariffe e' un, // contiene l istanza dell'oggetto annidato ed // invoca operazioni sull'oggetto annidato public abstract class Tariffe implements Prodotto { private Prodotto mycomp; public Tariffe(Prodotto myc) { mycomp = myc; public void printname() { mycomp.printname(); return mycomp.getcost(); // Prodotto e' un Component public interface Prodotto { public void printname(); public double getcost(); // Sconto e' un Concrete, // aggiunge funzionalita ad un prodotto public class Sconto extends Tariffe { public Sconto(Prodotto myc) { super(myc); public void printname() { //non chiama l'oggetto annidato System.out.print("Biglietto ridotto"); //chiama getcost sull'oggetto annidato return super.getcost()*0.95; Prof. E. Tramontana - Design Pattern - 7-Giu-10! 17! // Configurazione definisce alcuni metodi factory public class Configurazione { // getbiglietto restituisce un tipo Prodotto public static Prodotto getbiglietto() { // Iva e un per Biglietto return new Iva(new Biglietto()); public static Prodotto getbigliettoscontato() { // qui ho due annidamenti return new Iva(new Sconto(new Biglietto())); // TestBiglietto e' un client public class TestBiglietto { public static void main(string[] args) { Prodotto prod; prod = Configurazione.getBigliettoScontato(); prod.printname(); System.out.println(" costo: " + prod.getcost()); prod = Configurazione.getBiglietto(); prod.printname(); System.out.println(" costo: " + prod.getcost()); // Iva e' un Concrete public class Iva extends Tariffe { public Iva(Prodotto myc) { super(myc); return super.getcost()*1.2; Prof. E. Tramontana - Design Pattern - 7-Giu-10! 18! Conseguenze Più flessibilità rispetto all ereditarietà poiché si possono aggiungere responsabilità dinamicamente La stessa responsabilità può essere aggiunta più volte, semplicemente aggiungendo due istanze dello stesso Concrete Prevedere per le classi in alto nella gerarchia quali responsabilità servono significherebbe avere per esse troppe responsabilità. I Concrete sono invece indipendenti e definibili successivamente L identità (tipo e riferimento) del Concrete non è quella del ConcreteComponent, quindi non si dovrebbero confrontare i riferimenti Si avranno tanti piccoli oggetti, che differiscono nel modo in cui sono interconnessi Prof. E. Tramontana - Design Pattern - 7-Giu-10! 19! Esempio 1 tratto da JHotDraw Su JHotDraw ritroviamo un implementazione del design pattern L interfaccia Figure è un Component (Figure è implementata da 44 classi) Il metodo draw() è un operazione che viene ridefinita dal Concrete AbstractFigure è una implementazione di Figure La classe Figure è un La classe Border è un Concrete public class Border extends Figure { public Border(Figure figure) { super(figure); /** * Draws a the figure and decorates it with a border. */ public void draw(graphics g) { Rectangle r = displaybox(); super.draw(g); g.setcolor(color.white); g.drawline(r.x, r.y, r.x, r.y + r.height); g.drawline(r.x, r.y, r.x + r.width, r.y); g.setcolor(color.gray); g.drawline(r.x + r.width, r.y, r.x + r.width, r.y + r.height); g.drawline(r.x, r.y + r.height, r.x + r.width, Prof. E. Tramontana r.y + r.height); - Design Pattern - 7-Giu-10! 20!

6 Esempio 2 Su JHotDraw ritroviamo un altra implementazione del L interfaccia Locator è un Component Il metodo locate() è un operazione che viene ridefinita dal Concrete La classe OffsetLocator è un Concrete e un AbstractLocator è una classe astratta che implementa Locator public class OffsetLocator extends AbstractLocator { private Locator fbase; public Point locate(figure owner) { Point p = fbase.locate(owner); p.x += foffsetx; p.y += foffsety; return p;... Prof. E. Tramontana - Design Pattern - 7-Giu-10! 21!