patrons de disseny - udgima.udg.edu/~sellares/einf-es2/present1213/patronsdisseny.pdf · els...

Patrons de disseny

Raquel Garcia

Anna Salvat

21 de març de 2013

Índex

1 Introducció als patrons de disseny 7

1.1 Creacionals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2 Estructurals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.3 Comportament . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.4 Diagrama de relació entre els diferents patrons . . . . . . . . . . 9

2 Patrons creacionals 11

2.1 Factory Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.1.1 Objectiu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.1.2 Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.1.3 Aplicabilitat . . . . . . . . . . . . . . . . . . . . . . . . . 122.1.4 Avantatges i inconvenients . . . . . . . . . . . . . . . . . . 122.1.5 Codi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Abstract Factory . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.1 Objectiu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.2 Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.3 Aplicabilitat . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.4 Avantatges i inconvenients . . . . . . . . . . . . . . . . . . 142.2.5 Codi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3 Singleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3.1 Objectiu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3.2 Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3.3 Aplicabilitat . . . . . . . . . . . . . . . . . . . . . . . . . 162.3.4 Avantatges i inconvenients . . . . . . . . . . . . . . . . . . 162.3.5 Codi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4 Patró Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.4.1 Objectiu: . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.4.2 Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.4.3 Aplicabilitat . . . . . . . . . . . . . . . . . . . . . . . . . 172.4.4 Avantatges i inconvenients . . . . . . . . . . . . . . . . . . 172.4.5 Codi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.5 Patró Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.5.1 Objectiu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.5.2 Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3

4 ÍNDEX

2.5.3 Aplicabilitat . . . . . . . . . . . . . . . . . . . . . . . . . 192.5.4 Avantatges i inconvenients . . . . . . . . . . . . . . . . . . 192.5.5 Codi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Patrons estructurals 21

3.1 Patró Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.1.1 Objectiu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.1.2 Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.1.3 Aplicabilitat . . . . . . . . . . . . . . . . . . . . . . . . . 223.1.4 Avantatges i inconvenients . . . . . . . . . . . . . . . . . . 223.1.5 Codi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2 Patró Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2.1 Objectiu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2.2 Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2.3 Aplicabilitat . . . . . . . . . . . . . . . . . . . . . . . . . 233.2.4 Avantatges i inconvenients . . . . . . . . . . . . . . . . . . 243.2.5 Codi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3 Patró Composite . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.3.1 Objectiu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.3.2 Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.3.3 Aplicabilitat . . . . . . . . . . . . . . . . . . . . . . . . . 263.3.4 Avantatges i inconvenients . . . . . . . . . . . . . . . . . . 263.3.5 Codi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4 Patró Decorator . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.4.1 Objectiu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.4.2 Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.4.3 Aplicabilitat . . . . . . . . . . . . . . . . . . . . . . . . . 283.4.4 Avantatges i inconvenient . . . . . . . . . . . . . . . . . . 293.4.5 Codi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.5 Patró Façade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.5.1 Objectiu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.5.2 Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.5.3 Aplicabilitat . . . . . . . . . . . . . . . . . . . . . . . . . 313.5.4 Avantatges i inconvenients . . . . . . . . . . . . . . . . . . 31

3.6 Patró Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.6.1 Objectiu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.6.2 Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.6.3 Aplicabilitat . . . . . . . . . . . . . . . . . . . . . . . . . 323.6.4 Avantatges i inconvenients . . . . . . . . . . . . . . . . . . 323.6.5 Codi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.7 Patró Flyweight . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.7.1 Objectiu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.7.2 Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.7.3 Aplicabilitat . . . . . . . . . . . . . . . . . . . . . . . . . 343.7.4 Avantatges i inconvenients . . . . . . . . . . . . . . . . . 343.7.5 Codi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

ÍNDEX 5

4 Patrons de comportament 37

4.1 Patró Chain of Responsability . . . . . . . . . . . . . . . . . . . . 374.1.1 Objectiu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.1.2 Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.1.3 Aplicabilitat . . . . . . . . . . . . . . . . . . . . . . . . . 384.1.4 Avantatges i inconvenients . . . . . . . . . . . . . . . . . . 384.1.5 Codi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2 Patró Command . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.2.1 Objectiu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.2.2 Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.2.3 Aplicabilitat . . . . . . . . . . . . . . . . . . . . . . . . . 404.2.4 Avantatges i inconvenients . . . . . . . . . . . . . . . . . . 414.2.5 Codi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.3 Patró Iterator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.3.1 Objectiu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.3.2 Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.3.3 Aplicabilitat . . . . . . . . . . . . . . . . . . . . . . . . . 434.3.4 Avantatges i inconvenients . . . . . . . . . . . . . . . . . . 434.3.5 Codi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.4 Patró Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.4.1 Objectiu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.4.2 Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.4.3 Aplicabilitat . . . . . . . . . . . . . . . . . . . . . . . . . 444.4.4 Avantatges i inconvenients . . . . . . . . . . . . . . . . . . 444.4.5 Codi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.5 Patró Observer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.5.1 Objectiu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.5.2 Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.5.3 Aplicabilitat . . . . . . . . . . . . . . . . . . . . . . . . . 464.5.4 Avantatges i inconvenients . . . . . . . . . . . . . . . . . . 464.5.5 Codi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.6 Patró State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.6.1 Objectiu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.6.2 Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.6.3 Aplicabilitat . . . . . . . . . . . . . . . . . . . . . . . . . 484.6.4 Avantatges i inconvenients . . . . . . . . . . . . . . . . . 484.6.5 Codi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.7 Patró Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.7.1 Objectiu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.7.2 Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.7.3 Aplicabilitat . . . . . . . . . . . . . . . . . . . . . . . . . 514.7.4 Avantatges i inconvenients . . . . . . . . . . . . . . . . . . 514.7.5 Codi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.8 Patró Template . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.8.1 Objectiu . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.8.2 Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6 ÍNDEX

4.8.3 Aplicabilitat . . . . . . . . . . . . . . . . . . . . . . . . . 544.8.4 Avantatges i inconvenients . . . . . . . . . . . . . . . . . . 544.8.5 Codi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.9 Patrò Visitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.9.1 Objectiu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.9.2 Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.9.3 Aplicabilitat . . . . . . . . . . . . . . . . . . . . . . . . . 564.9.4 Avantatges i inconvenients . . . . . . . . . . . . . . . . . . 574.9.5 Codi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.10 Patrò Memento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.10.1 Objectiu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.10.2 Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.10.3 Aplicabilitat . . . . . . . . . . . . . . . . . . . . . . . . . 584.10.4 Avantatges i inconvenients. . . . . . . . . . . . . . . . . . 584.10.5 Codi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.11 Patrò MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.11.1 Objectiu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.11.2 Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.11.3 Aplicabilitat sobre tres patrons esmentats anteriorment . 61

5 Bibliogra�a 63

Capítol 1

Introducció als patrons dedisseny

Els patrons de disseny son la base per a la cerca de solucions a problemes co-muns en el desenvolupament de software i altres àmbits referents al disseny deinteracció o interfícies.

Un patró de disseny és una solució a un problema de disseny. Una solucióes considerada un patró quan aquesta ha de tenir unes certes característiques.Una d`elles es que ha de comprovar la seva efectivitat resolvent problemes simi-lars en ocasions anteriors, una altra és que ha de ser reutilitzable, és a dir, quees pot aplicar a diferents problemes de disseny en diferents circumstàncies.

Objectius principals per utilitzar un patró:

• Evitar la reiteració a la recerca de solucions a problemes ja coneguts isolucionats anteriorment.

• Formalitzar un vocabulari comú entre dissenyadors.

• Estandaritzar el mode en el que es realitza el disseny.

• Es tenen que relacionar entre ells.

Existeixen tres tipus:

1. Creacionals.

2. Estructurals.

3. Comportament.

7

8 CAPÍTOL 1. INTRODUCCIÓ ALS PATRONS DE DISSENY

1.1 Creacionals

Els patrons creacionals abstreuen el procés de creació d`objectes. Fan inde-pendent el sistema de com es creen, composen i representen els objectes que elformen.

Patrons: Abstract Factory, Factory Method, Singleton, Prototype i Builder.

1.2 Estructurals

Tots els patrons estructurals són similars ja que es basen en herència i compo-sició La diferencia entre els patrons estructurals es el seu proposit.

Patrons: Adapter, Bridge, Composite, Decorator, Façade, Proxy i Flyweight.

1.3 Comportament

Els patrons de comportament tenen relació amb els algorismes i amb l`assignacióde responsabilitat. També descriu la comunicació entre objectes.

Patrons: Chain of Responsability, Command, Mediator, Observer, State, Stra-tegy, Template, Visitor, Iterator i Memento.

1.4. DIAGRAMA DE RELACIÓ ENTRE ELS DIFERENTS PATRONS 9

1.4 Diagrama de relació entre els diferents pa-

trons

Figura 1.1: Relació entre els diferents patrons

10 CAPÍTOL 1. INTRODUCCIÓ ALS PATRONS DE DISSENY

Capítol 2

Patrons creacionals

2.1 Factory Method

2.1.1 Objectiu

De�neix una interfície per crear un objecte, però deixa que siguin les subclassesdecideixin quina classe instanciar. Permet que una classe delegui en les sevessubclasses la creació d`objectes.

2.1.2 Diagrama

Figura 2.1: Patró Factory Method

• Product: interfície que de�neix els productes que s`han creat.

• ConcreteProduct: implementa el producte.

• Factory: declara el mètode de fabricació.

• ConcreteFactory: rede�neix el creador per un producte concret.

11

12 CAPÍTOL 2. PATRONS CREACIONALS

2.1.3 Aplicabilitat

Fem servir el patró factory method quan:

1. Una classe no sap quins objectes crearà.

2. Una classe vol que siguin les subclasses qui especi�quin els objectes.

3. Les classes delegen la responsabilitat en les classes auxiliars i volem saberquina classe es la que te la responsabilitat.

2.1.4 Avantatges i inconvenients

1. Els mètodes de fabricació no estan lligats al producte.

2. El factory method permet mes �exibilitat i permet que els objectes espuguin ampliar.

3. Connecta jerarquies de classes

2.1.5 Codi

public interface Product {}public abstract class Creatorpublic void anOperation(){Product product = factoryMethod();}protected abstract Product factoryMethod();}

public class ConcreteProduct implements Product {}public class ConcreteCreator extends Creator{protected Product factoryMethod() {return new ConcreteProduct();}}

public class Client {public static void main( String arg[] ) {Creator creator = new ConcreteCreator();creator.anOperation();}}

2.2. ABSTRACT FACTORY 13

2.2 Abstract Factory

2.2.1 Objectiu

Proporcionar una interfície per crear famílies de objectes relacionats o que de-penen entre si, sense especi�car les classes concretes.

2.2.2 Diagrama

Figura 2.2: Patró Abstract Factory

• AbstractFactory: interfície o classe abstracta que permet crear objectes.

• ConcreteFactory: classe que crea un objecte concret i implementa les ope-racions per crear-lo

• AbstractProduct: interfície o classe abstracta que de�neix part dels ob-jectes.

• Product: de�nició del objecte per a que el factory pugui crear-lo.

2.2.3 Aplicabilitat

Fem servir el abstract factory quan:

1. Un sistema ha de ser independent de com es creen, componen i representenels seus productes.

2. Un sistema es con�gura amb una família de productes.

3. El sistema vol formar una biblioteca de productes i l`ho important es laseva interfície no la implementació.



1. Aïlla les classes contretes. Quan els clients creen objectes o fan mitjançantinstancies, per tant, el client no ha de conèixer lòbjecte.

2. Permet canviar les families dòbjectes, nomes canviant la fabrica concreta.Dàquesta manera es poden treure o agregar families sense proporcionargrans canvis.

3. Promou la consistència dels objectes.

2.2.5 Codi

abstract class AbstractProductA{public abstract void operationA1();public abstract void operationA2();}class ProductA1 extends AbstractProductA{ProductA1(String arg){System.out.println("Hello "+arg);// Implement the codepublic void operationA1() { };public void operationA2() { };}class ProductA2 extends AbstractProductA{ProductA2(String arg){System.out.println("Hello "+arg);// Implement the code public voidoperationA1() {};public void operationA2() { };}abstract class AbstractProductB{//public abstract void operationB1();//public abstract void operationB2();}class ProductB1 extends AbstractProductB{ProductB1(String arg){System.out.println("Hello "+arg);} // Implement the code}class ProductB2 extends AbstractProductB{ProductB2(String arg){System.out.println("Hello "+arg);// Implement the co-de}abstract class AbstractFactory{abstract AbstractProductA createProductA();abstract AbstractProductB createProductB();}class ConcreteFactory1 extends AbstractFactory{AbstractProductA createProductA(){return new ProductA1("ProductA1");}

2.3. SINGLETON 15

AbstractProductB createProductB(){return new ProductB1("ProductB1");}}class ConcreteFactory2 extends AbstractFactory{AbstractProductA createProductA(){return new ProductA2("ProductA2");}AbstractProductB createProductB(){return new ProductB2("ProductB2");}}//Factory creator - an indirect way of instantiating the factoriesclass FactoryMaker{private static AbstractFactory pf=null;static AbstractFactory getFactory(String choice)if(choice.equals("a")){pf=new ConcreteFactory1();else if(choice.equals("b")){pf=new ConcreteFactory2();} return pf;}}// Clientpublic class Client{public static void main(String args[]){AbstractFactory pf=FactoryMaker.getFactory("a");AbstractProductA product=pf.createProductA();//more function calls on product}}

2.3 Singleton

2.3.1 Objectiu

Garanteix que una classe nomes tingui una instancia i proporciona un puntd`accés global a ella.

2.3.2 Diagrama

Figura 2.3: Patró Singleton


2.3.3 Aplicabilitat

Fem servir el patró Singleton quan:

1. Nomes quan tenim una única instancia dùna classe i aquesta ha de seraccessible per el client

2. Aquesta instancia pot tindre una extensió mitjançant herència i els clientshan de ser capaços dùtilitzar la instancia sense modi�car codi.


1. Accés controlat a una única instancia.

2. Millora la gestió de variables globals.

3. Permet modi�car, en temps dèxecució la instancia creant-li extensions

4. Mes �exible que les operacions de classe.

2.3.5 Codi

class Singleton{private static Singleton m_instance;private Singleton(){ ... }public static synchronized Singleton getInstance()if (m_instance == null) m_instance = new Singleton();return m_instance;} ...public void doSomething() ...}

2.4 Patró Prototype

2.4.1 Objectiu:

Especi�ca els objectes que s`han de crear mitjançant una instancia i crea nousobjectes a partir dàquest prototip. Es crea lòbjecte duplicant un existent. Hihan dos maneres de duplicar-ho:

1. Deep. És copia tot, �ns i tot els objectes.

2. Shallow. La referencia al objecte es la mateixa.

2.4. PATRÓ PROTOTYPE 17

2.4.2 Diagrama

• Client: crea un nou objecte mitjan�cant el prototip.

• Prototype: declara una interfície que es clonarà.

• ConcreteProtoype: implementa el prototip que ha de clonar-se.

Figura 2.4: Patró Prototype

2.4.3 Aplicabilitat

Fem servir el patró prototype quan:

1. Les classes que sìnstancien sèspe�quen en temps dèxecució.

2. Per evitar crear una jerarquia de classes de fabriques paral·lela als objectes.

3. Les instàncies son similars i nomes seria un o dos mètodes.


1. El client no ha de conèixer lòbjecte nomes la instància.

2. Es pot ampliar els objectes sense implicar grans canvis.

3. Permet afegir i treure productes en temps dèxeccució

4. Permet crear nous objectes combinant prototips i modi�cant-los �ns aobtenir lòbjecte que volem. Es pot variar valors o estructures.

5. Redueix la herència.

6. Permet con�gurar dinàmicament en temps dèxecucció una classe.


2.4.5 Codi

public interface Prototype {public abstract Object clone ( );}public class ConcretePrototype implements Prototype {public Object clone() {return super.clone();}}public class Client {public static void main( String arg[] ){ConcretePrototype obj1= new ConcretePrototype ();ConcretePrototype obj2 = ConcretePrototype)obj1.clone();}}

2.5 Patró Builder

2.5.1 Objectiu

Separa la construcció d`un objecte complexe de la seva representació, de maneraque el mateix proces de construcció pugui crear diferents representacions.

2.5.2 Diagrama

Figura 2.5: Patró Builder

• Builder: Especi�ca una interfície abstracta per crear les parts d`un objecteproduct.

• ConcreteBuilder: Implementa la interfície Builder per construir i acoblarles parts del producte. De�neix la representació a crear. Proporciona unainterfície per retornar el product.

2.5. PATRÓ BUILDER 19

• Director: construeix un objecte utilitzant lìnterfície Builder.

• Product: Representa lòbjecte a construir. El ConcreteBuilder constru-eix la representació interna del product i de�neix el proces dàcoblament.Inclou las classes que de�neixen les parts que el formen.

2.5.3 Aplicabilitat

Sùtilitza quan:

1. Làlgoritme per crear un objecte hauria de ser independent de les parts deque es component aquest objecte i de com sàcoblen.

2. El procés de construcció ha de permetre diferents representacions de lòbjecteque sèstà construint.


1. Permet variar la representació interna dùn producte

2. Aïlla el codi de construcció i representació.

3. Proporciona un control més exacte sobre el proces de construcció.

2.5.5 Codi

//Abstract Builderclass abstract class TextConverter {abstract void convertCharacter(char c);abstract void convertParagraph();}// Productclass ASCIIText{public void append(char c){ //Implement the code here }}//Concrete Builderclass ASCIIConverter extends TextConverter{ASCIIText asciiTextObj;//resulting product/*converts a character to target representation and appends to the resulting*/object void convertCharacter(char c)char asciiChar = new Character(c).charValue();//gets the ascii characterasciiTextObj.append(asciiChar);}void convertParagraph(){}ASCIIText getResult(){ return asciiTextObj;}}


//This class abstracts the document objectclass Document{static int value;char token;public char getNextToken()//Get the next tokenreturn token;}}//Directorclass RTFReader{private static �nal char EOF=`0`; //Delimitor for End of File�nal char CHAR=`c`;�nal char PARA=`p`;char t;TextConverter builder;RTFReader(TextConverter obj)builder=obj;}void parseRTF(Document doc){while ((t=doc.getNextToken())!= EOF){switch (t){case CHAR: builder.convertCharacter(t);case PARA: builder.convertParagraph();}}}}//Clientpublic class Client{void createASCIIText(Document doc){ASCIIConverter asciiBuilder = new ASCIIConverter();RTFReader rtfReader = new RTFReader(asciiBuilder);rtfReader.parseRTF(doc);ASCIIText asciiText = asciiBuilder.getResult();}

public static void main(String args[]){Client client=new Client();Document doc=new Document();client.createASCIIText(doc);system.out.println("This is an example of Builder Pattern");}}

Capítol 3

Patrons estructurals

3.1 Patró Adapter

3.1.1 Objectiu

Permet que dues classes amb diferents interfícies puguin treballar de maneraconjunta a partir de la creació d`un objecte que les comunicarà. El propòsitdel patró es convertir una interfície ja existent en una altre adequada al client.Mitjan�cant aquest patró es pot reutilitzar codi, en aquest cas la interfície, i peradaptar-la no es necessari que els objectes que treballen amb la interfície siguincompatibles o similars.

Per adaptar es pot fer mitjançant la herència o utilitzant composició. Lainterfície adaptada pot implementar funcions que no te la interfície original.

3.1.2 Diagrama

Figura 3.1: Patró Adapter

• Objectiu: de�neix la interfície que utilitza l`usuari.

21

22 CAPÍTOL 3. PATRONS ESTRUCTURALS

• Adaptable: es la classe ja existent que es vol adaptar a les necessitats delùsuari.

• Adaptador: es la classe adaptada.

3.1.3 Aplicabilitat

Fem servir el patró Adapter quan:

1. Es vol utilitzar una classe i aquesta no concorda amb el tipus de classeque es necessita.

2. Es vol crear una classe que sigui reutilitzable que pugui treballar ambclasses diferents.


1. Permet que lòbjecte �Adaptador� rede�neixi part del comportament delòbjecte �Adaptabla�.

2. Permet que un objecte �Adaptador� pugui treballar amb diferents objectes�Adaptable�.

3. Un �Adaptador� pot de�nir i afegir funcionalitats a diferents �Adaptable�a la vegada.

4. El patró Adapter no funciona quan es vol adaptar tota una jerarquia.

3.1.5 Codi

public interface Objectiu{public abstract void request();}public class Adapter implements Objectiu{private Adaptable delegate;public Adapter() {delegate = new Adaptable();}public void request() {delegate.delegatedRequest();}}public class Adaptable{public void delegatedRequest() {System.out.println("This is the delegated method.");

3.2. PATRÓ BRIDGE 23

}}public class TestAdapter{public static void main(String[] args) {Objectiu client = new Adapter();client.request();}}

3.2 Patró Bridge

3.2.1 Objectiu

Permet desacob lar o separar la abstracció de la implementació de manera quepuguin variar i canviar independentment. Es una bona opció quan una abs-tracció té diverses implementacions. Sùtilitza el patró bridge per tal de poderutilitzar les propietats de la herència i, a la vegada, deslligar la implementaciói la abstracció.

3.2.2 Diagrama

Figura 3.2: Patró Bridge

• Abstracció: de�neix una interfície per a làbstracció.

• Abstracció re�nada: implementa làbstracció.

• Implementador: de�neix una interfície per a la implementació.

• Implementador n: implementa les funcions.

3.2.3 Aplicabilitat

Fem servir el patró Bridge quan:


1. Es vol evitar una relació o enllaç permanent entre la implementació ilàbstracció.

2. Quan es vol estendre la implementació, la abstracció o totes dues de ma-nera independent, sense que els canvis en una afectin a làltre.

3. Quan els canvis a la implementació no ha dàfectar al client.

4. Quan es vol amagar o encapsular la implementació al client.

5. Quan es vol que una mateixa implementació sigui utilitzada per diferentsclients sense que cap client sàdoni del fet.


1. Desacoblar la implementació de làbstracció.

2. Millorar la extensibilitat, ja que permet que tant la implementació comlàbstracció puguin ser modi�cades o ampliades de manera independent.

3. Amagar detalls de implementació als clients.

3.2.5 Codi

public class Abstraccio{private Implementador implementador;public void setImplementor( Implementador implementador ){this.implementador = implementador;}public Implementor getImplementor(){return implementador;}public void operation(){implementador.operation();}}public class AbstraccioRe�nada extends Abstraccio{public void operation(){super.operation();}}public interface Implementador{

3.3. PATRÓ COMPOSITE 25

void operation();}public class Implementador1 implements Implementador{public void operation(){}}public class Test{public static void main( String arg[] ){Abstraccio abstraccio = new AbstraccioRe�nada();Implementador implementador = new Implementador1();abstraccio.setImplementor( implemetador );abstraccio.operation();}}

3.3 Patró Composite

3.3.1 Objectiu

Composa objecte en jerarquies o arbres. Permet que els clients puguin crearobjectes simples o compostos i a més tots dos es tracten de la mateixa manera.

3.3.2 Diagrama

Figura 3.3: Patró Composite

• Component: de�neix la interfície de la composició.

• Fulla: representa i implementa els objectes simples.


• Component compost: representa i implementa els components compostque poden estar formats per fulles o per altres components compostos.

3.3.3 Aplicabilitat

Fem servir el patró Composite quan:

1. Es volen representar jerarquies.

2. Els clients han de tractar de la mateixa manera els objectes simples i alscompostos.


1. De�neix jerarquies de objectes que poden ser simples o compostos.

2. Simpli�ca la implementació del client ja que un mateix codi li permettreballar tant amb objectes simples com amb compostos.

3. Facilita afegir nous components.

4. Pot provocar que els elements siguin molt generals i a més les comprova-cions d`error s`han de fer en temps d`execució.

3.3.5 Codi

interface Component {public String defaultMethod();public ArrayList<Component> getChildren();public boolean addComponent(Component c);public boolean removeComponent(Component c);}class ComponentCompost implements Component {private String id;private ArrayList<Component> components = new ArrayList<Component>();public ComponentCompost (String identi�cationid = identi�cation;}public String defaultMethod() {String s = "("+ id + ":";for (Component child : getChildren())s = s + ""+ child.defaultMethod();return s + ")";}public ArrayList<Component> getChildren(){return components;}public boolean addComponent(Component c){

3.3. PATRÓ COMPOSITE 27

return components.add(c)}public boolean removeComponent(Component c){return components.remove(c);}}class Fulla implements Component {private String id;public Fulla (String identi�cation)id = identi�cation;}public String defaultMethod() {return id;}public ArrayList<Component> getChildren() {return null;

public boolean addComponent(Component c) {return false;}public boolean removeComponent(Component c) {return false;}}class CompositePattern {public static void main(String[] args) {ComponentCompost england = new ComponentCompost ("England");Fulla york = new Fulla("York");Fulla london = new Fulla(L.London");england.addComponent(york);england.addComponent(london);england.removeComponent(york); ComponentCompost france = new Compo-nentCompost ("France");france.addComponent(new Leaf("Paris"));ComponentCompost europe = new ComponentCompost ("Europe");europe.addComponent(england);europe.addComponent(france);System.out.println( europe.defaultMethod() );}}


3.4 Patró Decorator

3.4.1 Objectiu

Assigna responsabilitats addicionals als objectes de manera dinàmica, es a dir,en temps dèxecució. Proporciona una alternativa �exible a l`herència per talde estendre la funcionalitat dels objectes. Es basa en el principi �open-closed�.

3.4.2 Diagrama

Figura 3.4: Patró Decorator

• Component: de�neix la interfície dels objectes als que es vol afegir funci-onalitats dinàmicament.

• Component concret: implementa lòbjecte al qual se li assignen funciona-litats.

• Decorador: manté la relació amb el component i de�neix la interfície deldecorador que afegeix noves funcions.

• Decorador concret: implementa les noves funcionalitats del component.

3.4.3 Aplicabilitat

Fem servir el patró Decorador quan:

1. Es vol afegir funcionalitats als objectes de manera dinàmica i transparent(es a dir, no ha dàfectar al objecte).

2. Quan es vol posar i treure funcionalitats. Implementades al decorador nos`ha de tocar el codi del objecte.

3. Quan l`herència es poc pràctic o impossible.

3.4. PATRÓ DECORATOR 29

3.4.4 Avantatges i inconvenient

1. Proporciona més �exibilitat que l`herència.

2. Es poden afegir o treure funcionalitats en temps d`execució.

3. Evita que les classes superiors de les jerarquies hagin de tenir implemen-tades moltes funcions. Mitjan�cant un decorador, es pot implementar elcodi bàsic pel funcionament de l`objecte al propi objecte, i les funcionsaddicionals al decorador.

3.4.5 Codi

public class Decorator implements Component {Component component = new ConcreteComponent();public void action()component.action();}}public class ConcreteDecoratorA extends Decorator {String addedVariable;public void action()super.action();System.out.println(�ConcreteDecoratorA.action() called.�);addedVariable = �extra�;System.out.println(�ConcreteDecoratorA.addedVariable=� + addedVariable);}}public class ConcreteDecoratorB extends Decorator {public void action() {super.action();System.out.println(�ConcreteDecoratorB.action() called.�);addedBehavior ();}private void addedBehavior() {System.out.println(�ConcreteDecoratorB.addedBehavior () called.�);}}public class ConcreteComponent implements Component {public void action() {System.out.println(�ConcreteComponent.action() called.�);}}public interface Component {public void action();}public class DecoratorTest {


public static void main(String[] args) {System.out.println(�Decorator : Test�);Component decorated1 = new ConcreteDecoratorA();decorated1.action();Component decorated2 = new ConcreteDecoratorB();decorated2.action();}}

3.5 Patró Façade

3.5.1 Objectiu

Proporciona una interfície per un sistema complex, de manera que mitjan�-cant aquesta interfície és més fàcil utilitzar totes les funcionalitats del sistema.Lòbjectiu dàquesta patró, es proporcionar a lùsuari un punt dàccés al sis-tema. En aquesta interfície sìmplementa totes les funcionalitats que lùsuaridesitja utilitzar per a facilitar la interacció entre el client i el sistema. El fa�cademinimitza les dependències entre el client i el sistema i redueix la complexitat.

3.5.2 Diagrama

Figura 3.5: Patró Façade

• Fa�cade: Coneix el sistema complex i relaciona al client amb el sistema.Implementa totes les funcions necessàries per tal que lùsuari treballi cò-modament.

• Sistema: Implementa tota la funcionalitat . Hi poden haver tantes classescomo complex sigui el sistema.

3.6. PATRÓ PROXY 31

3.5.3 Aplicabilitat

Fem servir el patró Façade quan:

1. Es vol una interfície simple que permeti utilitzar totes o algunes de lesfuncionalitats dùn sistema complex. A mesura que els sistemes sàmplienla complexitat augmenta, per tant mitjançant el fa�cade sàconsegueix unpunt dàccés de fàcil ús.

2. Es vol desacoblar el client del sistema. Així si el sistema canvia no afectaal client, i a més proporciona independència i portabilitat.

3. Es vol crear subconjunts de classes en un sistema complex per tal dedonar independència a aquests subconjunts per tal que puguin canviarindependentment.


1. Amaga al client el funcionament intern del sistema complex, les relacionsentre classes i les dependències.

2. Facilita l`ús de les funcionalitats del sistema.

3. Proporciona un baix acoblament.

4. En cas necessari, es poden utilitzar totes les funcionalitats del sistema.

3.6 Patró Proxy

3.6.1 Objectiu

Proporciona un objecte que controla làccés a un altre. Amb aquest patró podemcontrolar quan sìnicialitza i crea un objecte, permeten que nomes es faci quanés necessari.

3.6.2 Diagrama

Figura 3.6: Patró Proxy


• Subject: De�neix la interfície comú entre el RealSubject i el Proxy. Dàquestamanera és pot utilitzar el Proxy quan sèspera un RealSubject.

• RealSubject: De�neix lòbjecte sobre el que treballa el Proxy.

• Proxy: Manté una referencia al objecte real. Proporciona una interfícieigual a la del Subject per poder substituir-l`ho. És el responsable de lacreació, eliminació del objecte i de làccés a ell.

Tres tipus de Proxy

• Proxy remot: Són els responsables de enviar les peticions al objecte.

• Proxy virtual: Guarden informació addicional del objecte.

• Proxy de protecció: Comprova que lòbjecte que crida al Subject té permísde fer-ho.

3.6.3 Aplicabilitat

Fel servir el patrò Proxy quan:

1. Necessitem un representant dùn determinat objecte (Proxy remot).

2. Necessitem controlar làccés a un objecte (Proxy de protecció).

3. Necessitem un substitut dùn objecte que a més a més proporcioni funci-onalitats noves o addicionals (Proxy virtual).


1. Un Proxy pot optimitzar la gestió dels objectes.

2. Permeten realitzar tasques de manteniment.

3. A vegades es necessari fer copies dòbjectes que poden ser costoses. Mit-jançant el Proxy podem realitzar les copies amb làvantatge de que nomesho farem quan lòbjecte canvii.

3.6.5 Codi

public class Client {public static void main( String arg[] ) {Subject real = new RealSubject();Proxy proxy = new Proxy();proxy.setRealSubject( real );proxy.request();}}public interface Subject {

3.7. PATRÓ FLYWEIGHT 33

void request();}

public class RealSubject implements Subject {public void request() {}}

public class Proxy implements Subject {private Subject realSubject;public void setRealSubject( Subject subject )realSubject = subject;}public Subject getRealSubject() {return realSubject;}public void request() {realSubject.request();}}

3.7 Patró Flyweight

3.7.1 Objectiu

Permet eliminar o reduir la redundància quan es treballa amb una quantitatd`objectes elevada que tenen informació igual. Permet compartir objectes, esa dir, un mateix objecte dona servei a diferents aplicacions, utilitza una únicainstancia per accedir a l`objecte compartit. Proporciona �exibilitat i rendimentde recursos.

3.7.2 Diagrama

Figura 3.7: Patró Flyweight

• Fabrica Flyweight: permet crear i controlar els objectes Flyweight (elsobjectes que es comparteixen). Garantitza que la compartició del objecte


es realitza de forma adequada.

• Flyweight: de�neix la interfície que permet als objectes realitzar accionssobre els objectes Flyweight.

• Flyweight Concret: implementa lòbjecte Flyweight.

• Client: guarda lèstat de lòbjecte Flyweight.

3.7.3 Aplicabilitat

Fem servir el patrò Flyweight quan:

1. Una aplicació utilitza un gran nombre dòbjectes.

2. Els costos per guardar tota la informació dels objectes són elevats, ja queel nombre de objectes es elevat.

3. Molts objectes poden ser substituïts per un nombre més petit i de maneraque es comparteixin o reutilitzin.

4. Quan les aplicacions no depenen de la identitat dels objectes. Com que elpatró Flyweight permet compartir objectes, aquests no es poden identi�carperquè en cas de fer-ho, diferents objectes poden retornar un mateix valor.


1. Reducció dèspai per emmagatzemar dades. Ja que els objectes es com-parteixen lèstalvi es produeix perquè un mateix objecte pot donar ser-vei a diferents aplicacions. Com més objectes es comparteixen més espaisèstalvia.

2. Redueix el nombre de objectes.

3. Redueix les dades que s`han de gestionar.

4. Lìnconvenient es que les cerques requereixen més temps.

3.7.5 Codi

//interfície Flyweightpublic interface Pelota {public Image getPelota();}//ConcreteFlyweight IO;public class PelotaConcreta implements Pelota {private Bu�eredImage imagen;public PelotaConcreta()try{imagen=imageIO.read(getClass().getClassLoader().getResource(�pelota.gif�));

3.7. PATRÓ FLYWEIGHT 35

}catch(IOException e){System.out.println(�no se puede cargra la imagen�);}}public Image getPelota(){System.out.println(�aqui�);return (Image)imagen;}

//(FlyweightFactory)public class PelotaFactoryprivate static Pelota miPelota =null;public static Pelota getPelota()if(miPelota==null)miPelota=new PelotaConcreta();return miPelota;}}//(Client)public class DibujaPelota {private Pelota pelota = PelotaFactory.getPelota();private int cordX=0;private int cordY=0;public Image getPelota(){return pelota.getPelota();}public void setCordX(int x){cordX=x;}public void setCordY(int y){cordY=y;}public int getCordX(){return cordX;}public int getCordY(){return cordY;}}

Capítol 4

Patrons de comportament

4.1 Patró Chain of Responsability

4.1.1 Objectiu

Evita làcoblament entre el emissor de la petició i el receptor dàquesta, donantla possibilitat a més dùn objecte de respondre. La petició circula per el sistema�ns que algun objecte respon a la petició.

4.1.2 Diagrama

Figura 4.1: Patró Chain of Responsability

• Handler: De�neix una interfície per tractar les peticions.

• ConcreteHandler: Tracta les peticions de les que es responsable. Si no escapa�c de tractar la petició, aleshores crida al següent.

• Client: Es qui inicialitza la petició.

37

38 CAPÍTOL 4. PATRONS DE COMPORTAMENT

4.1.3 Aplicabilitat

Fem servir aquest patró quan:

1. Hi ha més dùn objecte que pot respondre a una petició i no es coneix apriori qui ha de respondre sinó que s`ha de determinar de forma automà-tica.

2. Es vol enviar una petició a un objecte sense especi�car el receptor.

3. El conjunt dòbjectes que responen a una petició sèspeci�ca dinàmica-ment.


1. Redueix làcomblament. El emissor nomes ha de saber fer la petició, senseconèixer el receptor i de la mateixa manera el receptor no coneix a lèmissornomés ha de saber respondre la petició

2. Afegeix �exibilitat per assignar responsabilitat a objectes. Es pot canviarresponsabilitats en temps dèxecució.

3. No es garanteix la recepció. Pot haver-hi cassos en que una petició noobtingui resposta.

4.1.5 Codi

public class Request {private int m_value;private String m_description;public Request(String description, int value) {m_description = description;m_value = value;}public int getValue() {return m_value;}public String getDescription() {return m_description;}}

public abstract class Handler {protected Handler m_successor;public void setSuccessor(Handler successor) {m_successor = successor;}public abstract void handleRequest(Request request);

4.1. PATRÓ CHAIN OF RESPONSABILITY 39

}public class ConcreteHandlerOne extends Handler {public void handleRequest(Request request) {if (request.getValue() < 0) {System.out.println(�Negative values are handled by ConcreteHandlerOne:�);System.out.println(� �ConcreteHandlerOne.HandleRequest : � + request.getDescription()+ request.getValue());}elsesuper.handleRequest(request);}}public class ConcreteHandlerThree extends Handler{public void handleRequest(Request request) {if (request.getValue() >= 0) { //if request is eligible handle itSystem.out.println(�Zero values are handled by ConcreteHandlerThree:�);System.out.println(� �ConcreteHandlerThree.HandleRequest : � + request.getDescription()+ request.getValue());

elsesuper.handleRequest(request);}}public class ConcreteHandlerTwo extends Handler{public void handleRequest(Request request) {if (request.getValue() > 0) { //if request is eligible handle itSystem.out.println(�Positive values are handled by ConcreteHandlerTwo:�);System.out.println(� �ConcreteHandlerTwo.HandleRequest : � + request.getDescription()+ request.getValue());}elsesuper.handleRequest(request);}}public class Main {public static void main(String[] args) {Handler h1 = new ConcreteHandlerOne();Handler h2 = new ConcreteHandlerTwo();Handler h3 = new ConcreteHandlerThree();h1.setSuccessor(h2);h2.setSuccessor(h3);h1.handleRequest(new Request(�Negative Value �, -1));h1.handleRequest(new Request(�Negative Value �, 0));h1.handleRequest(new Request(�Negative Value �, 1));h1.handleRequest(new Request(�Negative Value �, 2));


h1.handleRequest(new Request(�Negative Value �, -5));}}

4.2 Patró Command

4.2.1 Objectiu

Encapsula una petició en un objecte. El client o objecte que crida la petició noconeix la seva estructura, nomes coneix la instancia. El patró Command permetque els objectes fagin peticions sense conèixer al receptor.

4.2.2 Diagrama

Figura 4.2: Patró Command

• Command: declara una interfície o classe abstracta per executar la acció.

• ConcreteCommand: De�neix lènllaç entre el receptor i làcció.

• Client: És el que realitza a la petició de command i estipula el receptor.

• Invoker: Demana al command que realitzi la acció

• Receiver: Sap com es realitzar làcció.

4.2.3 Aplicabilitat

Fem servir el patró command quan:

1. Permet parametritzar objectes amb una acció a realitzar.

2. Permet especi�car, posar en la cua, gestionar i executar peticions.

3. Permet desfer accions.

4.2. PATRÓ COMMAND 41

4. Permet registrar els canvis per que cas de caiguda del sistema es puguinrestablir, una vegada el sistema s`hagi recuperat.

5. Permet estructurar un sistema amb operacions dàlt nivell a partir dòperacionsbàsiques.

6. Permet que totes les accions sìnvoquin de la mateixa manera.


1. Desacobla lòbjecte que fa la petició dàcció del objecte que sap realitzar-la

2. Permet que les ordres siguin tractades com un objecte. Per tant, podenser manipulades o esteses.

3. Es poden combinar ordres simples per crear una ordre composta.

4. Es poden afegir noves ordres sense modi�car les existents

4.2.5 Codi

public interface Order {public abstract void execute ( );}public class StockTrade {public void buy() {System.out.println(�You want to buy stocks�);}public void sell() { System.out.println(�You want to sell stocks �); }}public class Agent {private m_ordersQueue = new ArrayList();public Agent() { }void placeOrder(Order order) {ordersQueue.addLast(order);order.execute(ordersQueue.getFirstAndRemove());}}

public class BuyStockOrder implements Order {private StockTrade stock;public BuyStockOrder ( StockTrade st) { stock = st; }public void execute( ) { stock . buy( ); }}public class SellStockOrder implements Order {private StockTrade stock;public SellStockOrder ( StockTrade st) stock = st; }public void execute( ) { stock . sell( ); }


}public class Client {public static void main(String[] args) {StockTrade stock = new StockTrade();BuyStockOrder bsc = new BuyStockOrder (stock);SellStockOrder ssc = new SellStockOrder (stock);Agent agent = new Agent();agent.placeOrder(bsc); agent.placeOrder(ssc);}}

4.3 Patró Iterator

4.3.1 Objectiu

Proporciona un mètode per accedir seqüencialment als elements dùn objectesense que s`hagi de mostrar la seva estructura interna. Permet recórrer llistesamb diferents recorreguts o amb diferents mètodes. A més es poden fer recorr-reguts simultanis al mateix objecte. El patró té la responsabilitat dàccedir irec`órrer lòbjecte de manera que les funcions que de�neixen els recorreguts iels accessos no han dèstar de�nits al objecte. Cada estructura o objecte tindráassociat un iterador.

4.3.2 Diagrama

Figura 4.3: Patró Iterator

• Iterador: de�neix una interfície per a recórrer i accedir als elements dùnaestructura.

• Iterador concret: implementa la interfície iterador.

• Estructura: de�neix una interfìcie per a la creació de lòbjecte Iterador

• Estructura concreta: implementa la interfície del creador de lìterador.

4.4. PATRÓ MEDIATOR 43

4.3.3 Aplicabilitat

Fem servir el patró Iterador quan:

1. Volem accedir al contingut dùn objecte sense exposar la seva representacióinterna.

2. Volem de�nir diferents recorreguts sobre un objecte.

3. Volem proporcionar una interfìcie uniforme per recorrer diferents estruc-tures.


1. Permet fer variacions en els recorreguts dels objectes o estructures.

2. Simpli�quen la interfície del objecte que s`ha dàccedir o recórrer.

3. Es pot fer més dùna recorregut o accés a una mateixa estructura.

4.3.5 Codi

interface IIterator{public boolean hasNext();public Object next();}interface IContainer{public IIterator createIterator();}

4.4 Patró Mediator

4.4.1 Objectiu

De�neix un objecte que encapsula com interactuen un conjunt dòbjectes. Pro-porciona un baix acoblament, ja que la relació entre objectes no es directe sinóque es fa a través del mediador.


4.4.2 Diagrama

Figura 4.4: Patró Mediator

• Mediator: de�neix una interfície que permet comunicar els diferents ele-ments (col·legues) del sistema.

• Mediator concret: implementa el comportament del mediador i la comu-nicació entre els elements.

• Colega: de�neix la interfície del elements que s`han de comunicar.

• Colega concret: implementen el conjunt de classes que es comuniquenmitjançant el mediador. Cada classe concreta ha de tenir associat unmediador concret.

Els missatges i les peticions sènvien entre colegues a través del mediador.

4.4.3 Aplicabilitat

Fem servir el patró Mediator quan:

1. Un conjunt dòbjectes s`han de comunicar entre ells.

2. Existeix un comportament o funcionalitat que es compartida entre unconjunt dòbjecte i aquests han de comunicar-se.

3. Per poder reutilitzar objectes que té comunicacions amb altres objectes.


1. Es redueix l`herència.

2. Es desacoblen objectes.

3. Simpli�ca les relacions entre objectes.

4. Abstrau como coopeeren els objectes.

4.5. PATRÓ OBSERVER 45

4.4.5 Codi

public interface Mediator {}public class ConcreteMediator implements Mediator {private ConcreteColega1 colega1= new ConcreteColega1();private ConcreteColega2 colega2 = new ConcreteColega2();}public class Colega {private Mediator mediator;public Mediator getMediator()return mediator;}public void setMediator( Mediator mediator ) {this.mediator = mediator;}}public class ConcreteColega1 { }

4.5 Patró Observer

4.5.1 Objectiu

De�neix una dependència entre objectes, de un a molts, de manera que quanun objecte canvia es noti�ca a la resta dòbjectes el canvi . Hi ha dues formesde noti�car el canvi:

1. Push: quan lòbjecte canvia, els objectes dependents són avisats de ques`ha produït el canvi.

2. Poll: els objectes dependents constantment han de preguntar si lòbjecteha canviat.

4.5.2 Diagrama

Figura 4.5: Patró Observer


• Subjecte: coneix als observadors. Proporciona un mecanisme per assignari treure observadors.

• Observador: de�neix una interfície que de�neix els observadors.

• Subjecte concret: implementa lòbjecte que ha de ser observat.

• Observador concret: implementa lòbservador i sèncarrega dàvisar quanes produeix el canvi al subjecte concret.

4.5.3 Aplicabilitat

Fem servir el patró Observador quan:

1. Quan hi hagi un objecte que depengui dùna altre i que els canvis en unafectin a làltre. Mitjançant lòbservador sèncapsulen els objectes perseparat i permet que varien independentment.


1. Permet modi�car els subjectes i els observadors de forma independent.

2. Permet utilitzar un objectes sense necessitat dùtilitzar làltre.

3. Làcoblament entre el subjecte i observadors és mínim.

4. Alta capacitat de comunicació entre els objectes.

4.5.5 Codi

public class Subject{private Vector observers = new Vector();public void attach( Observer observer ){if( observers.contains( observer ) == false ){observers.addElement( observer );}}public boolean detach( Observer observer ){return observers.removeElement( observer );}public void notifyObservers(){for( int i = 0; i < observers.size(); ++i ){Observer observer = (Observer) observers.elementAt(i);observer.update();}}}public interface Observer{void update();

4.6. PATRÓ STATE 47

}public class ConcreteSubject extends Subject {public int getState() {return 1; } } public class ConcreteObserver implements Observer {public void update()System.out.println( �update() called.� );}}public class Test{public static void main( String arg[] ){Subject subject = new ConcreteSubject();Observer observer = new ConcreteObserver();subject.attach( observer );subject.notify();}}

4.6 Patró State

4.6.1 Objectiu

Permet que un objecte canvi el seu comportament cada cop que canvia el seuestat intern.

4.6.2 Diagrama

Figura 4.6: Patró State

• Context: de�neix un punt d`interès per als clients.

• Estat: de�neix una interfície per tal d`encapsular els diferents comporta-ment que por realitzar un objecte segons el seu estat.


• Estat Concret: implementa el comportament dùn determinat estat.

4.6.3 Aplicabilitat

Fem servir el patró State quan:

1. El comportament dùn objecte depèn del seu estat.

2. Les accions que realitzar un objecte depèn del lèstat del propi objecte.


1. Permet tenir localitzats els comportaments dels objectes i associar uncomportament a un estat.

2. Permet afegir de forma fàcil nous estats i nous comportaments.

3. Evita sentències condicionals.

4. Fa explícites les transicions entre estats.

5. Els estats es poden compartir.

4.6.5 Codi

public class Test{public static void main( String arg[] ){try{State state = new ConcreteStateA();Context context = new Context();context.setState( state );context.request();}catch( Exception e ) {e.printStackTrace();}}}public class Context{private State state;public void setState( State state )this.state = state;}public State getState(){return state;}public void request(){state.handle();}

4.6. PATRÓ STATE 49

}public interface State{void handle();}public class ConcreteStateA implements State{public void handle(){}}public class ConcreteStateB implements State{public void handle(){}}public class StatePattern {public void main(String args[]){try{State state;Context context = new Context();SocketChannel socketChannel = null;// OPEN/LISTENING SOCKET//First State:state = new ConnectSocketState(socketChannel);context.setState( state );socketChannel = context.request();// CLOSE SOCKET//Second State:state = new CloseSocketState(socketChannel);context.setState( state );socketChannel = context.request();}catch( Exception e ) {e.printStackTrace();}}public class Context{private State state;public void setState( State state ){this.state = state;}public State getState(){return state;}public SocketChannel request(){return state.processState();}}public interface State{SocketChannel processState();}


public class ConnectSocketState implements State {SocketChannel socketChannel;public ConnectSocketState(SocketChannel socketChannel){this.socketChannel=socketChannel;}public SocketChannel processState() {try {int port = 21;InetAddress host = InetAddress.getByName(�192.168.1.1�);SocketAddress adress = new InetSocketAddress(host, port);socketChannel = SocketChannel.open(adress);socketChannel.con�gureBlocking(true);}catch (IOException e) {e.printStackTrace();}return socketChannel;}}public class CloseSocketState implements State{SocketChannel socketChannel;public CloseSocketState(SocketChannel socketChannel){this.socketChannel=socketChannel;}public SocketChannel processState(){try {socketChannel.close();}catch (IOException e) {e.printStackTrace();}return socketChannel;}}

4.7 Patró Strategy

4.7.1 Objectiu

De�neix una família d`algorismes, els encapsula i els fa intercanviables entre si.Permet que un programa canvii el seu comportament en temps d`execució.

4.7. PATRÓ STRATEGY 51

4.7.2 Diagrama

• Context: Manté una referència a l`estratègia.

• Estratègia: de�neix una interfície comú a tots els comportaments perme-sos.

• Estratègia concreta: implementa els diferents comportaments.

Figura 4.7: Patró Strategy

4.7.3 Aplicabilitat

Fem servir el patró Strategy quan:

1. Moltes classes relacionades nomes es diferencien en el comportament.

2. Són necessaris diferents mètodes per a realitzar un mateix comportament.

3. Una classe té diferents comportaments.


1. És una alternativa a l`herència.

2. Permet modi�car els comportaments de forma dinàmica.

3. Elimina sentències condicionals.

4. Un mateix objecte pot tenir diferents comportaments.

5. Es pot arribar a generar una gran nombre d`objectes.

6. Es pot afegir nous comportaments sense modi�car els objectes.


4.7.5 Codi

public interface IBehaviour {public int moveCommand();}public class AgressiveBehaviour implements IBehaviour{public int moveCommand(){System.out.println(� �Agressive Behaviour: if �nd another robot attack it�); re-turn 1;}}public class DefensiveBehaviour implements IBehaviour{public int moveCommand(){System.out.println(� �Defensive Behaviour: if �nd another robot run from it�);return -1;}}public class NormalBehaviour implements IBehaviour{public int moveCommand(){System.out.println(� �Normal Behaviour: if �nd another robot ignore it�);return 0;}}public class Robot {IBehaviour behaviour;String name;public Robot(String name)this.name = name;}public void setBehaviour(IBehaviour behaviour){this.behaviour = behaviour;}public IBehaviour getBehaviour(){return behaviour;}public void move(){System.out.println(this.name + �: Based on current position� + �the behaviourobject decide the next move:�);int command = behaviour.moveCommand(); // ... send the command to mec-hanismsSystem.out.println(� �The result returned by behaviour object � + �is sent to themovement mechanisms � + � for the robot � ` + this.name + �� `);}public String getName() {return name;}

4.8. PATRÓ TEMPLATE 53

public void setName(String name)this.name = name;}}public class Main {public static void main(String[] args) {Robot r1 = new Robot(�Big Robot�);Robot r2 = new Robot(�George v.2.1�);Robot r3 = new Robot(�R2�);r1.setBehaviour(new AgressiveBehaviour());r2.setBehaviour(new DefensiveBehaviour());r3.setBehaviour(new NormalBehaviour());r1.move();r2.move();r3.move();System.out.println(�� n New behaviours: � + �� n�̀Big Robot` gets really sca-red� + �� n�, `George v.2.1` becomes really mad because� + �it`s always attackedby other robots� + �� n�and R2 keeps its calm� n�);r1.setBehaviour(new DefensiveBehaviour());r2.setBehaviour(new AgressiveBehaviour());r1.move();r2.move();r3.move();}}

4.8 Patró Template

4.8.1 Objectiu

De�neix un esquelet que permet realitzar una acció, delegant a les subclassesalguns dels passos. Permet que les diferents subclasses tinguin comportamentsiguals però amb parts diferent, de manera que el codi que es igual per a totes lessubclasse es troba implementat a la classe superior, mentre que el comportamentdiferents es troba implementat a les classes inferiors.


4.8.2 Diagrama

Figura 4.8: Patró Template

4.8.3 Aplicabilitat

Fem servir el patró Template quan:

1. Es vol implementar parts dùn algorisme que no varien sigui lòbjecte quesigui, i hi ha una part que si que varia depenent del objecte.

2. Hi ha diferents objectes que tenen comportaments similar. Així evitem laduplicitat de codi.

3. Per controlar les extensions de les subclasses.


1. Reutilització de codi.

2. Facilitat de afegir nous objectes que es comporten similar a la resta dòbjectesde la jerarquia.

4.8.5 Codi

public abstract class Ca�eineBeverage {�nal void prepareRecipe ( ) {boilWater ( );brew ( );pourInCup ( );addCondiments ( );}abstract void brew ( );abstract void addCondiments ( );void boilWater ( ) {System.out.println (�Boiling Water�);

4.9. PATRÒ VISITOR 55

}void pourInCup ( ) {System.out.println(�Pouring into cup�);}}public class Tea extends Ca�eineBeverage {public void brew ( ){System.out.println (�Steeping the Tes�);}public void addCondiments ( ) {System.out.println(�Adding Lemon�);}}public class Co�ee extends Ca�eineBeverage {public void brew ( ) {System.out.println (�Dripping Co�ee Thru the Filters�);}public void addCondiments ( ){System.out.println(�Adding Sugar and Milk�);}}

4.9 Patrò Visitor

4.9.1 Objectiu

Representa una operació sobre els elements dùna estructura dòbjectes. Permetde�nir una nova operació sense canviar les classes dels elements sobre els queopera.

4.9.2 Diagrama

• Visitor: Declara una operació Visitar per cada classe dòperació Concre-tElement de lèstructura dòbjectes. El nom i signatura de la operacióidenti�quen a la classe que envía la petició Visitar al visitant. Això per-met al visitant determinar la classe concreta del element que està sentvisitat. A continuació el visitant pot accedir a lèlement directament através de la seva interfície particular.

• ContreteVisitor: Implementa cada operació declarada per el Visitor. Ca-da operació implementa un fragment del algoritme de�nit per la classecorresponent a la estructura. Proporciona el contexte per el algoritme iguarda el seu estat local.


• ObjectStructure: Pot enumerar els elements. Pot proporcionar una inter-fície dàlt nivell per permitir al visitant visitar els seus elements. Pot serun patró Composite.

• Element: Interfície o classe abstracte que de�neix una operació accept queagafa un visitant com argument.

• ConcreteElement: Implementa una operació accept que agafa un visitantcom a argument.

Figura 4.9: Patró Visitor

4.9.3 Aplicabilitat

Sùtilitza quan:

1. Una estructura dòbjectes conté moltes classes dòbjectes amb diferentsinterfícies i volem realitzar operacions sobre els elements que depenen dela seva classe concreta.

2. Es necessita realitzar moltes operacions diferents i no relacionades sobreobjectes dùna estructura dòbjectes, i volem evitar �contaminar� els classeamb aquestes operacions.

3. Les classes que de�neixen lèstructura dòbjectes no canvien gaire, peròmoltes vegades volem de�nir noves operacions sobre lèstructura.

4.9. PATRÒ VISITOR 57


1. El visitant facilita afegir noves operacions.

2. Un visitant agrupa operacions relacionades i separa les que no ho estan.

3. És difícil afegir noves classes de ConcreteElement.

4. Es poden visitar varies jerarquies de classes.

4.9.5 Codi

public interface Visitor {void visitConcreteElementA( ConcreteElementA element );void visitConcreteElementB( ConcreteElementB element );}public interface Element {void accept( Visitor visitor );}public class ConcreteVisitor1 implements Visitor {void visitConcreteElementA( ConcreteElementA element ) { }void visitConcreteElementB( ConcreteElementB element ) { }}public class ConcreteVisitor2 implements Visitor {void visitConcreteElementA( ConcreteElementA element ) { }void visitConcreteElementB( ConcreteElementB element ) { }}public class ConcreteElementA implements Element {public void accept( Visitor visitor ){visitor.visitConcreteElementA( this );}public void operationA() {}}public class ConcreteElementB implements Element {public void accept( Visitor visitor ){visitor.visitConcreteElementB( this );}public void operationB() {}}


4.10 Patrò Memento

4.10.1 Objectiu

Representa i externalitza el estat intern dùn objecte sense trencar lèncapsulació,de manera que aquest pugui tornar a aquest estat més endavant.

4.10.2 Diagrama

Figura 4.10: Patró Memento

• CareTaker: Es responsable de guardar en un lloc segur el memento. Maiexamina els continguts del memento, ni opera sobre ell.

• Memento: Guarda lèstat intern del Objecte Creador. Protegeix davantlàccés dàltres objectes que no siguin el creador.

• Originator: Crea un memento que conté una instancia del estat internactual. Fa servir el memento per tornar al estat anterior.

4.10.3 Aplicabilitat

El memento es fa servir quan:

1. S`ha de guardar una instancia del estat dùn objecte (o part dàquest) perque pugui tornar posteriorment a aquest estat.

2. Una interfície directa per obtindre lèstat exposa detalls dìmplementaciói trenqui lèncapsulació de lòbjecte.

4.10.4 Avantatges i inconvenients.

1. Evita exposar lìnformació que nomes hauria dèstar gestionada per uncreador, però que ha de ser guardada fora del creador.

2. Simpli�ca al Creador.

3. Utilitzar el memento pot ser costos.

4.10. PATRÒ MEMENTO 59

4. El alguns llenguatges pot ser difícil garantitzar que només el creador ac-cedeix al estat del memento.

5. Hi han costos ocults en el manteniment dels mementos.

4.10.5 Codi

class Memento{private String state;

public Memento(String stateToSave){state = stateToSave;}

public String getSavedState(){return state;}}

class Originator{private String state;

public void set(String state){System.out.println(�Originator: Setting state to �+state); this.state = state;}

public Memento saveToMemento(){System.out.println(�Originator: Saving to Memento.�);return new Memento(state);}

public void restoreFromMemento(Memento m){state = m.getSavedState();System.out.println(�Originator: State after restoring from Memento: �+state);}}

class Caretaker {private ArrayList<Memento> savedStates = new ArrayList<Memento>();


public void addMemento(Memento m) savedStates.add(m);public Memento getMemento(int index) return savedStates.get(index);}

class MementoExample {public static void main(String[] args) {Caretaker caretaker = new Caretaker();

Originator originator = new Originator();originator.set(�State1�);originator.set(�State2�);caretaker.addMemento( originator.saveToMemento() );originator.set(�State3�);caretaker.addMemento( originator.saveToMemento() );originator.set(�State4�);

originator.restoreFromMemento( caretaker.getMemento(1) );}}

4.11 Patrò MVC

4.11.1 Objectiu

És un patró compost, que ens permet separar el model de dades, la interfícied`usuari i la lògica de control. Es separa l`aplicació en tres blocs: el model, lavista i el controlador.

4.11. PATRÒ MVC 61

4.11.2 Diagrama

Figura 4.11: Patró MVC

• La vista, és la interfície dùsuari.

• El controlador, respon als events generats per lùsuari i realitza peticionsal model.

• El model, conté la informació i el coneixement de com resoldre les peticionspel controlador, pot actualitzar la vista.

4.11.3 Aplicabilitat sobre tres patrons esmentats anteri-

orment

1. Observer: Model, permet mantenir actualitzats les vistes i controladors.Quan el model canviï ho noti�carà als seus observadors, la vista i el con-trolador.

2. Composite: View, ens permet tenir múltiples �nestres. La vista està for-mada per �nestres (composite) i botons (fulles), quan volem actualitzarla vista, només era necessari comunicar-ho al component.

3. Strategy: Controller, permet que puguin canviar el seu comportament. Lavista només proporciona la GUI, mentre que el controlador serà lèncarregatdàtendre lèvent de lùsuari, la manera dàtendre lèvent pot variar en ca-da moment.

Capítol 5

Bibliogra�a

1. Patrones de diseño: elementos de software orientado a objetos reutilizableErich Gamma, Richard Helm, Ralph Johnson, John VlissidesAddison-Wesley - 2003ISBN: 8478290591

2. www.wikipedia.es

3. http://modelosprogramacion.blogspot.com.es

4. http://pserv.udg.edu/Portal/Uploads/4305830/index.htm

63

patrons de disseny - udgima.udg.edu/~sellares/einf-es2/present1213/patronsdisseny.pdf · els...

Documents