Patrons de Dissney

Enginyeria del Software I

Xavier Pacheco Lluís Clavaguera

EINF

Índex   Índex.................................................................................................................2  Introducció ......................................................................................................3  

Tipus de Patrons ..........................................................................................4  Conjunt de patrons de disseny.....................................................................6  

Patró Template Method.............................................................................7  Patró Strategy..............................................................................................9  Patró Factory Method ..............................................................................11  Patró Abstract Factory .............................................................................13  Patró Singleton ..........................................................................................15  Patró Adapter ...........................................................................................17  Patró Bridge ...............................................................................................19  Patró Decorator ........................................................................................21  Patró Observer ..........................................................................................23  Patró Composite .......................................................................................25  Patró Chain of Responsability..................................................................31  Patró State .................................................................................................34  Patró Façade ............................................................................................38  Patró Prototype .........................................................................................42  Patró Visitor ................................................................................................46  Patró Mediator ..........................................................................................50  Patró Proxy .................................................................................................53  Conclusions................................................................................................56  Bibliografia bàsica ....................................................................................57  

Introducció   Un patró de disseny és un esquelet de les solucions a problemes de disseny en el desenvolupament del software, és a dir, donen una solució ja provada i documentada,a problemes amb contexts similars. Una característica molt important dels patrons és que han de ser reutilitzables. Cada patró, descriu un problema que passa moltes vegades en el nostre entorn, així com la solució a aquest, de tal manera que podem utilitzar la mateixa solució moltes vegades més endavant sense haver de pensar la solució una altre vegada. Aquetes solucions estan provades i donen dissenys altament flexibles, modulars i reutilitzables. Els objectius dels patrons de disseny són els següents:

• Proporcionen un conjunt d’elements reutilitzables en el disseny de sistemes de software

• Eviten buscar la solució d’un problema que ja es coneixia

anteriorment i que estava solucionat

• Formalitzen un vocabulari comú entre dissenyadors

• Estandaritzar la manera en què es realitza el disseny

• Facilitar l’aprenentatge de la noves generacions de dissenyadors

Objectius no desitjats:

• Imposar certes alternatives de disseny davant d’altres

• Eliminar la creativitat inherent en el procés de disseny Així doncs no és obligatori utilitzar els patrons de disseny, és aconsellable en el cas de tenir el mateix problema o similar al que soluciona. L’abús de patrons també pot ser un error.

Tipus  de  Patrons   Patrons d’arquitectura Són aquells patrons que representen un esquema organitzatiu estructural, és dir que representen un estructura per un sistema de software. Patrons de Disseny Aquells patrons que expressen esquemes de com definir certes estructures de disseny o les seves relacions, amb las que construir sistemes de software Dins els patrons de disseny es classifiquen també en: de creació, estructural i de comportament. Els de creació com indica el seu nom, són patrons que tracten la creació d’objectes, i intent fer-ho de forma adient. Els Patrons estructurals, s’ocupen de com es combinen les classes i els objectes per a formar una estructura complexa. Finalment els de comportament, fan referència a algorismes i a l’assignació de responsabilitats entre objectes. Dialectes Són patrons de baix nivell i més específics per cada llenguatge de programació. Concreten algun patró però per un llenguatge de programació concret. Patrons d’interacció Són un tipus de patrons, enfocats bàsicament a les interfícies web. A més, últimament ha aparegut la idea de antipatró de disseny, que com el seu nom indica, serveixen per intentar evitar els errors comuns de disseny en el software. La idea d’aquestes és explicar problemes que donen certs dissenys molt freqüents, per intentar evitar que els sistemes acabin altre vegada en el mateix error. Algunes exemples d’antipatrons són els següents:

• Base de dades com a comunicador de processos (database as an IPC):Utilitzar una base de dades per comunicar processos en un o varis ordinadors, quan la comunicació entre processos directa es més adequada.

• Blob: Objecte SuperPoderós • Clase Gorda: Dotar a una classe amb massaatributs i/o

mètodes, fent-la responsable de la major part de la lògica de negoci.

• Botomàgic (magic pushbutton):Tendir, desenvolupant interfícies, a programar la lògica de negoci en els mètodes de interacció, implementant els resultats de les accions de l’usuari en termes no suficientment abstractes.

• Carrera d’obstables (race hazard): Incapacitat de preveure les conseqüències de diferents events successius.

• Fàbrica de combustible (gas factory): Dissenyar de manera innecessariament complexa.

• Interficie inglada (interface bloat): Pretendre que una interfície sigui tan potent que llavors és extremadament difícil de implementar.

• Re-dependència (re-coupling): Introduir dependencies innecessaries entre objectes.

• Sistema de tubs de calefacció (stovepipe system): Construir un sistema difícilment mantenible, assemblant components poc relacionats.

A continuació doncs, passarem a veure un conjunt de patrons de disseny que és el tema que ens toca, ordenats de menys a més dificultat de comprensió.

Conjunt  de  patrons  de  disseny   Els patrons de disseny com hem comentat anteriorment, són un esquelet d’una solució a un problema ja resolt anteriorment. A continuació en veurem uns quants i un conjunt d’exemples.

Patró  Template  Method   Nom del Patró: Template Method Tipus: Estructural Intenció: Definir una estructura que serà utilitzada en totes les subclasses, encara que redefinida. Motivació: Definir una estructura de herència en que la superclasse que serveixi de plantilla dels mètodes en les subclasses. Estructura:

AbstractClass: Classe on es defineix l’estructura.

ConcreteClass: Classe on s’implementarà l’estructura de l’AbstractClass.

Conseqüències:

• Permet factoritzar el comportament comú en biblioteques de classes

• És important indicar de quin tipus són els mètodes en els que es basa el mètode:

• Es pot obligar a redefinir per extensió. Exemple:

Patró  Strategy   Nom del Patró: Strategy Tipus: De comportament Intenció: Permetre mantenir un conjunt d’algoritmes dels que l’objectiu client pot elegir aquell que li convingui i intercanviar-lo segons les seves necessitats. Motivació: Qualsevol programa que ofereixi un servei o funció determinada, que pugui ser realitzada de diferents formes, és candidat a usar el patró Strategy. Pot haver-hi diferents estratègies i qualsevol d'elles pot ser intercanviada per una altre en qualsevol moment, inclús en temps d'execució. Estructura:

Context:Clase base que manté una instància del estat actual. Strategy: Classe abstracta de la qual el context en té una instància, amb l’estructura definida.

ConcreteStrategy’s: Classes on s’implementarà l’estructura de l’Strategy.

Conseqüències:

• Al treure els diferents algorismes del context flexibilitzem la definició de nous algoritmes o noves variants dels algorismes.

• Aquest patró té més sentit quan els algorismes són complicats i / o es recolzen en estructures de dades complexes, de manera que en treure'ls del context.

• Un inconvenient és que els clients han de conèixer l'existència de les diferents estratègies. Per tant, només hem d'usar el patró quan l'estratègia a utilitzar sigui rellevant per als clients.

• Si hi ha molta variació en la complexitat dels algorismes pot passar que als més simples el context els passi informació innecessària

Exemple:

Patró  Factory  Method   Nom del Patró: Factory Method Tipus: Creacional Intenció: Definir la interfície de creació d'un cert tipus d'objecte, permetent que les subclasses decideixin quina classe concreta necessiten instàncies. Motivació: Consisteix en utilitzar una classe constructora (semblant al Abstract Factory) abstracta amb uns quants mètodes definits i altes abstractes: el dedicat a la construcció dels objectes d'un subtipus d'un tipus determinat. Estructura:

• Product defineix la interfície pels objectes que el factory method crea

• ConcreteProduct implementa la interfície de Product

• Creator

Declara el mètode factoria, que retorna un objecte de tipus Product (es pot donar una implementació per defecte). Pot invocar el factory method per crear un objecte Product.

• ConcreteCreator redefineix el factory method perquè torni la instància de ConcreteProduct que li interessa

Conseqüències:

• Permet escriure algorismes genèrics que funcionen amb qualsevol tipus de ConcreteProduct

• Un inconvenient és que pot obligar a crear subclasses artificials de Creator

• Permet definir un "punt de variació" (hook) • Pot definir una implementació per defecte • Permet separar una jerarquia complexa en dues jerarquies

paral·leles Exemple:

Patró  Abstract  Factory   Nom del Patró: Abstract Factory Tipus: Creacional Intenció: El seu objectiu és independitzar un sistema de la manera com es creen, componen i representen els seus objectes Motivació: Hem de crear diferents objectes, tots pertanyents a la mateixa família. Estructura:

• AbstractFactory defineix la interfície per a la creació dels productes i les ConcreteFactory implementen aquesta interfície

• AbstractProduct declara la interfície per a un cert tipus de

producte i els ConcreteProduct implementen aquesta interfície i defineixen un tipus de producte que serà creat per la corresponent ConcreteFactory

• Els clients només depenen de les interfícies AbstractFactory i

AbstractProduct

Conseqüències:

• Aïlla als clients de les implementacions concretes. • Facilita canviar una família de productes per una altra. • Promou la consistència entre els productes. • Dificulta la definició de nous productes.

Exemple:

Patró  Singleton   Nom del Patró: Singleton Tipus: De comportament Intenció: Restringir la creació d'objectes pertanyents a una classe o el valor d'un tipus a un únic objecte. Motivació: El patró singleton s'implementa creant en la nostra classe un mètode que crea una instància de l'objecte només si encara no n'hi ha cap. Per assegurar que la classe no pot ser instanciada novament es regula l'abast del constructor (amb atributs com protegit o privat). Estructura:

• Singleton defineix un mètode de classe que permet accedir a la instància única i pot ser el responsable de crear aquesta instància

Conseqüències:

• Accés controlat a la instància. • Manté net l'espai de noms en evitar l'ús de variables globals. • Permet especialitzar les característiques de la instància. • Permet mantenir un nombre variable d'instàncies. • És més flexible que aconseguir el mateix resultat amb mètodes

de classe.

Exemple:

Patró  Adapter   Nom del Patró: Adapter Tipus: Estructural Intenció: Converteix la interfície d'una classe en la interfície que esperen els clients Motivació: Adaptar a una mateixa entrada diferents components. Estructura:

• Target defineix la interfície que el client necessita. • Adaptee implementa la interfície que volem reutilitzar. • Adapter adapta la interfície de Adaptee a Target.

Conseqüències:

• Adaptadors basats en herència • No serveix per adaptar una classe i totes les seves

subclasses. • L'adaptador pot redefinir una part del comportament de

la classe adaptada.

• Només introdueix un objecte i no necessita indirecció addicionals.

• Adaptadors basats en composició.

• Permet adaptar una jerarquia de classes i afegir funcionalitat a totes les classes d'una vegada.

• Resulta més difícil redefinir el comportament de la classe adaptada.

• La complexitat dels adaptadors varia des de simples traductors

fins implementacions que es recolzen en la classe adaptada. • Les classes reutilitzables poden preveure la possibilitat de

treballar amb diferents interfícies (interfícies intercanviables). • De vegades es poden necessitar adaptadors bidireccionals que

s'implementen fàcilment amb herència múltiple. Exemple:

Patró  Bridge   Nom del Patró: Bridge Tipus: Estructural Intenció: Desacobla una abstracció de la seva implementació per tal que puguin evolucionar independentment Motivació: Quan hi ha diferents implementacions per a una mateixa abstracció la herència dificulta la definició de noves abstraccions i s'acobla el codi client amb una implementació concreta Estructura:

• Abstraction defineix la interfície i manté una referència de tipus Implementor

• RefinedAbstraction estén la interfície de Abstraction • Implementor defineix la interfície de les implementacions que

normalment es compon d'operacions primitives bàsiques • ConcreteImplementor implementa la interfície de Implementor

Conseqüències:

• Desacobla interfície i implementació

• Permet canviar la implementació d'una abstracció en temps d'execució.

• Elimina dependències en temps de compilació. El codi client segueix sent compatible a nivell binari

• Millora l'extensibilitat del sistema. • Amaga els detalls d'implementació dels clients daptadors

basats en herència Exemple:

Patró  Decorator   Nom del Patró: Decorator Tipus: Estructural Intenció: Permet afegir dinàmicament noves responsabilitats a un objecte, proporcionant una alternativa a la definició de subclasses. Motivació: Quan necessitem no tenir successives classes que heretin d’una primera per incorporant una nova funcionalitat. Estructura:

• Component defineix la interfície dels objectes als quals se'ls poden afegir responsabilitats dinàmicament.

• ConcreteComponent defineix un objecte al qual se li poden afegir responsabilitats.

• Decorator emmagatzema una referència a un objecte Component i defineix una interfície que s'ajusta a la de Component.

• ConcreteDecorator afegeix responsabilitats al component.

Conseqüències:

• Proporciona un mecanisme més flexible que l'herència per afegir responsabilitats.

• Evita sobrecarregar les parts altes d'una jerarquia de classes amb funcionalitats potencialment innecessàries.

• Compte en comparar objectes decorats. • Un ús extensiu del patró Decorator produeix codi més difícil

d'entendre i depurar. Exemple:

Patró  Observer   Nom del Patró: Observer Tipus: De comportament Intenció: Permet definir dependències un-a-molts de manera que els canvis en un objecte es comuniquin als objectes que en depenen. Motivació: Quan necessitem proporcionar diferents vistes de la mateixa informació, de manera que els canvis en una vista afecten a les altres, però les vistes no es coneixen entre si. Estructura:

• El subjecte coneix la llista dels seus observadors i se'ls notifica quan canvia el seu estat.

• Cada observador coneix al seu subjecte i pot preguntar pel seu estat, per canviar el seu d'acord, o també modificar l'estat del subjecte.

Conseqüències:

• L'avantatge fonamental és el desacoblament entre subjectes i observadors, convertint-los en entitats reutilitzables per separat

• És un mitjà molt flexible de distribuir la informació

o Els observadors poden subscriure's a un subjecte o donar-se de baixa quan els interessi en temps d'execució

o El subjecte pot incloure certa informació en el missatge d'actualització de manera que cada observador pot decidir si el canvi d'estat l'afecta o no

• Precisament la descentralització és el problema d'aquest patró: un petit canvi en el subjecte pot provocar molt processament en els observadors

o Té més sentit llavors que els observadors rebin la informació necessària per decidir si els interessa o no actualitzar.

Exemple:

Patró  Composite   Nom del Patró: Composite Tipus: Estructural Intenció: Permet representar estructures continent-contingut on els clients poden tractar de la mateixa forma als compostos i als individus. Motivació: És necessari equipar una implementació amb diferents capes. Estructura:

• Component defineix la interfície comuna i implementa el comportament per defecte, juntament amb la interfície necessària per accedir als fills i opcionalment el pare.

• Leaf representa els objectes sense fills i defineix el comportament dels objectes primitius de la composició.

• Composite defineix el comportament dels objectes amb fills, emmagatzema els fills i implementa les operacions d'accés als fills.

• Client manipula els objectes de la composició a través de la interfície Component.

Conseqüències:

• Permet tractar de manera homogènia a objectes simples i compostos.

• Simplifica el codi dels clients, evitant distincions de casos. • Facilita la definició de nous tipus de components sense afectar

els clients. • Pot obligar a realitzar un disseny massa generalista que dificulti la

definició de compostos on es restringeixi el tipus de components. Exemple:

Patró  Command Nom: Command (Acció o ordre) Tipus: De Comportament Intenció: Encapsular una comanda o acció dins un objecte, de tal manera que pugui ser guardat, passat per paràmetre o retornat igual que qualsevol altre objecte. Motivació: A vegades l’usuari vol evitar sol·licituds d’objectes sense conèixer exactament l’operació sol·licitada ni el receptor de la sol·licitud. En general un objecte botó o menú, executa sol·licituds però la sol·licitud no està implementada dins del mateix. Una biblioteca de classes per interfícies d’usuari tindrà objectes com botons i elements de menú, responsables de realitzar alguna operació en resposta a una entrada de l’usuari. Estructura:

Command: Declara la interfície per l’execució de l’operació. Concret Command: Defineix la relació entre l’objecte Reciver i una acció, implementa Execute i invoca les operacions corresponents al Reciver. Client: crea un objecte Concret Command i el relaciona amb el seu Reciver. Invoker: És el que fa sol·licituds al objecte Command. Reciver: Sap com executar les operacions associades a la sol·licitud. Qualsevol classe pot ser un receptor.

Conseqüències:

• S’independitza la part de l’aplicació que invoca a les accions de la implementació d’aquestes.

• Al tractar-se d’accions com objectes, es pot realitzar herència

de les mateixes, composicions de ordres, etc.

• Es facilita molt l’ampliació del conjunt d’accions Exemple:

En aquest exemple podem veure com Item mànager seria el gestor o qui invoca els events. Tenim dues classes Item i Category que són dependents entre elles, és a dir una guarda la instància de l’altre. Per

fer el procés de afegir i eliminar les instàncies s’ha creat una acció (AddCommand i DeleteCommand) així són aquestes qui s’ocupen d’aquesta tasca.

Patró  Chain  of  Responsability   Nom: Chain of Responsability (Cadena de responsabilitats) Tipus: De Comportament Intenció: Establir una cadena en un sistema, perquè el missatge pugui ser utilitza en el nivell en què es rep per primera vegada, o ser redirigit a l’objecte que pugui utilitzar-lo. Motivació: La petició ha de ser processada pels receptors, el que vol dir que la petició queda al marge del ús exclusiu. El que pretén és donar un major detall i especificació a les peticions generades. Les peticions seran filtrades per tots els receptors a mesura que es van generant els resultats esperats. Estructura:

Cliente:Serà l’encarregat de generar les peticions que s’hagin de passar per el Manejador genèric. Manejador: Serà una interfície on es vagin duent a terme les peticions que generarà el client. Manejador Concret: Tractarà cada petició que li correspon del client.

Conseqüències:

• Facilita que hi hagi un acoblament baix entre el client i qui ha de tractar cada missatge.

• Evita acoblar l’emissor d’una petició al seu receptor. • Crea una cadena d’objectes receptors i cadascun va passant

la petició sinó la pot tractar. Exemple:

En l’exemple es pot veure com el client demana una petició per demanar una autorització, i cada càrrec delega la petició d’autorització a qui tingui permís per fer aquesta autorització.

Patró  State   Nom: State (Estat o objectes d’estat) Tipus: De Comportament Intenció: Canviar fàcilment l’estat d’un objecte en temps d’execució. Motivació: Canviar el comportament en funció de l’estat. Quan volem que un objecte canvi el seu comportament, segons canvia el seu estat, es presenta el problema de la complexitat del codi. Estructura:

Context: Classe base que manté una instància del estat actual. State: Es defineix com un interfície per el comportament associat a un estat determinat del Context. ConcretState: Cada subclasse que implementa el comportament associat a un estat del Context.

Conseqüències:

• Localitza el comportament depenent del estat i divideix el comportament en diferents estats.

• Fa explícites les transaccions entre estats. • Els objectes estat poden compartir-se.

Exemple:

En l’exemple es pot veure l’estat d’una compte de comercial. A cada estat tenim uns mètodes que es comporten diferent i inclús algun mètode concret d’aquell estat.

Patró  Façade   Nom: Façade (Façana) Tipus: Estructural Intenció: Proporciona una interfície simplificada per un grup de subsistemes o per un sistema complex. Motivació: Simplificar l’accés a un conjunt de classes proporcionant una única classe que tots utilitzen per comunicar-se amb el conjunt, reduir la complexitat i minimitzar les de Façade (Façana) Estructura:

Façade:Coneix quines classes del subsistema son responsables de una petició i delega les peticions dels clients als objectes adients. Classes de Package: Implementen la funcionalitat del subsistema, no coneixen a Façade, però són les que fan la feina. Client:Són les classes que demanen a Façade el que volen fer de forma molt més simplificada.

Conseqüències:

• Definir una única interfície per accedir a una funcionalitat. • Defineix un intermediari més llegible i simple. • Crea un intermediari i realitzar crides a aquest i solament a

través d’aquest. • S’ha d’utilitzar per crear classes simples, no classes que serveixin

per tot. Exemple:

En l’exemple es pot veure com hem afegit una classe CostumerFacade, que s’ocupa de fer tot el necessari per guardar les dades d’un client quan són modificades. Així no cal que ho faci tot el controlador AccountManager i es simplifica el codi.

Patró  Prototype   Nom: Prototype (Prototip) Tipus: Creacional Intenció: La seva finalitat és crear nous objectes duplicats, clonant una instància creada prèviament. Motivació: Abstreure la lògica que decideix quin tipus d’objectes utilitzarà una aplicació, de la lògica que utilitzarà els objectes en la seva execució. Els motius d’aquesta separació poden ser variats, per exemple l’aplicació ha de basar-se en alguna configuració o paràmetre en temps d’execució per decidir el tipus d’objectes que es crearan. Estructura:

Façade: Coneix quines classes del subsistema son responsables de una petició i delega les peticions dels clients als objectes adients.

Classes de Package: Implementen la funcionalitat del subsistema, no coneixen a Façade, però són les que fan la feina. Client: Són les classes que demanen a Façade el que volen fer de forma molt més simplificada.

Conseqüències:

• És una alternativa a un conjunt de Factory. • Simplifica la tasca de crear objectes, creant un prototip, i

demanant clons d’aquell amb les modificacions necessaris. Exemple:

Plantejament del problema

Solució amb Prototype

L’exemple representa la creació d’un pla en funció del sistema operatiu en què ens trobem. A la segona figura podem veure com es

Disseny amb Factory

faria utilitzant el patró Factory. A la tercera i quarta figura, està redissenyat utilitzant el prototype. Així el disseny que queda finalment és la classe HostingPlanKit, serà l’engarregada de retornar un clon de l’objecte. HostingPlanManager crear els plants en funció del sistema operatiu on ens trobem. HostingPlanManager podríem dir que seria com un Factory que crea el HostingPlanKit.

Patró  Visitor   Nom: Visitor (Visitant) Tipus: De comportament Intenció: Representa una operació sobre els elements d’una estructura d’objectes. Centralitza el comportament i permet que aquestes operacions siguin modificables i ampliables sense canviar les classes sobres les quals actuen. Motivació: Un compilador representa els programes com arbres de sintaxis abstracte, sobre els quals executa operacions. Moltes operacions necessiten diferenciar cada tipus de node en l’arbre (expressions, variables, etc.) Estructura:

Visitor: Defineix una operació de visita per cada classe de l’ConcreteElement en l’estructura d’objectes. ConcreteVisitor: Implementa la interfície Visitor, cada operació implementa un fragment de la tasca global, i permet guardar informació local. Element: Defineix una operació accept amb un objecte Visitor com a argument. ConcreteElement: Implementa la operació accept. ObjecteStructure: Gestiona l’estructura d’objectes sobre la cual actua el visitor.

Conseqüències:

• Facilita la definició d’operacions noves. • Agrupa operacions relacionades. • Afegeix noves classes ConcretElement pot ser molt costos.

• El Visitor pot acumular l’estat d’una operació al visitar l’estructura d’objectes, en comptes de passar-lo com argument o utilitzar variables globals.

• Destrueix l’encapsulació. Exemple:

L’exemple representa una comanda que segons l’estat on està tenim unes taxes o altres, per tant per calcular el preu d’aquesta cal utilitzar un mètode diferent. A més l’estructura és complexa. Així es crea un Visitor que permet calcular el preu de les taxes, o afegir funcionalitats com calcular el preu de cost, etc, sense alterar el codi de les classes Order.

Patró  Mediator   Nom: Mediator (Visitant) Tipus: De comportament Intenció: Simplifica la comunicació entre objectes d’un sistema introduint un únic objecte que gestioni la distribució de missatges entre els altres. Motivació: Quan molts objectes interactuen amb altres objectes, es pot formar una estructura complexa, amb objectes amb moltes connexions amb altres. En un cas extrem cada objecte pot conèixer a tots els altres. Per evitar això tenim el patró Mediator que encapsula el comportament de tot el conjunt d’objecte en un de sol. Estructura:

Visitor: Defineix una interfície per a comunicar-se amb els objectes Colleague. ConcreteMediator: Implementa el comportament cooperatiu entre els Colleague, els coneix i els manté.

Colleagues: Cada Colleague coneix al seu mediador, i utilitza aquest per comunicar-se amb els altres.

Conseqüències:

• Desacobla els objectes Colleague. • Simplifica la comunicació entre objectes. • Abstreu com els objectes cooperen entre ells. • Centralitza el control, això pot ser complex de entendre i

mantenir. Exemple:

L’exemple és un conjunt de botons que interactuen amb una llista local i una llista remota. L’objecte Mediator, s’ocupa de fer totes les accions que ha de fer el sistema, i de distribuir la feina, així no cal que tots els objectes es coneguin.

Patró  Proxy   Nom: Proxy (Representant) Tipus: Estructural Intenció: Proporciona un representant a un altre objecte per raons que poden ser l’accés, la velocitat o la seguretat. Motivació: Retardar el cost de crear i inicialitzar un objecte fins que realment és necessari. Per exemple, no obrir les imatges de un document fins que no son visibles. Hi poden haver ocasions en què es vulgui posposar el cost de la creació d’un objecte fins que sigui necessari utilitzar-lo. L’objecte proxy actua en lloc del objecte real, ofereix la mateixa interfície i el sol·licita quan sigui necessari. Estructura:

Subject: Defineix una interfície comú per el RealSubject i el proxy, de manera que pugui utilitzar u Proxy en qualsevol lloc en què s’espera un RealSubject. RealSubject: Defineix l’objecte real representat. Proxy: Manté una referència que permet al Proxy accedir a l’objecte real. Proporciona una interfície idèntica a la del RealSubject. Controla l’accés al RealSubject i pot ser responsable de la creació i destrucció d’aquest.

Conseqüències:

• Fa d’intermediari entre dos objectes. • Permet delegar la tasca de crear i destruir un objecte a un altre

objecte. • Optimitza el sistema, només es creen aquells objectes que es

necessiten. Exemple:

L’exemple representa en una aplicació on es mostren imatges de alta resolució. El que fa el proxy és no carregar la imatge HighResolutionImage, fins que sigui necessària.

Conclusions   Finalment les conclusions que podem extre d’aquest treball, són que els patrons de disseny s’ha d’utilitzar perquè permeten fer un software molt més extensible, ampliable i modificable. A més, com hem explicat a l’inici, aquets patrons són solucions a problemes frequents en el disseny del software, i per tant podem reutilitzar-los moltes vegades, i a més ens aseguren que la solució està provada i és bona. Tot i amb això, també hem de vigilar, perquè no tots els problemes són exactament iguals, i a vegades no s’ha d’obligar de posar un patró a un lloc que no és necessari, perquè també pot portar problemes posterior en el software.

Bibliografia  bàsica   http://patronesdediseno.blogspot.com/2009/05/patron-state.html Software achitecture Design Patterns in java – Partha Kuchana