TeoriaPatronesV2 - 2 Antecedente

Patrones de diseo
Mster en Bases de Datos e Internet
TABLA DE CONTENIDOS Presentacin de los patrones de diseo Contextualizacin Programacin Estructurada VS Programacin Orientada a Objetos (POO) Por qu debemos conocer los patrones de diseo? Qu es un patrn? Consecuencias del uso de patrones de diseo Clasificacin de patrones de diseo Objetivos del taller Requisitos Patrones Estructurales El patrn Composite o Composicin El patrn Proxy El patrn Decorator o Decorador El patrn Facade o Fachada El patrn Bridge o Puente* El patrn Adapter o Adaptador* El patrn Flyweight o Objeto Ligero* Patrones de Creacin El patrn Prototype o Prototipo El patrn Singleton o Instancia nica* El patrn Factory Method o Mtodo de fabricacin* El patrn Abstract Factory o Fbrica abstracta* El patrn Builder o Constructor* Patrones de Comportamiento El patrn Chain of Responsability o Cadena de Responsabilidad El patrn State o Estado El patrn Strategy o Estrategia El patrn Observer u Observador El patrn Iterator o Iterador* El patrn Template Method o Plantilla* El patrn Visitor o Visitante* El patrn Command o Comando* El patrn Memento o Recuerdo* El patrn Mediator o Mediador*
Universidad de Zaragoza 2010
3 3 3 7 7 9 10 11 11 12 12 22 29 39 43 45 49 54 54 58 60 63 65 68 68 73 78 82 89 92 95 98 102 104 110
TALLER DE PATRONES DE DISEO

Raquel Trillo Lado
Bibliografa y referencias
-2-
Patrones de diseo
Patrones de diseo
PRESENTACIN DE LOS PATRONES DE DISEO Contextualizacin En general se han venido estudiando de forma separada Ingeniera del Software y Diseo de Algoritmos y Programacin. En Ingeniera del Software se suelen analizar los diferentes ciclos de vida de construccin del software (cascada, espiral, prototipado, etc), metodologa de construccin, explotacin y calidad del software (mtrica, ISO 9000-3, etc.), y modelos de objetos (OMT, UML, etc.). En Diseo de Algoritmos y Programacin se suelen aprender las estructuras de un lenguaje de programacin y sus caractersticas y se implementan en ese lenguaje problemas de diferente ndole. Los Patrones de Diseo actan como puente entre estas dos materias (Ingeniera del Software y Diseo de Algoritmos y Programacin). En palabras de Donald Knuth, First create a solution using sound software engineering techniques, then if needed, introduce small violations of good software engineering pinciples for efficiencys sake, es decir Primero crear una solucin usando tcnicas de ingeniera del software conocidas, luego si es necesario, introducir pequeos camios de los principios de ingeniera del software bien establecidos por razones de eficiencia. Programacin Estructurada VS Programacin Orientada a Objetos (POO) Programacin Estructurada: o Hace unos diez aos que cay en desuso pero todava se sigue usando sobre todo en aplicaciones legadas (legacy). o Comprende fundamentalmente tres fases: Anlisis o captura de requisitos, donde de estudia el problema y se definen las caractersticas que debe tener la solucin. Diseo, donde se construye el algoritmo que resuelve el problema, ajustndose a las caractersticas que se han especificado en la fase de anlisis, basndose en los bloques estructurales secuencia, condicin e iteracin. Por ejemplo mediante la tcnica diagramas de flujo.
Codificacin o implementacin, donde se traduce el diseo a un lenguaje de programacin estructurado como por ejemplo Ada, Pascal, Cobol, Fortan,... En general esta traduccin es bastante directa. o En general la mayora de errores se introducen en la fase de diseo. Adems cuanto ms tarde se detete un error ms problemas suele suponer. Debido a esto se dedica mucho tiempo a esta fase para tratar de evitar errores tempranos. o Supone que los requisitos permanecen inalterados durante todo el ciclo de vida y que se conocen de antemano, de modo que cambios o nuevos requisitos segn Horowitz en 1993 suponen un 70% del coste total en mantenimiento. o Debido a esto se introdujo el ciclo de vida de desarrollo del software en Espiral y el Prototipado en lugar de emplear el desarrollo en Cascada o Cascada con realimentacin. Cascada y Cascada con realimentacin: Fundamentalmente el ciclo de vida del desarrollo del software se realiza en bloques. Por lo tanto, en general, es necesario haber finalizado completamente cada una de las fases antes de pasar a la siguiente. Espiral y Prototipado. En general el ciclo de vida del desarrollo del software es incremental de modo que se van aumentando poco a poco las funcionalidades del sistema. En este tipo de desarrollos existe gran interaccin con el usuario con el fin de disminuir los riesgos. o Separacin del modelo de datos (en general especificado mediante diagramas Entidad-Relacin o mediante ficheros) del modelo de procesos (en general especificado mediante diagramas de flujo). No se encapsulan las operaciones que se pueden realizar sobre los datos. Cambios en uno de ellos pueden provocar fallos en el otro porque no se manejan de forma integrada. Programacin Orientada a Objetos (POO):
-3-
-4-
Patrones de diseo
Patrones de diseo
o Hoy en da es la ms usada aunque en ciertas reas como por ejemplo, implementacin de algoritmos de clculo numrico con gran carga de operaciones, todava se siguen empleando lenguajes estructurados como Fortran. o Se basa en la suposicin de que los objetos del dominio de negocio en el que se est trabajando son las entidades ms estables del sistema de modo que cualquier diseo basado en estos objetos ser ms resistente a los cambios en las especificaciones que puedan darse posteriormente. o Fusiona el/los modelos de datos y los modelos de proceso en clases de objetos. Cada clase lleva incorporados los datos que requiere mediante un conjunto de atributos que representan sus caractersticas y los procesos necesarios para manipularlos mediante un conjunto de mtodos que representan su comportamiento. Adems como ventaja adicional reduce el vaco entre el software y los modelos de negocio, de modo que un modelo de objetos o diagrama de interaccin puede ser fcilmente comprensible por un empresario. o Las fases en el proceso de desarrollo del software son las mismas pero los objetivos, mtodos y tcnicas de cada una de ellas difieren enormemente: Anlisis o captura de requisitos: al igual que en el la programacin estructurada, en esta fase, se estudia el problema y se definen las caractersticas (requisitos) que debe tener la solucin. La diferencia radica en que en este caso el anlisis se centra en el dominio de estudio y tiene como objetivo construir un modelo del mundo real empleando objetos. Dicho modelo suele expresarse mediante el modelo conceptual (diagrama de clases que resuelve el problema pero no representa una descripcin de los componentes software) y diagramas de UML como por ejemplo los casos de uso. (Fase de investigacin) Diseo, el objetivo de esta fase es crear es refinar los modelos obtenidos en el anlisis de modo que se enriquezcan con suficientes detalles prximos a la implementacin. Debido a esto en esta fase es necesario comprobar que se cumplen los requisitos
y asignar responsabilidades e interacciones entre objetos. En esta fase se suelen usar los diagramas de clases (extienden el modelo conceptual de la fase de anlisis enriquecindolo con atributos mtodos y relaciones de interaccin), colaboracin, estado y ciclos de vida de UML. (Fase de bsqueda de solucin lgica) Codificacin o implementacin, al igual que en la programacin estructurada, en esta fase, se traduce el diseo elaborado a un lenguaje de programacin. El lenguaje seleccionado suele ser un lenguaje orientado a objetos como por ejemplo Java, C++, C# o cualquier otro de la familia .Net, SmallTalk, etc.; aunque podra ser otro tipo de lenguaje, como por ejemplo un lenguaje estructurado o un lenguaje funcional (Caml, Erlang, etc.). o Problemas que se deben afrontar: Se debe buscar un diseo reusable y suficientemente flexible a cambios y ampliaciones (escable) a la vez que eficiente. Cules son las clases y objetos que deben intervenir y qu responsabilidad se le asigna a cada uno de ellos? Cul es la granularidad correcta para las clases? Cundo usar la herencia de clases y cundo usar la implementacin de una interfaz? Cmo deben interactuar los objetos?, es decir, cmo intercambian mensajes (o peticiones, request) entre ellos para realizar sus funciones (o responsabilidades)? o Cules son las relaciones entre ellos? o En la metodologa orientada a objetos sigue habiendo problemas fundamentalmente por dos razones: En algunos modelos de diseo existe un uso inadecuado de la encapsulacin de modo que hay una visibilidad de atributos y mtodos incorrecta. Esto suele provocar mayor acoplamiento entre clases del debido, de modo que cambios en una de ellas implica cambios en las dems, es decir mayor dificultad de mantenimiento.
-5-
-6-
Patrones de diseo
Patrones de diseo
En muchos casos existe un vaco entre el anlisis y el diseo y entre el diseo y la implementacin. Esto provoca que los modelos proporcionados en la fase de diseo no sean buenos. Fundamentalmente se dan dos problemas; o bien no se han refinado suficientemente el modelo de modo que el programador debe tomar decisiones de diseo sin tener suficientes conocimientos del dominio; o bien existe una sobreespecificacin de modo que no se proporciona suficente libertar al programador (p.e. especificndole una estructura de datos concreta en donde implementar una lista). Por qu debemos conocer los patrones de diseo? Los diseadores expertos saben que no se debe empezar a resolver todos los problemas desde el principio. Adems tambin conocen diversas soluciones ya probadas que le evitan reinventar la rueda. En general Los diseadores senior normalmente reusan soluciones que ya han trabajado anteriormente y que les han proporcionado buenos resultados. La idea de los patrones de diseo es especificar soluciones buenas y determinar sus caractersticas de algn modo para que puedan ser integradas en los diseos de aplicaciones incluso por diseadores no expertos. Es decir capturar la experiencia para poder usarla eficientemente. Esta idea aplicada hoy al software surgi de la arquitectura: o Christopher Alexander Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. o Christopher Alexander. A Pattern Language: Towns, Buildings, Construction, 1977. The Timeless Way of Building, 1979. Qu es un patrn de diseo? Vctor Gulas Nuevo collar para un perro viejo: Abstraccin, es decir, dada una solucin a un problema especfico se trata de determinar cul es la esencia de la solucin eliminando la parte especfica del contexto, de modo que dicha
esencia pueda ser usada para resolver problemas en contextos diferentes. De este modo se permite el reuso de ideas (diseos) no slo cdigo. Definicin 1: Es una solucin de diseo vlida en diferentes contextos y que ha sido aplicada con xito en el pasado(al menos una vez), la cual se cataloga de modo que pueda ser aplicada en el futuro para resolver nuevos problemas con la misma esencia. O lo que es lo mismo, es una solucin de diseo a un problema no trivial efectiva y reusable (se puede aplicar a un abanico de problemas de diseo en distintas circunstancia). Cmo se cataloga (describe) un patrn de diseo? o Nombre del patrn: Describe un problema de diseo, su solucin y las consecuencias en una o dos palabras. En general se suele especificar en castellano y en ingls. o Clasificacin (campo opcional): Indica de que tipo es el patrn. o Propsito: Indica en dos o tres lneas cul es el problema que intenta resolver el patrn y su propsito. o Otros nombres (Also Known As) (campo opcional): Si existen otros nombres con los que es conocido en la comunidad deberan especificarse. o Motivacin: Describe un ejemplo real de problema (el escenario) que ha sido resuelto con el patrn, especificando la estructura que lo resuelve (la solucin). El escenario ayudar a entender la descripcin ms abstracta que se indicar a continuacin. o Aplicabilidad: Especifica cules son las situaciones donde se puede usar. Adems da ejemplos de cmo puede solucionar problemas de diseos pobres y cmo se pueden reconocer esas situaciones. o Estructura: Especifica mediante notaciones grficas (diagrama de clases, colaboracin y estado fundamentalmente) cul es la solucin al problema de forma abstracta. Esta notacin es sumamente importante pero no es suficiente porque slo captura el producto final del proceso de diseo. Para poder reusar un patrn es necesario tambin recordar las decisiones, alternativas y ventajas e inconvenientes a las que nos dirigen adems de ejemplos que nos puedan ayudar.
-7-
-8-
Patrones de diseo
Patrones de diseo
o Participantes: Lista las clases y objetos que intervienen en la estructura del patrn y especifica cul es la responsabilidad de cada uno de ellos. o Colaboraciones entre participantes: Indica cmo interaccionan los diferentes participantes (clases y objetos) que intervienen en su estructura. o Consecuencias: Describe las ventajas e inconvenientes de la aplicacin del patrn. Adems se indica cmo soporta los objetivos y qu aspectos del sistema pueden variar. o Implementacin: Tcnicas y peligros que conlleva la implementacin del patrn. o Cdigo de ejemplo: Solucin limitada que puede servir de base para implementaciones que usen el patrn. o Usos conocidos (campo opcional): Ejemplos de uso del patrn en sistemas reales. o Patrones relacionados (campo opcional): Listado de patrones relacionados incidiendo en las diferencias de uso y en el posible uso conjunto de estos, es decir con qu patrones debera usarse. Consecuencias del uso de patrones de diseo Los patrones guardan experiencias de diseo orientado a objetos. Adems nombran, evalan y explican diseos que se repiten a menudo en los sistemas orientados a objetos. Facilitan el aprendizaje de diseadores junior, y permiten ahorro de tiempo en la elaboracin de diseos puesto que la toma de decisiones es automtica; debido a que ayudan a escoger alternativas de diseo. Facilitan la comunicacin entre diseadores debido a que establecen un marco de referencia de terminologa y justificacin, puesto que son conocidas las clases que intervienen en ellos y las interacciones entre los objetos. Mejoran la documentacin y el mantenimiento de las aplicaciones. mbito de li i
o El propsito, el cual trata de reflejar lo que hace el patrn. Los patrones pueden ser: De creacin: El prposito del patrn es crear nuevos objetos de forma transparente al sistema. Estructurales: Reflejan la composicin formada por diferentes objetos o clases con un objetivo establecido formando una estructura mayor. Nos indican cmo estructurar en memoria los objetos que intervienen en el problema. De comportamiento: Reflejan la forma de interactuar diferentes objetos o clases distribuyendo su responsabilidad para lograr un objetivo establecido. o El mbito de aplicacin, el cual trata de reflejar a que tipo de elementos se aplica el patrn. Si se trata de relaciones entre clases estas pueden ser establecidas en tiempo de compilacin, mientras que si se trata de relaciones entre objetos que pueden cambiarse de forma dinmica estas tienen que ser establecidas en tiempo de ejecucin.
Clasificacin de los patrones de diseo ms conocidos
Propsito Creacin Factory Method o Factora Estructural Adapter o Adaptador Comportamiento Interpreter o Intrprete Template Method o Plantilla
Clases
Clasificacin de patrones de diseo Se realiza una clasificacin en base a dos criterios:
-9-
-10-
Patrones de diseo
Patrones de diseo
apliacin
Abstract Factory o Fbrica Abstracta Builder o Puente Objetos Prototype o Prototipo Singleton o Instancia nica
Adapter o Adaptador Bridge o Puente Composite o Composicin Decorator o Decorador Facade o Fachada Flyweight o Objeto ligero Proxy
Chain of Responsability o Cadena de responsabilidad Command o Comando Iterator o Iterador Mediator o Mediador Memento o Recuerdo Observer o Observador State o Estado Strategy o Estrategia Visitor o Visitante
PATRONES ESTRUCTURALES Patrn Composite o Composicin Clasificacin: Estructural, debido a que nos indica cmo se organizan los objetos en memoria para obtener una composicin recursiva o lo que es lo mismo una jerarqua en forma de rbol. Propsito: Construir una jerarqua compuesta por dos tipos de objetos: primitivos (nodos hoja) y compuestos (nodos internos). Los objetos compuestos permiten componer objetos primitivos y otros objetos compuestos en estructuras arbitrariamente complejas. A este tipo de jerarquas tambin se le suele llamar composiciones recursivas y jerarquas parte-todo. El patrn permite a los clientes de los objetos composicin tratar de forma uniforme a los objetos primitivos y a las composiciones, es decir trata de igual forma a los nodos hoja como a los rboles o nodos internos. Motivacin: Diseo de un editor grfico en dnde es posible construir objetos complejos a partir de otros ms simples. El cliente que usa esta jerarqua de objetos complejos (en este caso el Editor) est interesado en tratar de forma uniforme a los objetos primitivos y a los compuesto para simplificar su cdigo.
Todos los patrones aqu enumerados han sido ampliamente probados y empleados en diferentes sistemas. Adems no pertenecen a ningn dominio especfico sino que resuelven problemas genricos.
Algunos de los patrones aqu descritos han sido incorporados como estructuras de lenguajes del programacin como por ejemplo el patrn observador en el lenguaje SmallTalk o el patrn Iterador en el lenguaje Java.
Objetivos del taller Identificar las caractersticas fundamentales de los patrones ms conocidos y determinar cundo se deben aplicar. Reproducir y modificar aplicaciones sencillas en las que se aplican patrones de diseo codificados en lenguaje Java. Requisitos Conocimientos previos: Orientacin a objetos y UML. Software: Java 1.5.
o El mtodo draw() en la clase Graphic es un mtodo abstracto, por lo tanto se declara su signatura pero no el cdigo que lo implementa. De este modo se obliga a tener una implementacin de este mtodo en cada
-11-
-12-
Patrones de diseo
Patrones de diseo
una de las subclases. Este mtodo se emplea para tener una interfaz comn disponible para el editor de modo que pueda dibujar cualquier objeto. o La clase Graphic ser una clase abstracta porque tiene al menos un mtodo abstracto. o Para los dems mtodos de la clase Graphic (los que realizan el tratamiento de los hijos) se proporciona una implementacin por defecto: Implementacin que no hace nada (se ignora) Proporciona una excepcin notificando que la operacin no es vlida si se hace por un nodo hoja (puesto que estos la heredan y no la redefinen) Los componentes compuestos redefinen estas operaciones. Estos mtodos no pueden ser abstractos porque de ese modo los nodos hoja no tendran implementacin de ellos (en cualquier caso no la tienen que tener). Por otro lado es necesario poner estos mtodos en la superclase porque sino el Cliente tendra que conocer que existen dos tipos de componentes (primitivos y compuestos). o La flecha etiquetada con graphics representa la navegabilidad, es decir el acceso va a ser siempre del objeto compuesto hacia los hijos de ste. Depende del programador como se realice la implementacin de esta navegabilidad. o Debido a que el rombo est pintado de negro (agregacin en UML) es responsabilidad de la clase Picture borrar todas las instancias hijas si esta se elimina. Si se duda si el rombo debe estar rellenado o no mejor dejarlo sin pintar. o Las notas son sugerencias de cmo codificar los mtodos cuando se realice la programcin del diseo. Aplicabilidad: o Representar composicin recursiva jerrquica, es decir jerarquas todoparte. o Ignorar las diferencias en el tratamiento de objetos primitivos (individuales) y objetos compuestos (composiciones) -13-
Estructura (Generalizacin del problema para aplicarlo a diferentes mbitos):
Participantes: o Component o Componente (Graphic en el ejemplo motivador): Representa el interfaz que se les presenta a los clientes y en general se va a tratar de una clase abstracta. Declara la interfaz comn para los objetos de la composicin (los objetos hojas y los compuestos). Declara la interfaz para regular la composicin, es decir acceder y manipular los componentes hijos. Se suelen dar al menos las tres operaciones de este tipo que se mencionan en la estructura (aadir componente, borrar componente y obtener hijo). Implementa el comportamiento por defecto para los diferentes componentes. o Leaf o Hoja (Rectangle, Line, Text en el ejemplo motivador): Representa un objeto primitivo, es decir un objeto hoja (sin hijos). Define el comportamiento de los objetos primitivos (bsicos) de la composicin.
-14-
Patrones de diseo
Patrones de diseo
o Composite o Composicin (Picture en el ejemplo motivador): Representa un objeto compuesto, es decir el nodo raz del rbol o un nodo interno. Define el comportamiento de los objetos compuestos, es decir de los componentes con hijos. Este tipo de operaciones (operation()) en este tipo de clases en general se definen mediante delegacin en los componentes hijos. Es decir, en general las operaciones de las hojas se definen aqu por delegacin en los hijos. Almacena los componentes hijos. Implementa las operaciones relacionadas con los hijos de la interfaz componente. Estas operaciones son las que van a regular la asociacin. o Client o Cliente: Maneja los objetos de la composicin a travs de la interfaz comn Componente, es decir slo tiene conocimientos de la superclase de la jerarqua de clases.. Colaboraciones entre participantes: o El cliente emplea la interfaz Componente (el API que acta como superclase) para interactuar con los objetos de la composicin: Si se acta sobre una hoja, entonces la peticin es realizada directamente por la instancia correspondiente. Si se acta sobre una composicin, en general s eredirige la peticin del compoenente a sus hijos y se realiza alguna accin adicional (posiblemente antes o despus de rediriguirle la peticin). Consecuencias (ventajas e inconvenientes): o Ventaja 1: Simplifica el cliente debido a que trata a los objetos compuestos y primitivos de forma uniforme. El cliente no conoce, ni debera saber con lo que est tratando. Esto simplifica el cdigo del cliente porque evita tener que escribir funciones con sentencias condicionales (if, case, selects, etc.) para las clases de la composicin.
o Ventaja 2: Facilita la introduccin de nuevos componentes sin afectar al cliente. o Desventaja: Resulta complejo restringir los componenetees de un objeto compuesto, y para ello normalmente es necesario aadir comprobaciones en tiempo de ejecucin. Por ejemplo: Imaginar que la figura compuesta tiene que estar compuesta por un conjunto de figuras elementales todas del mismo tipo. En este caso no es viable una comprobacin en tiempo de compilacin y habra que llevarla a cabo en tiempo de ejecucin. Implementacin: (Variantes del patrn y problemas que pudede desarrollar) o Referencias explcitas al padre, es decir qu pasa si a partir de los hijos nos interesa llegar al padre?: Definir una interfaz para acceder al padre de un componente en la estructura recursiva e implementarlo de la forma apropiada. Varias posibilidades: Obtener la navegacin bidireccional en la relacin children o hijos. Por ejemplo si a partir de un fichero queremos saber cul es su directorio padre.si es que tiene alguno. Una opcin sera poner un atributo padre en la clase Fichero (Componente) y adems aadir ah un mtodo obtenerPadre() que nos devuelve un Directorio. El padre necesitara actualizarse en tiempo de ejecucin al hacerse llamadas al mtodo addChild y removeChild. Esto tiene un efecto desagradable en el API y es que le damos al cliente una referencia a la clase directorio y en principio el cliente no debera saber que existen dos tipos de ficheros diferentes. Establecer una relacin recursiva de Fichero consigo mismo de cardinalidad (0..1) de modo que se evite que el cliente tenga que conocer la estructura de directorios. El problema aqu es que no se est representando lo mismo y as un componente compuesto podra ser hijo de un componente primitivo. Debido a esto tenemos que reforzar el modelo para evitarlo. El refuerzo del
-15-
-16-
Patrones de diseo
Patrones de diseo
modelo se consigue mediante restricciones que tendrn que ser comprobadas en tiempo de ejecucin: o En general el padre debe ser un objeto compuesto (Directorio), para evitar que un nodo hoja (fichero normal) sea el padre de otro nodo (fichero normal o directorio). o El padre de un objeto debe tener como uno de sus hijos al objeto. La forma ms sencilla de conseguir esta restriccin es cambiar slo el padre de un objeto cuando este siendo aadido o borrado a una composicin. o Comparticin de componentes: Cundo se trabaja con objetos muy pesado que no poseen estado puede interesarnos compartirlos de modo que la representacin incial en rbol deja de serlo porque se produce una comparticin de nodos. La representacin de rbol pasa a ser la de un grafo dirigido acclico. Por ejemplo si trabajamos con ficheros muy grandes y queremos tenerlos accesibles desde diferentes puntos podremos crear accesos directos a estos evitando duplicarlos.
composicin es que el cliente no sea consciente de qu objetos hojas y compuestos se estn usando. Para lograrlo la clase componente tiene que definir tantas operaciones comunes para la composicin y las hojas como sea posible. En general la interfaz proporciona implementaciones por defecto que se reescribirn en la subclase. Este objetivo a veces entra en conflicto con el principio de diseo de la jerarqua de clases que indica que una clase slo debera definir operaciones que son significativas a sus subclases, y en este caso hay operaciones necesarias para los componentes que no tienen sentido para las subclases. Adems crea un conflicto de seguridad porque los clientes pueden tratar de hacer operaciones poco significativas para las hojas. Cmo puede la clase componente proporcionar una implementacin por defecto para ellas? Es necesario ser creativos, por ejemplo, la interfaz para acceder a los hijos es fundamental para los objetos compuestos pero no es necesaria para los objetos hoja. Sin embargo si vemos la hoja como un componenete que tienes hijos podemos definir una operacin por defecto para el acceso a los hijos en la superclase donde no se devuelve ningn hijo. Las hojas usarn la implementacin por defecto y la clase compuesta la refinar. o Declaracin de mtodos para la manipulacin de los hijos: Se proporciona una implementacin por defecto: Implementacin que no hace nada (se ignora) Proporciona una excepcin notificando que la operacin no es
En este caso hay que tener cuidado con la implementacin de las operaciones pues por ejemplo la operacin de obtener tamao tal y como la habamos planteado inicialmente aqu nos dara como resultado para el directorio Raiz 1300 bytes y esto no es correcto. Este tipo de implementaciones todava se complicara ms si quisisemos tener la navegacin en los dos niveles, es decir guardar referencias a las listas de los padres. o Maximizar la interfaz Component Uno de (Decisin los que balancea patrn
vlida si se hace por un nodo hoja (puesto que estos la heredan y no la redefinen) Los componentes compuestos en general redefinen estas operaciones y los simples las heredan. o Lista de Componentes en Component? En algunas ocasiones se ingnora la clase Composite y se sustituye el modelado por:
Seguridad-Transparencia): -17-
objetivos
del
-18-
Patrones de diseo
Patrones de diseo
haberse modificado desde la ltima vez que se realiz la operacin obtener tamao. El uso de las cachs lleva asociado el problema de su actualizacin. Cambios en los componentes hijos requeiren la invalidacin de las cachs de sus padres. De modo que este tipo de implementaciones funcionar mejor cuando existen referencias a los padres. o Responsabilidad de borrado. En general cuando no existe recolector de basura lo ms sencillo es hacer responsable del borrado de los hijos al Esto incurre en una penalizacin de espacio para todas las hojas, porque tienen reservado el espacio para tener hijos aunque estas nunca lo usen. Esta implementacin es ms sencilla (hay una clase menos) pero slo vale la pena si hay relativamente pocos nodo hoja en la estructura. Si se usa esta implementacin del patrn la asociacin padre encaja con mayor facilidad haciendo la asociacin children bidireccional. Sin embargo se corre el peligro de que se use el espacio de los hijos en los nodo hoja para haer cualquier cosa. o Ordenacin de hijos: Puede disearse un orden de los hijos de un objeto compuestos. Por ejemplo en el editor esto puede ser interesante para reflejar la superposicin de las figuras y en el ejemplo de los ficheros para reflejar la antigedad de los ficheros creados. Otro ejemplo en el que podra resultar de utilidad es cuando la composicin refleje rboles sintcticos. La ordenacin en los hijos se logra mediante una restriccin (ORDER) en la asociacin children o hijos. Esta restriccin deber tenerse en cuenta a la hora de realizar la implementacin. o Mejora de rendimiento usando cachs en objeto Composicin. En las implementaciones del patrn es comn usar una cach a nivel del objeto compuesto que guarde informacin acerca de los hijos. Por ejemplo cuando estamos tratando de obtener el tamao de un directorio que contiene otros directorios, si realizamos la operacin tal y como la hemos implementado se llama siempre a las operaciones de todos los descendientes a pesar de que alguna parte de la estructura puede no objeto compuesto que los contiene de modo que si se borra el objeto compuesto este debe eliminar los hijos. Una excepcin a esta regla se produce cuando los objetos hijos pueden ser compartidos por varios objetos compuestos. En Java, como tiene recolector de basura, si se elimina un fichero de un objeto directorio simplemente bastar con romper la asociacin y el recolector de basura liberar la memoria posteriormente del objeto eliminado de la asociacin si este no est referenciado por otro objeto compuesto sin tener que programar mecanismos adicionales. o Estructura de datos para almacenar hijos: En la fase de diseo no se debe obligar a una estructura de datos concreta (listas enlazadas, arrays, rboles, tablas hash, etc. ) esa eleccin deber tomarse en la implementacin y depender de la eficiencia. Cdigo de ejemplo y ejercicios: o Ejercicio 1: Obtener una representacin de los rboles de directorios y los ficheros que estos contienen permitindonos conocer el tamao que ocupan en disco. Recordad que en muchos lenguajes los directorios se tratan como ficheros. (Pista: Fichero, FicheroNormal y Directorio). o Ejercicio 2: Implementar la clase Cliente. El cliente debe crear la siguiente estructura de directorios:
-19-
-20-
Patrones de diseo
Patrones de diseo
La tentacin directa una vez hemos definido esto es implementar cada una de las clases que aparece en el diagrama de forma independiente. Si pensamos en mayor profundidad vemos que existe cdigo muy parecido entre por ejemplo los frames y las columnas y tambin entre los caracteres y las imgenes. Pensar como se podra realizar en diseo considerando el patrn composicin puesto que hay elementos que no pueden contener a otros A continuacin se debe mostrar por pantalla el tamao total del fichero raz, elimiar el directorio usr y elininar el fichero b. Finalmente se debe obtener de nuevo por pantalla el tamao del fichero (directorio) raz. o Ejercicio 3: Probar la clases anteriores y realizar un diagrama de secuencia indicando como fluyen los mensajes entre los objetos. y hacer un diagrama de secuencia indicando como fluyen los mensajes entre lso diferentes objetos. o Ejercicio 4: Aumentar el diseo anterior permitiendo la asociacin padre. o Ejercicio 5: Pensar en la estructura de un documento en un editor de textos. Podra ser algo como lo que se indica a continuacin: o Documento Patrn Proxy Clasificacin: Estructural, debido a que nos indica cmo se organizan los objetos en memoria. Otros nombres: subrogado o subrogate. Propsito: Proporcionar un subrrogado o intermediario de un objeto para controlar su acceso. El intermediario (o subrogado) controla el acceso al objeto que estamos considerando. * Pgina * * * * Motivacin: o Problema: En el contexto de un editor grfico consideremos los objetos grficos (imgenes) que puede haber dentro de un documento. Frame Imagen * En general no todas las imgenes van a tener que cargarse cuando se abra el documento porque depende que zona estemos visualizando har que se muestren o no. La apertura del documento debera ser rpida y en general las imgenes suelen ser bastante pesadas, sobre todo si son de gran tamao. * Caracter o Solucin: Debido a que no es necesario crear todos los objetos con imgenes nada ms abrir el documento porque no todas son visibles se puede hacer carga bajo demanda. * Columna elementos del documento mientras otros si pueden.. Patrones relacionados: Decorador, Iterador (realizar la navegacin entre los hijos), Objeto ligero (para compartir componentes), cadena de responsabilidad, Visitante (localiza operaciones y comportamientos que deberan ser distribuidos a lo largo de la composicin y en las clases hojas).
* Lnea Texto
-21-
-22-
Patrones de diseo
Patrones de diseo
La implementacin de la carga bajo demanda por parte del editor hace que este se complique, adems la funcionalidad de carga bajo demanda puede ser requerida por diversos mdulos. Modificar la clase imagen para que esta sepa cuando tiene que cargarse en funcin de un estado interno tampoco parece una buena opcin porque esta clase se puede usar en otras aplicaciones donde no se requiere la carga bajo demanda. Crear una copia de la clase imagen y modificarla para permitir la carga bajo demanda tampoco se considera un buen diseo porque implica tener cdigo duplicado con todas las desventajas que esto conlleva. Para evitar complicar el editor y dar al objeto imagen responsabilidades que no le incumben (aadir funcionalidad adicional a la clase imagen), se puede emplear un objeto proxy. Este objeto se comportar como la imagen de cara al editor pero ser responsable de la carga bajo demanda de la imagen. En el proxy se pude almacenar el nombre del fichero como una referencia al objeto real (suponiendo que la imagen est en disco). La clase ImageProxy cuando puede resolver las operaciones por si misma las resuelve y proporciona el resultado (por ejemplo devolver la extencin o tamao del fichero de la imagen), en caso de que se le requiera una operacin que implique la carga de la imagen entonces la cargar en ese momento y delegar la operacin correpondiente en el objeto imagen. Aplicabilidad: o Cuando exista una forma de referencia a un objeto ms sofisticada que un simple puntero, como por ejemplo las siguientes: Proxy remoto: El proxy representa en local a un objeto remoto. Este tipo de proxies es til en aplicaciones distribuidas. Proxy virtual: El proxy crea objetos costosos bajo demanda. Proxy de proteccin: El proxy controla el acceso a un El editor interactuar con el proxy, el cual delega en la imagen si no puede resolver la operacin por si mismo y se encarga de realizar la carga bajo demanda. Para que el editor no tenga conocimiento de la existencia de proxies se crea una clase abstracta que propociona los mtodos de la imagen al editor, actuando como interfaz. Esta clase abstracta actuar como superclase del objeto proxy y del real. determinado recurso (objeto original). Por ejemplo si disponemos de una clase en concreto, denominmosla X, puede que esta no realice la comprobacin de los parmetros que llaman a sus mtodos. En muchas aplicaciones esta comprobacin no ser necesaria pero en algunas otras puede ser requerido.
-23-
-24-
Patrones de diseo
Patrones de diseo
No se deberan incorporar las comprobaciones a la clase porque esto la hara ms pesada y en muchos casos no se necesitaran (depende del cliente). En lugar de la opcin anterior el proxy puede realizar la comprobacin de los parmetros. Si los parmetros son correctos el proxy delega la llamada en el objeto y sino trata el problema. Contar las veces que se accede a determinados mtodos para determinar cuales son las operaciones ms demandadas o tener uncontador de referencias al objeto real para controlar la concurrencia al acceder a l. Estructura:
Proporcioan la misma interfaz que el sujeto (Subject) para que un proxy pueda ser substituido por el sujeto real. Controla el acceso al objeto real y puede ser el responsable de su creacin y borrado, por ejemplo el proxy podra decidir liberar de memoria un determinado objeto (en el ejemplo motivador la Imagen) porque no se est usando en ese momento. Ojo con esto porque puede ser que luego vuelvas a necesitar el objeto y la creacin del objeto tambin consume tiempo. Adems en funcin del tipo del proxy del que se trate: Es el responsable de codificar una peticin y sus argumentos y enviarla al objeto remoto (Proxy Remoto) disponible en una determinada direccin. Actu como cach de informacin del objeto real para evitar en la medida de lo posible el acceso a este. (Proxy Virtual o Cach). Comprueba la correccin de los permisos y/o parmetros de peticiones. (Proxy de proteccin). o Subject (Graphic): Define la interfaz comn del Proxy y el RealSubject de modo que el proxy se pueda usar en cualquier lugar donde se espera un sujeto real. o RealSubject (Image): Define el objeto real que est siendo representado por el proxy. Colaboraciones entre participantes: Dependiendo de la clase de proxy, el objeto proxy realizar una serie de operaciones y redirigir peticiones al objeto real que est representando. Desde el punto de vista del cliente el proxy y el sujeto real forman un objeto compuesto en donde el proxy envuelve al objeto real.
Participantes: o Proxy (ImageProxy): Mantiene una referencia al objeto real (RealSubject). El proxy puede referirse a Sujeto o Subject si las interfaces del Sujeto y SujetoReal o RealSubject son las mismas.
Consecuencias: o Introduce un nivel de indireccin en las peticiones que requieren acceder al objeto, lo que conlleva a una pequea penalizacin que en general puede permitirse. o Adems dependiendo del tipo de Proxy:
-25-
-26-
Patrones de diseo
Patrones de diseo
Los proxies remotos ocultan el lugar donde residen los objetos reales. Los proxies virtuales realizan optimizaciones como por ejemplo la carga bajo demanda o cacheado de resultados para evitar diferir la operacin al sujeto real. Los proxies de proteccin permiten realizar diversas tareas ante el acceso a un objeto como por ejemplo comprobar los parmetros o permisos. o Se pueden usar tambin en copias bajo demanda (copy-on-write o creacin bajo demanda), retrasando la replicacin de un objeto hasta que este cambia: Crear una copia de un objeto complejo y de gran tamao puede ser una operacin cara. Adems si la copia nunca se modifica no hay necesidad de realizar ese gasto, usando un proxy se puede posponer el proceso de copia hasta que sea requerido un cambio en la copia. Para copiar bajo demanda es necesario que el objeto real tenga un contador. La copia del objeto (solicitada a travs del proxy) no har nada ms que incrementar ese contador de referencias. Solamente cuando se requiera un cambio el proxy hace una copia y el contador se decrementa. Adems cuando la referencia es cero el sujeto real se borra. o Inicialmente la situacin es esta: Implementacin: o Los proxies no siempre necesitan conocer el tipo del sujeto real con el que estn trabajando. Si una clase proxy puede tratar con el sujeto real slo conociendo una interfaz abstracta entonces no hay necesidad de que lo conozca y para instanciar el objeto real pueden emplear una factora si esta est disponible. o Es necesario que los proxies tengan algn mecanismo para referenciar cul es el objeto real que les corresponde antes de instanciarlo. Patrones relacionados: o Adaptador o Adapter: Un adaptador proporciona diferente interfaz al del sujeto real (el objeto que adapta). En contraste un rpoxy proporciona la o Cuando se solicita una copia la accin ser crear un nuevo proxy sobre el mismo sujeto real: misma interfaz que el sujeto real. Sin embargo un proxy usado para la proteccin de acceso pudiera no logra una operacin que el sujeto si logra por lo tanto su funcionalidad puede ser efectivamente un subconjunto de la funcionalidad del objeto real. o Problemas de esto: Es necesario que el proxy sepa que mtodos modifican el estado del sujeto real y tambin es necesario introducir un contador en el sujeto real. o Cuando se modifique alguna de las copias el proxy solicitar la creacin de la copia al objeto real.
-27-
-28-
Patrones de diseo
Patrones de diseo
o Decorador o decorator: Aunque pueden tener implementaciones similares a los proxies tiene diferente propsito. Un decorador aade ms responsabilidades al objeto en tiempo de ejecucin mientras que un proxy controla el acceso a l. En cualquier caso variantes del patrn proxy son implementadas como decoradores como por ejemplo un proxy de proteccin con varios niveles de control. Por otro lado los proxies remotos y virtuales mantienen una referencia indirecta al sujeto real (como por ejemplo la direccin del servicio o el nombre de la imagen) y los decoradores mantienen una referencia directa. Cdigo de ejemplo: o Ejercicio1: Probar el cdigo proporcionado que simula el
ventanas de la misma forma, posean las funcionalidades adicionales o no por lo que no es viable modificar la clase Ventana. La modificacin de la clase Ventana supondra cargas adecionales para otras aplicaciones que no requieren esas funcionalidades. o Solucin 1: La alternativa ms directa para modelar este problema es usar la herencia para extender las responsabilidades de la clase Ventana y crear una subclase VentanaConScroll, otra VentanaActiva y otra ventanaActivaConScroll. Esta solucin es bastante ineficiente porque se produce una explosin de clases a medida que se quieran proporcionar nuevas funcionalidades. Esta solucin tambin es inflexible puesto que es esttica y un objeto es difcil que puede transformarse de una clase a otra dinmicamente (en tiempo de ejecucin); es decir, es una slucin esttica hecha en tiempo de compilacin. Esta solucin provoca herencia mltiple que en determinados lenguajes de programacin puede ser difcil de implementar.
comportamiento del patrn y elaborar un diagrama de clases con su estructura. De qu tipo de proxy se trata y por qu? o Ejercico 2: Realizar un diagrama de secuencia del cdigo proporcionado. Patrn Decorator o Decorador Clasificacin: Estructural, debido a que nos indica cmo se establecen las relaciones entre los diferentes elementos en memoria. Otros nombres: wrapper. Propsito: Aadir responsabilidades o caractersticas a un objeto en concreto dinmicamente, proporcionando una alternativa flexible a la extensin de una clase para aumentar la funcionalidad. Motivacin: o Problema: En el contexto de un editor de texto consideremos las ventanas grficas que muestran el documento. Se desea que las ventanas donde se muestra el documento puedan proporcionar un borde que estar activo cuando se est trabajando sobre esa ventana y una barra de desplazamiento o scroll si el documento es de un tamao considerable. Se desea aadir esa responsabilidad a objetos en concreto no a una clase. Adems se pretende que estos dos funcionalidades adicionales no supongan modificar el cliente, es decir que los clientes traten las
o Solucin 2: Debido a los problemas que supone la creacin de nuevas subclases se opta por encapsular el objeto base (ventana o TextView) dentro de otro objeto que aade las nuevas funcionalidades (objeto decorador). Adems como no se desea que el cliente diferencie entre
-29-
-30-
Patrones de diseo
Patrones de diseo
objetos sin decorar y decorados se (visualComponent).
considera una interfaz comn
aadir nuevas funcionalidades que no estn disponibles en el objeto sin decorar (scroolTo, drawBorder). Los clientes de los componentes visuales no hacen distincin entre los componentes decorados y sin decorar. Aplicabilidad: o Aadir eliminar responsabilidades de objetos de forma dinmica y transparente, sobre todo cuando no es prctico el uso de la herencia debido a su inflexibilidad y explosin de clases. Estructura:
El decorador redirige las peticiones al objeto base y aade las nuevas funcionalidades antes o despus de la redireccin. Pueden existir diferentes tipos de funcionalidades que se desean aadir (en el ejemplo motivador en concreto son dos: Scroll y borde activo) por ello se considera una interfaz (Decorador) que las engloba a todas y que acta como mecanismo encapsulador. Esta interfaz puede especializarse proporcionando el comportamiento de las diferentes funcionalidades.
Participantes: o Componente o Component: Define la interfaz para que el cliente trate de forma uniforme objetos decorados que objetos bsicos. o ComponeneteConreto o ConcreteComponent: Define un objeto al cual se le pueden agregar responsabilidades adicionales.
La superclase Decorator impelementa la interfaz del componente visual, redirigiendo los mtodos al componente que encapsula. Adems la transparencia de la interfaz VisualComponent permite el anidamiento de decoradores permitiendo un nmero no limitado de nuevas funcionalidades. Las subclases decoradoras refinan los mtodos del componente aadiendo responsabilidades. Adems las subclases pueden
o Decorador o Decorator: Mantiene una referencia al componente encapsulado (asociado) e implementa la interfaz de la superclase Componente. El Decorador delega en el componente asociado las operaciones de la interfaz. o DecoradorConcreto o ConcreteDecorator: Aade funcionalidades
(responsabilidades) al componente (refinamiento). Colaboraciones entre participantes:
-31-
-32-
Patrones de diseo
Patrones de diseo
o El decorador redirige las peticiones al componente asociado y opcionalmente puede realizar tareas adicionales antes o/y despus de redirigir la peticin. Consecuencias: o Es una estructura ms flexible que la herencia (la cual es esttica) puesto que es configurable en tiempo de ejecucin y evita la herencia mltiple. Adems con el decorador las responsabiliddades pueden ser aadidas o eliminadas y se evita la herencia mltiple. o Evita la aparicin de clases con muchas responsabilidades en las clases superiores de la jerarqua permitiendo incorporar las responsabilidades incrementalmente. Esto tiene la ventaja aadida de que no es necesario pagar un coste por funcionalidades no requeridas. Adems tambin es sencillo definir nuevos tipos de decoradores independientemente de las clases de objetos que extienden por ejemplo para extensiones no previstas inicialmente. o Puede provocar problemas con la identidad de los objetos. Un decorador acta como un envoltorio transparente de un objeto componente pero desde el pundo de vista de la identidad de los objetos un componente decorado no es idntico al componente en si mismo puesto que no tienen la misma referencia. Por lo tanto no se debera confiar en la identidad de los objetos cuando usas decoradores. Cundo dos objetos son el mismo, cuando tienen la misma referencia o cuamdno forman parte del mismo objeto compuesto, el cual se construye sobre el mismo objeto base? Se puede plantear una solucin y usar un identificador calve nico (atributo id) para identificar los objetos de modo que no se emplee la referencia. Ntese que el identificador slo lo tendra el objeto bsico (TextView) y que los decoradores lo heredaran. Es decir se pondra un atributo _clave en el TextView o en Unidad y un mtodo abstracto obtenerId(). El componente bsico devuelve el nomber en obtenerId() y los decoradores delegan en el componente esa operacin.
o Puede provocar la existencia de un gran nmero de objetos pequeos y adems se producen pequeas penalizaciones por cada nivel de indireccin introducido. Implementacin: o El decorador debe cumplir la interfaz de la clase Componente para que el cliente no distinga entre objetos bsicos y decorados. o Cuando slo exista la posibilidad de aadir un tipo de funcionalidad a los objetos bsicos se puede omitir la clase abstracta Decorador. En general esto no es as y adems conviene ponerla porque proporciona mayor flexibilidad al diseo. o Se debe mantener la clase Componente o Component ligera. As la definicin de los datos de representacin debera hacerse en las subclases porque sino se har a las clases decoradoras muy pesadas para poder ser usadas de forma anidada. Adems aadir demasiada funcionalidad en la interfaz Componente aumenta la probabilidad de que se pongan caractersticas que para un caso en concreto no se utilicen. o Patrn Decorador vs patrn Estrategia: En este caso se le estn aadiendo nuevas pieles (Decorador) que aumentan la funcionalida al objeto base. Si en lugar de aadir funcionalidades se quisiese cambiar el medio de conseguir la funcionalidad del objeto base entonces se empleara el patrn Estrategia. Adems el patrn estrategia se debe aplicar tambin cuando la clase Component es demasiado pesada. En el patrn decorador el componente no tiene que saber nada de los decoradores, es decir los decoradores son transparentes al componente debido a que slo se cambia un componente desde el exterior. En el patrn estrategia el componente en si mismo conoce sus posibles extensiones. Adems tiene referencias y mantiene las correspondientes estrategias. Patrones relacionados:
-33-
-34-
Patrones de diseo
Patrones de diseo
o Adaptador: Un decorador es diferente de un adpatador en el sentido en que el decorador slo cambia las responsabilidades del objeto, no su interfaz. Un adaptador proporciona una interfaz completamente nueva. o Composicin: Un decorador puede verse como una composicin degenerada con solo un componente (un hijo). Sin embargo un decorador aade responsabilidades no es una agregacin de objetos como lo es la composicin. o Estrategia: El decorador cambia la piel del objeto y la estrategia su modo de realizar las operaciones. Son dos alternativas diferentes de cambiar un objeto. Cdigo de ejemplo: o Ejercicio 1: Crear un modelo e implementarlo para el siguiente escenario. Se consideran Unidades (soldados) de un juego de estrategia. Estas unidades pueden defender, atacar o moverse. Adems tendrn un mtodo descripcin que nos propocionar un String con la informacin de las unidades (nombre y tipos de mtodos que emplea). Las unidades en un principio son SoldadosRaso (es decir capacidad de ataque, defensa y movimiento 1) pero a medida que ganan experiencia pueden obtener complementos (escudos y pistolas) que le ayuden a desarrollar su misin. Por cada escudo que se adquiera la capacidad de defensa se multiplica por dos y por cada pistola la capacidad de ataque se multiplica por 2 (Pista: Fichero, FicheroNormal y Directorio). o Ejercicio 2: Implementa una clase Cliente de la estructura anterior que poseea el siguiente mtodo: + Unidad combate(Unidad atacante, Unidad defensor) De modo que si la capacidad de ataque de la unidad atacante es mayor que la capacidad de defensa de la unidad defensor, entonces el ganador del combate es el atacante (return atacante), en caso contrario el ganador del combate es el defensor (return defensor). o Ejercicio 3: Adapta el siguiente cdigo para probar las clases anteriores:
} ... }
Public static void main (String argv[]){ Cliente c = new Cliente(); Unidad ryan = new Soldado (Ryan); Unidad rambo = new Pistola( new Escudo( new Soldado( Rambo))); System.out.prinln(Si + Rambo.obtenerNombre() + ataca a + Ryan.obtenerNombre() + , el vencedor es + c.combate(rambo, ryan).obtenerNombre()); } } o Ejercicio 4: Si se desease disponer del mtodo suprimirComplemento dnde sera ms adecuado hacerlo disponible?. Analizar las siguientes opciones. Opcin 1: Nueva responsabilidad en la clase Complemento:
abstract class Complemento extends Unidad { ... public Unidad suprime_complemento(Complemento complemento) { if (complemento == this) return _sujeto; else { if (_sujeto instanceof Complemento) _sujeto = ((Complemento) _sujeto) .suprime_complemento(complemento); return this; }
Public class Main{
Unidad p = new Escudo( new Soldado("mi_unidad") ); -35-36-
Patrones de diseo
Patrones de diseo
Unidad mi_unidad = new Pistola(p); mi_unidad = ((Complemento) mi_unidad) .suprime_complemento((Complemento) p); Opcin 2: Tratamiento uniforme de Unidades y Complementos:
abstract class Unidad { ... public Unidad suprime_complemento(Unidad complemento) { return this; } ... } abstract class Complemento extends Unidad { ... public Unidad suprime_complemento(Unidad complemento) { if (complemento == this) return _sujeto; else { _sujeto = _sujeto.suprime_complemento(complemento); return this; } } ... } Unidad p = new Escudo( new Soldado("mi_unidad") ); Unidad mi_unidad = new Pistola(p); mi_unidad = mi_unidad.suprime_complemento(p); } } ... } }
...
abstract class Complemento extends Unidad { ... protected abstract String tipo(); public Unidad suprime_complemento(String cual) { if (tipo().equals(cual)) return _sujeto; else { _sujeto = _sujeto.suprime_complemento(cual); return this; }
class Escudo extends Complemento { ... protected String tipo() { return "ESCUDO"; } ...
class Pistola extends Complemento { ... protected String tipo() { return "PISTOLA"; } ...
Unidad mi_unidad = new Pistola(new Escudo(new Soldado("mi_unidad"))); mi_unidad = mi_unidad.suprime_complemento("ESCUDO");
o Ejercicio 5: Si se desease pasar como parmetro un identificador del tipo de complemento que se desea suprimir al mtodo suprimirComplemento cmo habra que modificar la implementacin anterior?.
abstract class Unidad { ... public Unidad suprime_complemento(String cual) { return this; }
Nota: En ocasiones nos puede interesar tener identificado el complemento que se manipula por ejemplo para borrarlo. Por ejemplo si una Unidad dispone de dos pistolas igual nos interesa -38-
-37-
Patrones de diseo
Patrones de diseo
eliminar la que adquiri en primer lugar y no una cualquiera de ellas (como lo hace el mtodo anterior.). En este caso en el constructor identificador. Patrn Facade o Fachada Clasificacin: Estructural. Propsito: Proporcionar una interfaz nica para un conjunto de interfaces en un subsistema. El objetivo es definir la interfaz de nivel ms alto de las operaciones que realiza el subsistema para que sea ms sencillo el usarlo por otros mdulos o subsistemas diferentes, es decir facilitar el acceso. Motivacin: o En general la divisin de un sistema complejo en subsistemas facilita el poder abordar el problema y reduce la complejidad. o El objetivo que se persigue es minimizar las comunicaciones y puntos de acceso de un subsistema a otro de modo que la dependencia entre subsistemas se reduzca. Es decir, disminuir el acoplamiento entre sistemas. o Problema: En el contexto del desarrollo de un entorno de programacin integrado por ejemplo para el lenguaje C++; se desea disponer de una herramienta debuger por lo que se requerir hacer uso de un compilador. o Solucin 1: Conocer los diferentes mdulos y componentes del compilador (Scanner, Parser, etc.) de modo que pueda hacer llamadas a cada uno de ellos. o Solucin 2: Usar el compilador como una caja negra de modo que los cambios en la estructura del compilador o sus interfaces internas no afecten, es decir no se propaguen ms all del punto de conexin que se proporciona que ser la fachada. del complemento ser necesario indicar un
o As se reducen las dependencias entre los mdulos y se aisla a los posibles clientes de los cambios internos del mdulo. Sin embargo el emplear una fachada no impide que existan aplicaciones especializadas que puedan acceder a las clases del mdulo directamente, es decir la fachada no oculta las funcionalidades de ms bajo nivel. Aplicabilidad:
-39-
-40-
Patrones de diseo
Patrones de diseo
o Necesidad de una interfaz ms simple para un subsistema complejo debido a que algunos clientes no necesitan conocer todo. Es decir a los clientes slo se le proporciona aquello que necesitan. La fachada proporciona un punto de vista simple por defecto del subsistema y slo los clientes que necesiten mayor grado de personalizacin accedern directamente al subsistema sin hacerlo mediante la fachada. o Necesidad de reducir las dependencias entre las clases que implementan un subsistema y sus clientes. Es decir, intentar acotar que un cambio en el subsistema no se propague al exterior promoviendo la independencia de los subsistemas y su portabilidad. o Estructuracin en capas de los subsistemas, de modo que cada fachada se corresponde con un punto de entrada a cada nivel. Estructura:
Colaboraciones entre participantes: Los clientes se comunican con el subsistema enviando peticiones a la fachada, la cual redirige las peticiones a los objetos apropiados. Aunque las clases del subsistema son las que realizan el trabajo real, la fachada puede tener que realizar alguna operacin por si misma como por ejemplo traducir sus interfaces a las interfaces del subsystema (delegacin y adaptacin de protocolos).
Consecuencias: o Reduce el acomplamiento entre clientes y subsistemas facilitando su uso y aislando la implementacin de modo que se pueden realizar cambios en esta sin alterar el cliente. Adems se reduce el nmero de objetos que el cliente debe conocer. o Los objetos del subsistema no conocen a la fachada por lo que es posible tener diferentes fachadas que proporcionen acceso a diferentes tipos (perfiles) de usuario. o No impide que los clientes accedan a las clases del subsistema si resulta necesario.
Implementacin: o La reduccin del acoplamiento entre clientes y subsistemas puede reducirse incluso ms si en lugar de emplear una fachada concreta la fachada es una clase abstracta de la que se proporcionan diferentes implementaciones del subsistema. Para instanciar una fachada en concreto para un determinado cliente se debera usar una factora.
Participantes: o Fachada o Facade (Compiler): Conoce las clases del subsistema responsables de una determinada operacin que se les est ofertando a los clientes. Cuando un cliente le realiza una peticin delega las peticiones en los objetos apropiados del subsistema; es decir, las clases realizan el proceso, la fachada no asume la responsabilidad. o Clases del subsistema (Scanner, Parser, ProgramNode, etc.):
Patrones relacionados: o Mediador o Mediator: Al igual que la fachada el mediador abstrae la funcionalidad de clases existentes. Sin embargo, el propsito del mediador es abstraer las comunicaciones arbitrarias que se producen entre los objetos del subsistema centralizando a menudo una determinada funcionalidad que no pertenece a ningn otro objeto del subsistema. Adems en el patrn mediador las clases del subsistema conocen a la clase mediadora y realizan la comunicacin con el mediador en lugar de hacerlo unas con otras directamente. Por el contrario los objetos del
Implementan la funcionalidad del subsistema realizando el trabajo solicitado por la Fachada. Estas clases no conocen la existencia de la Fachada (no tienen referencias a la fachada).
-41-
-42-
Patrones de diseo
Patrones de diseo
subsistema no tienen conocimiento de la fachada y esta no define nueva funcionalidad. o Instancia nica o Singleton: En general slo es necesario disponer de un objeto fachada (si en la fachada no se almacena estado) por lo tanto se suele usar este patrn en combinacin con el patrn instancia nica. Patrn Bridge o Puente Clasificacin: Estructural. Propsito: Desacoplar una abstraccin de su implementacin de forma que cada una de ellas pueda variar independientemente. Motivacin: o En general para realizar la implementacin de abstracciones se suele emplear la herencia. El problema que genera la herencia es que asocia de forma permanente la implementacin y la abstraccin. o Problema: En un entorno de ventanas que puede funcionar en dos sistemas de ventanas diferentes (por ejemplo Windows y Mac), la abstraccin Ventana permite desarrollar aplicaciones que funcionen en los dos sistemas pero la implementacin de esta abstraccin deber ser distinta en uno que en otro. o Solucin 1: La solucin directa sera implementar la clase abstracta Ventana con subclases que implementen la abstraccin en cada entorno. Esta solucin genera los siguientes problemas: Es complejo poder extender la abstraccin porque implica modificar cada una de las subclases. Existen problemas de dependencia de la plataforma.
o Solucin 2: Separar en jerarquas diferentes la abstraccin de la ventana y sus implementaciones dependientes de la plataforma.
o De este modo todas las operaciones utilizadas en las subclases de Windows se definen como mtodos abstractos de la Interfaz WindowImp (puente o brige). Aplicabilidad: o Desacoplar abstracciones de sus implementaciones permitiendo el cambio en tiempo de ejecucin. o Necesidad de extender mediante herencia tanto la abstraccin como sus implementaciones. o El cambio en la implementacin de una abstraccin no debera afectar a los clientes. o Necesidad de compartir una misma implementacin. Estructura:
-43-
-44-
Patrones de diseo
Patrones de diseo
Si la abstraccin conoce la jerarqua de implementadores entonces puede crear el implementador en el constructor en base a sus parmetros. Si la abstraccin no conoce la jerarqua de implementadores entonces deber delegar en otro objeto que se encargue de proporcionarle el implementador concreto, por ejemplo una Factora. o Comparticin de implementadores. o Herencia mltiple. Participantes: o Abstraccin (Abstraction): Define la interfaz de la abstraccin y mantiene la referencia al objeto implementador. o Abstraccin refinada (RefinedAbstraction): Extiende la interfaz definida por la abstraccin. o Implementador con la interfaz (Implementor): de la Define la interfaz para los Patrn Adapter o Adaptador Clasificacin: Estructural. Propsito: El adaptador o wrapper permite la colaboracin entre clases con interfaces incompatibles. Motivacin: o Reutilizar clases con interfaces incompatibles. o Problema: En el contexto de un editor grfico se manipulan objetos que cumplen una determinada interfaz (Shape). Esta interfaz abstrae a: Clases elementales como por ejemplo lneas y polgonos sencillos. Clases relativas a la edicin de texto no bsica. Adems se pretende reutilizar la clase existente de otra librera (TextView), pero inicialmente esta librera no fue diseada teniendo en cuenta la interfaz Shape. o Solucin 1: Modificar la clase TextView para que cumpla la interfaz Shape. Esta solucin en general es inaceptable porque esto puede implicar alterar otras aplicaciones en funcionamiento o duplicar cdigo. o Solucin 2: Emplear un adaptador.
implementadores concretos. Esta interfaz no tiene porque corresponderse abstraccin (Implementador->primitivas, Abstraccin->operaciones de alto nivel). o Implementador concreto (ConcreteImplementorX) Colaboraciones entre participantes: o La abstraccin redirige peticiones del cliente al objeto implementador. Consecuencias: o Desacoplamiento entre interfaz e implementacin. Elimina dependencias de compilacin. Posibilidad de configuracin en tiempo de ejecucin. o Facilita el poder extender independientemente las jerarquas de abstraccin e implementacin. o Oculta los detalles de implementacin a los clientes. Implementacin: o nico implementador. o Creacin del objeto implementador.
-45-
-46-
Patrones de diseo
Patrones de diseo
Aplicabilidad: o Se desea emplear una clase existente que no es compatible con el interfaz que se le requiere. o Se desea crear una clase reusable que coopere con clases no relacionadas. o Se desea usar diversas subclases existentes pero resulta imprctico adaptar sus interfaces mediante la extensin de todas ellas por lo que se emplea un objeto adaptador de la clase padre.
Participantes: o Objetivo o Target: Define la interfaz dependiente del dominio usada por el cliente. o Cliente o Client: Colabora con los objetos de acuerdo con el interfaz Objetivo o Target. o Adaptado o Adaptee: Define una interfaz existente que necesita ser adaptada. o Adaptador oAdapter: Adapta la interfaz del adaptado a la interfaz Objetivo.
Estructura: o Opcin 1 (herencia): La clase adaptadora implementa los mtodos de la interfaz pblica deseada (Target) e implementa la clase que se desea adaptar (heredando su mtodos).
Colaboraciones entre participantes: El cliente enva mensajes al adaptador y ste en repuesta los enva al objeto adaptado.
Consecuencias: o En ocasiones, permite la incorporacin de funcionalidades no disponibles en la clase adaptada. o Clase adaptadora: No permite adaptar una clase y todas sus subclases. Si se opta por la opcin 1 no existe indireccin. La clase adaptadora permite redefinir parte del comportamiento
o Opcin 2 (composicin): La clase adaptadora implementa los mtodos de la interfaz pblica deseada (Target) y usa un objeto de la clase que se desea adaptar para delegar parte del trabajo.
del adaptado. o Objeto adaptador: Un adaptador permite adaptar a diversos objetos que poseen un antecesor comn.
-47-
-48-
Patrones de diseo
Patrones de diseo
Difcil cambiar el comportamiento del adaptado. Para ello sera necesario extender el objeto adaptado y adaptar la nueva subclase. Patrn Flyweight o Objeto Ligero Clasificacin: Estructural. Propsito: Uso compartido de un gran nmero de objetos lgeros (o de grano fno) para aumentar la eficiencia. Motivacin: o Problema: En el contexto de un editor de documentos se emplean objetos para representar sus elementos: tablas, figuras, caracteres, etc. Adems se desea tratar a los elementos de forma uniforme. El problema es que mantener un objeto para cada letra por ejemplo puede ser muy caro.
El objeto ligero o flyweight acta como un objeto independiente que no se diferencia del objeto compartido. Distincin en el estado del objeto ligero (por ejemplo el formato de la letra o el carcter que se representa): Estado intrnsico: El estado se almacena dentro del objeto ligero e independientemente del contexto en el que se usa. (La letra que se representa) o Solucin 1: Tratar los caracteres de forma especial, es decir dar un tratamiento especfico para los caracteres en los diferentes algoritmos. o Solucin 2: Compartir objetos que pueden usarse al mismo tiempo en diferentes contextos. A estos objetos los denominaremos objetos ligeros o flyweight. Estado extrnsico: El estado depende del contexto en el que se encuentra el objeto de modo que el objeto ligero no puede ser compartido. (La posicin y el formato o el estilo que se le da al caracter). Los clientes del objeto ligero son los responsables de proporcionar el estado extrnseco al objeto ligero cuando lo necesite. -49-50-
Patrones de diseo
Patrones de diseo
Aplicabilidad: o Si se desea compartir objetos y se cumplen las siguientes condiciones: Existe un gran nmero de los objetos que se desean compartir. El coste de almacenamiento es alto debido a la gran cantidad de objetos que se requieren. La mayor parte del estado puede hacerse extrnsico. Muchos extrnsico. No se depende de la identidad entre objetos. grupos de objetos pueden reemplazarse por
Participantes: o ObjetoLigero o Flyweight: Declara la interfaz mediante la cual los objetos ligeros reciben y actan sobre el estado extrnseco. o ObjetoLigeroConcreto o ConcreteFlyweight: Implementa la interfaz del objeto ligero aadiendo el estado intrnseco. o ObjetoLigeroNoCompartido o UnsharedConcreteFlyweight: Puede hacer objetos con la interfaz de objeto ligero que no se compartan. En general estos objetos contienen a otros objetos ligeros (fila, columna, etc.). o FbricaDeObjetosLigeros o FlyweightFactory: Crea y gestiona los objetos ligerso y asegura la correcta comparticin de los objetos ligeros. o Cliente o Client: Mantiene referencias a objetos ligeros y calcula (o almacena) el estdo extrnsico de los objetos ligeros.
relativamente pocos objetos compartidos al eliminar el estado
Estructura:
Colaboraciones entre participantes: o El estado extrnsico es almacenado o calculado por lo clientes y proporcionado a los objetos ligeros cuando estos lo necesitan. o Los clientes no instancian directamente los objetos ligeros, sino que delegan esta responsabilidad en la fbrica de objetos ligeros para la correcta gestin de la comparticin de estos.
Consecuencias: o Penalizacin en el clculo del estado extrnseco. o Reduccin en los costes de almacenamiento, puesto que se reduce el nmero total de instancias y se almacena un solo estado intrnseco por objeto.
Implementacin:
-51-
-52-
Patrones de diseo
Patrones de diseo
o Eliminar el estado extrnsico. o Gestin de los objetos compartidos. o Combinacin con el patrn Composicin o Composite para construir grafos dirigidos acclicos. Los objetos ligeros no pueden tener un enlace al padre porque dependen del contexto (estado extrnseco).
PATRONES DE CREACIN Patrn Prototype o Prototipo Clasificacin: Patrn de creacin porque de forma transparente (sin necesidad de conecer la estructura de las instancias) crea objetos. Propsito: Especificar la clase de objetos a crear mediante la clonacin de un prototipo u objeto ya instanciado. Motivacin: o En el contexto de la construccin de un editor grfico que se plantea en el inicio del curso. Entre otras opciones, existen unas herramientas (GraphicTool) que permiten crear objetos nuevos (rectngulo, crculos, ). Los objetos creados pertenecen a una jerarqua de objetos (Graphic o Figura) cuyas clases derivadas son particulares para la aplicacin. o Adems de la jerarqua de objetos Graphic o figura existe una jerarqua de herramientas (Tool) que debera ser aplicable en otras aplicaciones como por ejemplo Mover, Rotar, Crear objetos nuevos, etc. Ntese que podra existir una fachada que nos proporcionase las operaciones de mover, rotar etc. y nos ocultase la jerarqua de herramientas. o Problema 1: Las herramientas encargadas de crear los objetos nuevos deben conocer las clases concretas de los objetos que van a instanciar puesto que pertenecean a la jerarqua de figuras y son particulares para la aplicacin del editor grfico. o Problema 2: Si tenemos una accin (subclase herramienta) para crear un rectngulo, tendremos que tener otra para crear un crculo, etc. Por lo tanto si existen 200 objetos diferentes tendremos 200 clases de accin. o Solucin: En primer lugar establecer slo una clase que se encargue de la creacin de los objetos de la jerarqua (todas las instancias). Para que adems la herramienta de creacin no tenga que conocer a todos los posibles tipos de instancia de la jerarqua, la herramienta de creacin va a construir los nuevos objetos de forma indirecta. Es decir la herramienta de creacin se inicializa con una instancia de las subclases grfica y es a las subclases grficas a las que le corresonde obtener una copia de s mismas si se desea crear objetos de ese tipo.
-53-
-54-
Patrones de diseo
Patrones de diseo
o PrototipoConcretoX o ConcretPrototypeX: Implementa la operacin de clonarse. o Cliente o Client: Crea un nuevo objeto solicitndole al prototipo que se clone. Colaboraciones entre participantes: El cliente solicita a un objeto prototipo que se replique (que se clone), es decir que se cree una copia de si mismo. Consecuencias: o Oculta las clases del producto al cliente. o Permite que el cliente trabaje con clases dependientes de la aplicacin sin cambios en este. Ntese el mtodo que hay que introducir en la superclase Graphic para permitir la rplica de los objetos. Aplicabilidad: o Cuando un sistema debe ser independiente de la forma en que sus productos son creados, compuestos y representados y : Las clases a instanciar son especficas en tiempo de ejecucin. Slo existe un nmero pequeo de combinaciones diferentes de estado para las instancias de una clase. Estructura: o Especificacin de nuevos objetos mediante el cambio de sus valores. o Especificacin de nuevos objetos mediante la variacin de su estructura mediante el cambio del prototipo de modo que el cliente no se vea afectado. o Reduccin del nmero de subclases. El patrn prototipo te permite a ti instanciar un nuevo clon a partir del prototipo en vez de pedir al mtodo de fabricacin que cree una nueva instancia, por lo tanto no necesitas una jerarqua de clases creadoras. o Configuracin dinmica de una aplicacin. Es posible aadir y eliminar productos en tiempo de ejecucin. Algunos entornos en tiempo de ejecucin te premiten la carga de clases de forma dinmica. El patrn prototipo es la clave para explotar tales facilidades. (Ejemplo: Creacin del botn casa) Implementacin: o Uso de un gestor de prototipos. En este patrn surge el problema de quin crea los prototipos para proporcionrselos al cliente de modo que este no sea dependiente de las jerarquas. En general debe ser un objeto que tenga que conocer la jerarqua y se la proporcione a los clientes (puede haber ms de uno), este objeto se conoce como el gestor de Participantes: o Prototipo o Prototype: Declara la interfaz para clonarse. prototipos. El gestor de prototipos tiene que proporcionar al cliente mtodos para que el cliente seleccione el prototipo que estime oportuno, por ejemplo un mtodo Producto crea(String tipoObjeto,
-55-
-56-
Patrones de diseo
Patrones de diseo
otraInformacin);. Si en lugar de pasar un simple String con un nombre se establecen especificaciones ms complejas el patrn prototipo degenerar en el patrn Negociador de productos o Product Traider en donde el negociador es un gestor de prototipos. Cliente Negociador
o Ejercicio 3: Buscar informacin de la interfaz java Cloneable y modificar el ejemplo proporcionado para usarla en lugar de emplear el mtodo clonar(). o Ejercicio 4: Modificar el ejemplo propocionado para permitir objetos compuestos. Usar el patrn composicin. Patrn Singleton o Instancia nica Clasificacin: Creacional. Propsito: Se asegura de que una determinada clase slo tiene una instancia y proporciona un punto de acceso a dicha instancia. Motivacin: o Existen mltiples ejemplos en donde slo se requiere tener una instancia de una clase, por ejemplo en el caso del patrn anterior slo necesistaremos una instancia del gestor de prototipos, o si tenemos muchas impresoras en general slo necesitaremos un nico gestor de impresin, muchas conexiones pero un nico gestor de conexin etc. o Problema: Nos interesa facilitar el acceso a ese objeto y que ese objeto sea nico, es decir exista una sola instancia de un determinado tipo de clase. o Solucin 1: Mantener una variable global para facilitar el acceso. De este modo no resolvemos el problema porque siempre podemos instanciar mltiples objetos en variables locales aunque si es cierto que es de fcil acceso. o Solucin 2: Hacer responsable a la propia clase de la instancia nica: Restringiendo el acceso al constructor de modo que una vez creada una instancia ya no se puedan crear ms. Proporcionando un mecanismo para acceder a la instancia si esta ya ha sido creada y sino que la cree en ese momento. Aplicabilidad: o Debe existir una nica instancia de una clase, y sta debe ser accesible a los clientes desde un punto de acceso bien conocido.
Especifiacin
Producto
o Implementacin de la operacin de clonacin. En los objetos compuestos esto puede ser un problema. Por ejemplo si clonamos un objeto decorado (ver patrn decorador) de qu se hace copia del envoltorio exterior o de todo el conjunto, es decir copia las referencias o crea nuevos objetos para el estado. En funcin de la decisin que se tome se modificar la operacin clonar(). o Inicializacin del objeto clonado en caso de que la rplica necesite una inicializacin adicional. A veces no es factible crear la instancia y replicar todo el estado del objeto que sirve como prototipo por ejemplo en el caso de que el prototipo tenga una clave o identificador de instancia o si hay una cierta parte del prototipo que no se puede clonar. Cuando se requiere inicializacin la opcin ms comn: Exportar a la superclase los mtodos de inicializacin. Esta opcin es vlida si todas las figuras en la jerarqua tuviesen la misma interfaz para realizar su inicializacin. Ejemplo void inicializar (string fichxml). Cada subclase debe redefinir el mtodo y extraer la informacin necesaria. Ejercicios: o Ejercicio 1: Realiza un diagrama de objetos del cdigo que se proporciona de ejemplo. o Ejercicio 2: Realiza un diagrama de secuencia del programa Main.
-57-
-58-
Patrones de diseo
Patrones de diseo
o La nica instancia puede ser extendida (subclase), y los clientes deberan poder usar la instancia extendida sin modificar su cdigo. Estructura:
o En Java: Declarar el constructor como privado y adems establecer un atributo como privado para almacenar la instancia. Para inicializar el atributo privado emplear un bloque esttico. Establecer un mtodo pblico que proporcione la instancia correspondiente al atributo privado de la clase. Ejercicios: o Ejercicio 1: Probar el ejemplo de cdigo proporcionado para el patrn Instancia nica y analizarlo.
Participantes: o Instancia nica o Singleton: Define un mtodo de clase que permite a los clientes acceder a la instancia nica y normalmente tambin es la responsable de crear su nica instancia.
Patrn Factory Method o Fabricacin Clasificacin: Creacional. Propsito: Define la interfaz para crear un objeto, pero deja que las subclases decidan que clase concreta se debe instanciar. Motivacin: o Framework para apliacaciones que permiten presentar mltiples documentos al usuario; donde existen dos abstracciones: Aplicacin y Documento. Para una aplicacin especfica, se especializan las interfaces Aplicacin y Documento. o Problema: La abstraccin (o interfaz) Aplicacin conoce cundo se debe crear un documento pero no qu documento crear puesto que eso depende de la aplicacin especfica que se desarrolla empleando el framework, por ejemplo un documento de Word o un documento de texto. o Solucin 1: Dar en la superclase o clase abstracta una implementacin por defecto del mtodo crear documento y que las subclases lo redefinan. Esta solucin tiene la siguiente desventaja: Puede ser que por cada aplicacin concreta necesitemos un tipo de documento concreto por lo que la subclase de documento por defecto puede no ser nunca empleada. o Solucin 2: Usar el patrn prototipo, pero esto requiere que la jerarqua de productos colabore.
Colaboraciones entre participantes: Los clientes acceden a la instancia del Singleton a travs de la operacin definida a tal fin (instance()).
Consecuencias: o Acceso controlado a la instancia nica. o Reduce el espacio de nombres al evitar variables globales. o Permite el refinamiento de operaciones y representacin mediante el uso de herencia. En este caso en lugar de tener una nica instancia nica de ella misma tiene una instancia nica de una subclase. En este caso se usa la instancia de la subclase con la interfaz de la superclase. o Permite un nmero variable de instancias. o Ms flexible que las operaciones de clase.
Implementacin: o Asegurar la unicidad de la instancia de la clase. o Extender la clase InstanciaUnica o Singleton: El mtodo de clase instacia conoce las subclases de la jerarqua y crea la instancia deseada. Establecer algn mecanismo para registrar las subclases.
-59-
-60-
Patrones de diseo
Patrones de diseo
o Solucin 3: Asigna a un mtodo abstracto la responsabilidad de crear un documento concreto, separando esta responsabilidad del framework.
o CreadorConcreto
ConcreteCreator
FactoraConcreta
ConcreteFactory: Redefine el mtodo de fabricacin para devolver una instancia de un producto concreto. Colaboraciones entre participantes: El creador emplea el mtodo de fabricacin redefinido por sus sublcases para utilizar la instancia del producto concreto apropiada. Consecuencias: o Elimina la necesidad de incluir clases especficas de la aplicacin en cdigo ms general dando mayor potencia de reutilizacin del
Aplicabilidad: o No se puede anticipar la clase de objetos que se tienen que crear. o Una clase quiere que sus subclases especifiquen que objetos se deben crear. o Clases que delegan la responsabilidad a una de las subclases colaboradoras y se desea localizar el conocimiento de qu sublcases es la encargada.
framework. o Mayor flexibilidad dado que se proporciona un mecanismo a las subclases para introducir una versin msextendida del producto. o Conecta jerarquas paralelas. o Desventaja: Puede obligar a extender la clase creadora slo para crear un producto concreto. Si esto es un problema puede emplear otra solucin como por ejemplo el patrn prototipo.
Estructura:
Participantes: o Producto o Product: Definde la interfaz de los objetos creados por el mtodo de fabricacin. o ProductoConcreto o ConcreteProduct: Implementa la interfaz de los productos. o Creador o Creator o Factora o Factory: Declara el mtodo de fabricacin y opcionalmente pudede definir una implementacin por defecto que construye un producto concreto. Puede utilizar el mtodo de fabricacin. Implementacin: o Dos variantes: El creador es una clase abstracta y no proporciona
implementacin por defecto para el mtodo (necesario extender al creador)
-61-
-62-
Patrones de diseo
Patrones de diseo
El creador es una clase concreta y define un producto concreto por defecto (flexibilidad para cambios futuros). o Mtodos de fabricacin parametrizados. Un nico mtodo puede crear distintos productos en base a los parmetros del mtodo de fabricacin. (Solucin ms comn.). Ejercicios: o Ejercicio 1: Probar el ejemplo de cdigo proporcionado para el patrn fabricacin y analizarlo. Patrn Abstract Factory o Fbrica Abstracta Clasificacin: Creacional. Propsito: Interfaz para la creacin de familias de objetos relacionados sin especificar sus clases concretas. Motivacin: o Interfaz de usuario con mltiples look-and-feels (Motif, Presentation Manager, Windows, ...) o Cada Look-and-feel define su propio juego de components (widgets: botones, ventanas, barras de desplazamiento, ...) o Problema: Por razones de portabilidad el resto del sistema no debe hacer referencia a componenetes concretos. o Solucin: Crear una clase abstracta con un mtodo de fabricacin para cada componente (fbrica abstracta) y una clase abstracta por componente. El cliente crear los componentes mediante la fbrica abstracta. De modo que la fbrica de componentes garantiza el uso consistente de cmponentes de un mismo look-and-feel. Participantes: o Fbrica abstracta o AbstractFactory: Declara la interfaz para las operaciones que crean productos abstractos (mtodos de fabricacin) o Fbrica Concreta o ConcretFactory: Implementa los mtodos de fabricacin de productos concretos. o Producto abstracto o AbstractProduct: Declara la interfaz utilizada por el cliente par un tipo de producto concreto. Aplicabilidad: o Un sistema debe ser independiente de la forma en que sus productos son creados, compuestos y representados. o Un sistema debe ser configurado con una de muchas familias de productos disponibles. o Una familia de productos son diseados para su uso conjunto, y se requiere asegurar este uso conjunto. o Se desea proporcionar una biblioteca de productos presentando su interfz, pero no su implementacin. Estructura:
-63-
-64-
Patrones de diseo
Patrones de diseo
o ProductoConcreto o ConcreteProduct: Define un producto creado por el mtodo de fabricacin de una fbrica concreta. Implementa la interfaz del producto abstracto. o Cliente o Client: Usa slo las interfaces declaradas por la fbrica abstracta y los productos abstractos. Colaboraciones entre participantes: Normalmente se crea una nica fbrica concreta que se encarga de crear los productos concretos, mientras que la fbrica abstracta difiere la creacin de productos a sus subclases. Consecuencias: o Asla clases concretas (no aparecen en el cdigo del cliente). o Facilita el intercambio de familias de productos. o Simplifica consistencia entre productos. o Difcil aadir nuevas clases de productos. Implementacin: o Las fbricas usualmente suelen se instancias nicas. o La creacin de productos puede realizarse por el mtodo de fabricacin habitual o mediante el patrn prototipo para evitar extender la fbrica abstracta. o Flexibilizar la fbrica mediante la parametrizacin del mtodo de fabricacin: El mtodo de fabricacin puede crear diferentes tipos de componenetes en base a los parmetros del mtodo. El cliente debe realizar una conversin tras crear el producto (downcasting). En la mayora de los lenguajes no hay ninguna relacin formal entre valores de los parmetros y productos creados, exceptuando el cdigo fuente. Patrn Builder o Constructor Clasificacin: Creacional.
Propsito: Separa la construccin de un objeto complejo de su representaicn, de modo que el mismo proceso de construccin permite crear diferentes representaciones.
Motivacin: o Lector de documentos en formato RTF que lo convierte a diferentes formatos (ASCII; TEX;...). o Dejar abierta la posibilidad de nuevos tipos de conversin: debera ser sencillo aadir una nueva conversin sin modificar el lector. o Solucin: Configurar el lector con un objeto responsable de convertir cada fragmento del documento RTF al formato destino. o Las subclases de la clase constructora especializan la construccin para los distintos formatos
Aplicabilidad: o El algoritmo para crear un objeto complejo debe ser independiente de las partes que constituyen el objeto y de cmo son ensambladas. o El proceso de construccin debe premitir distintas representaciones del objeto construido.
Estructura:
-65-
-66-
Patrones de diseo
Patrones de diseo
Participantes: o Constructor o Builder: Especifica la interfaz para la creacin de las partes de un Producto. o ConstructorConcreto o ConcreteBuilder: Implementa la interfaz del constructor para construir y ensamblar las diferentes partes del producto. Adems almacena el producto en construccin y proporciona una interfaz para recuperar el producto construido. o Director o Director: Construye un objeto utilizando la interfaz del constructor. o Producto o Product: Objeto concreto a construir. Consecuencias: o Permite variar la representacin interna de un producto. o Asla el cdigo de la construccin y la representacin. o Proporciona un control ms detallado del proceso de construccin.
Colaboraciones entre participantes: o El cliente crea el objeto director y lo configura con el constructor deseado. o El director notifica al constructor la parte del producto que debe ser creada. o El constructor aade partes al producto, de acuerdo con las peticiones del director. o El cliente recupera el producto final del constructor.
-67-
-68-
Patrones de diseo
Patrones de diseo
PATRONES DE COMPORTAMIENTO Patrn Chain of Responsability o Cadena de Responsabilidad Clasificacin: De comportamiento porque determina como se debe realizar el intercambio de mensajes entre los diferentes objetos para resolver una tarea. Propsito: Posibilidad de enviar (y/o gestionar) una peticin a ms de un objeto mediante el encadenamiento de los receptores. Motivacin: o Sistema de ayuda sensible al contexto de una interfaz grfica donde el usuario puede solicitar ayuda de cualquier componente o parte de la interfaz. Si la parte seleccionada tienen informacin especfica debe presentarla, en caso contrario debe presentar un mensaje relacionado con el contexto ms prximo (sucesor) de la parte seleccionada. En general el contexto ms prximo ser el que lo contiene el elemento. o Problema: El objeto que inicia la peticin no conoce a priori que objeto proporciona la ayuda, es decir no sabe si su sucesor ms cercano resolver la peticin o ser otro ms alejado. o Solucin: Desacoplar el emisor de la peticin de los receptores (receptor implcito, es decir el que realmente resuelve la peticin). Se establece una cadena de objetos que delegan la peticin hasta que uno se hace cargo. Por lo tanto la respuesta a la peticin depender tanto del componente en que se realice la peticin como del contexto en que se encuentre ste. o La alternativa a al solucin de la cadena de responsabilidad es que cada objeto conociese la forma de resolver el servicio. Esto implicara sobrecargar el objeto en concreto con ms cosas de las necesarias y llevara en muchos casos a la duplicidad de cdigo. Otra solucin sera conocer a priori el objeto que resuelve la peticin pero esto ltimo provoca acoplamiento entre el que inicia el servicio y el que lo resuelve, por lo cual es ms difcil de mantener. El patrn est pensado para que la estructura de la cadena pueda variar dinmicamente y que adems el mensaje pueda ir modificndose.
o Para realizar la delegacin entre objetos de la cadena es necesario tener una estructura que los relacione por ejemplo la asociacin manejador o handler.
-69-
-70-
Patrones de diseo
Patrones de diseo
Aplicabilidad: o Ms de un objeto puede manejar la peticin y no se conoce a priori cul de ellos va a resolverla. o No se desea identificar explcitamente el receptor de una peticin, sino que le envas la peticin a un conjunto. o Los objetos que pueden manejar la peticin varan dinmicamente.
o Cuando un cliente inicia una peticin, dicha peticin se propaga a travs de la caden hasta que un manejador concreto asume la responsabilidad de gestionarla y en ese momento corta la cadena de responsabilidad. Consecuencias: o Reduce el acoplamiento entre objetos, puesto que reduce las dependencias. En cualquier caso al mismo tiempo acarrea una pequea penalizacin de la eficiencia por los niveles de indireccin introducidos que son ms acusados cuanto mayor sea la delegacin en la cadena. o Flexibilidad aadida a la hora de asignar responsabilidades a los objetos. o La recepcin de la peticin no est garantizada puesto que quizs ningn objeto de la cadena de responsabilidad resuelve el servicio. Por lo tanto es necesario saber cul es el final de la cadena de responsabilidad y si en ese momento no se puede resolver la peticin devolver algn tipo de error, mensaje informativo o valor por defecto. Implementacin: o Cadena de sucesores: Definir nuevos enlaces para los sucesores o emplear enlaces existentes como por ejemplo los definidos en el patrn composicin con variante para referenciar el padre. En general si no exiten enlaces para los sucesores se crea una asociacin en la superclase de los objetos que intervienen en la cadena. Esta superclase y asociacin permite establecer el cdigo para realizar la asociacin y delegacin de la peticin en la superclase de modo que cada una de las clases concretas si quiere manejar la peticin deber reescribir el mtodo correspondiente, sino actuar como la superclase. o Conexin de sucesores. o Representacin de las peticiones. Un mtodo por tipo de peticin. nico mtodo parametrizado para distinguir diferentes tipos de peticiones: Como parmetro del mtodo poner un id que nos indique el tipo de peticin. Mala solucin porque si alguna de las peticiones implica parmetros entonces a parte de ese
Estructura:
Participantes: o Manejador o Handler: Define la interfaz para manejar peticiones y normalmente tambin define el enlace al sucesor en la cadena. En general tambin determina la resolucin por defecto de la peticin sino existe un objeto en quien delegar. o ManejadorConcreto o ConcreteHandler: Maneja las peticiones de las que es responsable. Si no puede gestionar la peticin, la redirige a su sucesor. o Cliente o Client: Enva una peticin a algn manejador concreto de la cadena.
Colaboraciones entre participantes:
-71-
-72-
Patrones de diseo
Patrones de diseo
identificador tendramos que poner en cualquier peticin todos los parametros de todas las posibles peticiones que no usuamos Tener como parmetro del mtodo que maneja las peticiones un objeto peticin que acta como superclase de los diferentes conjuntos de parmetros de las peticiones. o Se estn creando objetos artificiales que no tienen un comportamiento asociado, solamente almacenan un conjunto de parmetros. o No es necesario recompilar las clases de la cadena que no manejan la peticin si se aade una nueva peticin. Adems as no se sobrecargan esas clases con mtodos que no saben resolver. o Ejercicio 1: Realiza un diagrama de objetos del cdigo que se proporciona de ejemplo. o Ejercicio 2: Realiza un diagrama de secuencia del programa Main. o Ejercicio 3: Fusiona el cdigo del ejemplo de unidades de combate del patrn decorador con el cdigo propocionado en este bloque. A continuacin reflexiona sobre las diferencias entre el patrn decorador y el patrn cadena de responsabilidad. Patrn State o Estado Clasificacin: De comportamiento porque determina como se debe realizar el intercambio de mensajes entre los diferentes objetos para resolver una tarea. Propsito: Permite a un objeto modificar su comportamiento al cambiar su estado interno, de modo que el objeto concreto en apariencia cambia de clase. Motivacin: o Problema: Supongamos que disponemos de una clase que representa una conexin a una base de datos o una conexin de red. Un objeto en concreto de esa clase puede estar en diferentes estados: Establecida, Cerrada o Transmitiendo. Al recibir una peticin, el objeto se comporta
de modo distinto en base a su estado interno. Por ejemplo si la conexin est Cerrada y se intenta realizar una consulta SQL se producir un mensaje de error, sin embargo si el estado de la conexin es Establecida nos propocionar los datos correspondientes si realizamos correctamente la consulta. o Solucin 1: Extender la clase conexin con subclases que representen la conexin en distintos estados Problema: Los objetos tienen que cambiar dinmicamente de clase cuando pasen de un estado a otro. o Solucin 2: Tener una nica clase conexin y en cada uno de los mtodos establecer condiciones (switch, case, if, etc.) para determinar dentro de los mtodos lo que se debe hacer en funcin del estado. Problema: Ms complejo el cdigo y el mantenimiento de la clase. o Solucin 3: Introducir una superclase abstracta que representa a los estados de la conexin de red. La superclase define la interfaz de los mtodos dependientes del estado. Esta superclase es extendida con subclases que implementan el comportamiento especfico de cada uno de los estados concretos. Problema: Tiene el mismo problema que la solucin 1. o Solucin 4: La clase conexin mantiene una referencia a un objeto estado en el que delega el comportamiento dependiente del estado en que se encuentra la conexin. El objeto concreto del que mantiene la referencia la conexin en un determinado instante representa el estado actual de dicha conexin. Para cambiar de estado simplemente se cambia la asociacin entre la clase conexin y un objeto de la clase estado. La clase estado es un clase abstracta (es decir que no pueden existir instancias de dicha clase) que declara un interfaz comn a todas las subclases para representar diferentes estados operacionales. Por lo tanto, la clase abstracta se extiende con subclases concretas que representan el comporamiento especfico en cada uno de los estados operacionales.
-73-
-74-
Patrones de diseo
Patrones de diseo
contexto. En el ejemplo motivador se corresponde con la clase TCPConection. o Estado (State): Define una interfaz para encapsular el comportamiento asociado con un estado particular del contexto. En el ejemplo motivador se corresponde con la clase TCPState. o Estados Concretos (ConcreteState): Cada subclase implementa el comportamiento asociado con un estado del contexto. En el ejemplo motivador se corresponde con las clases TCPStateStablished, TCPClose y TCPListen. Problema: En los mtodos dependientes del estado se pueden requerir atributos de la clase TCPConnection: Solucin a: Pensar la asociacin _state como una relacin bidireccional. Esta solucin suele ser difcil de mantener y compleja. Solucin b: Proporcionar el propio libro como parmetro de llamada a un metodo. Aplicabilidad: El comportamiento de un objeto depende de su estado, y dicho estado puede cambiar en tiempo de ejecucin. Adems tambin se puede aplicar cuando existen clases con grandes sentencias condicionales mltiples dependientes del estado del objeto y donde el estado se representa por 1 o ms constantes enumeradas. Estructura: Colaboraciones entre participantes: o El contexto delega las partes de comportamiento especficos del estado al objeto ConcreteState que tiene asociado en cada momento. Adems el contexto puede pasarse a s mismo como argumento al objeto estado para manejar una peticin. De esta forma, el objeto estado puede acceder a informacin del contexto si esta es requerida. o La configuracin de un contexto la puede realizar un cliente con objetos estado pero en general los clientes utilizan el contexto como interfaz, sin necesidad de manejar objetos estado directamente. Es ms una vez el contexto est configurado inicialmente, el cliente no debera tratar con los objetos estado directamente. Adems en el constructor de la clase contexto se puede indicar un estado inicial. Por otro lado tanto el contexto como los estados concretos pueden decidir cambiar el estado actual bajo la poltica concreta de cambio de estado. Consecuencias: o Localiza y separa el comportamiento especfico de cada estado facilitando aadir nuevos estados y transiciones pero haciendo que el modelo sea menos compacto puesto que aumenta el nmero de clases. o Encapsula el comportamiento asociado a un estado concreto en un clase particular y deja en la clase contexto slo operaciones que no dependen Participantes: o Contexto (Context): Define la interfaz para los clientes. Mantiene una instancia de un estado concreto que define el estado actual del objeto -75-76del estado, lo cual facilita el mantenimiento.
Patrones de diseo
Patrones de diseo
o Hace explcitas las transiciones entre estados, mientras que si se opta por codificar el estado con valores internos en la clase contexto y sentencias condicionales esto sera implcito. Es decir, las transiciones entre estados se mostraran slo mediante la asignacin de determinados valores a variables. o Bajo ciertas circunstancias, es posible la comparticin de objetos estado por varios objetos contexto. Por ejemplo cuando los objetos estado no tienen variables instanciadas, es decir el objeto estado es como un tipo de datos (patrn objeto ligero o flyweight). Implementacin: o De quin es la responsabilidad de efectuar transicin entre estados? Esto no se especifica en el patrn. En general cuando los criterios son fijos los cambios de estado suelen ser responsabilidad de la clase contexto. Sin embargo, se puede permitir que las sublcases estado especifiquen su propio estado sucesor. Esto ltimo requiere que las subclases estado conozcan el objeto contexto y que el contexto disponga de un mtodo que les permita a dichas subclases cambiar su estado actual explcitamente. o Creacin y destruccin de objetos estado. Crear y destruir cada vez que es necesario. Posiblemente siendo el contexto el que se encargue de esto. Evita crear objetos que no son frecuentemente usados. Crear al principio y no destruir. Esto slo es posible cuando los estados se conocen a priori y no se van a cambiar en tiempo de ejecucin. Da lugar a dos relaciones: EstadosPosibles y EstadoActual. Emplear el patrn instancia nica para la creacin de estados. o Herencia dinmica. Cdigo ejemplo: o Ejercicio 1: Analiza cuales son los objetos que se porporcionan en el cdigo de ejemplo y determina cul es la funcin de cada uno de ellos.
o Ejercicio 2: Qu patrn o patrones se estn usando en la implementacin del ejemplo adems del patrn estado o State? o Ejercicio 3: Cul es la visibilidad del mtodo
establecerEstado(EstadoLibro estado) de la clase libro? Podra tener otra visibilidad? Qu implicara? Patrn Strategy o Instancia Estrategia Clasificacin: De comportamiento porque determina como se debe realizar el intercambio de mensajes entre los diferentes objetos para resolver una tarea. Propsito: Define, encapsula y hace intercambiables a una familia de algoritmos, de modo que un algoritmo puede variar independientemente del cliente que lo usa. Adems hace intercambiables a los diferentes algoritmos con la misma funcionalidad. Motivacin: o En el contexto de un editor de textos se dispone de diversos algoritmos para particionar un texto en lneas (justificado, alineado a izquierda, alineado a derecha, con palabras partidas, etc. ) siendo deseable separar a las clases clientes de las clases algoritmos de particin por las siguientes razones: Los clientes que incluyen el cdigo para particionar en lneas son ms grandes y ms difciles de mantener, especialmente si soportan mltiples algortimos de particionamiento. No todos los algoritmos son necesarios en todos los casos. De modo que no queremos que los clientes soporten algoritmos que no van a necesitar. Es difcil aadir nuevos algoritmos o modificar los existentes si el algoritmo forma parte del cliente. Se produce duplicidad de cdigo si existen diferentes clientes distintos que requieren el particionamiento de lneas. o Solucin: Definir clases que encapsulan a las diferentes estrategias de particionamiento en una jerarqu diferente.
-77-
-78-
Patrones de diseo
Patrones de diseo
Estructura:
Cada una de las clases concretas Compositor representan un algoritmo, de modo que el cliente (Composition) puede reemplazar el algoritmo que emplea o bien estticamente o bien dinmicamente. Este patrn tambin es til cuando el algoritmo con el que se est trabajando es complejo y requiere muchas estructuras de datos que se quieren aislar. Se ve que la estructura es similar al patrn anterior (estado) pero los propsitos por los que surge son distintos. En el patrn estado existe una dependencia mucho ms fuerte que en el patrn estrategia puesto que por ejemplo una conexin no puede existir si no tiene estado asociado pero el editor puede existir sin un algoritmo de particionamiento de lneas. Adems los algoritmos pueden ser usados por otros tipos de clientes. Aplicabilidad: o Muchas clases relacionadas se diferencian nicamente en su
Participantes: o Contexto (Context): Es el elmento que usa los algoritmos por lo tanto va a delegar en la jerarqua. Est configurado con una estrategia concreta mediante una referencia al objeto estrategia correspondiente. Puede definir una interfaz que permita a la estrategia el acceso a sus datos. o Estrategia (Strategy): Declara una interfaz comun para todos los algoritmos soportados. El contexto utiliza este interfaz para invocar el algoritmo definido por una estrategia concreta. o Estrategia Concreta (ConcreteStrategy): Implementa el algoritmo utilizando la interfaz definida por la estrategia.
Colaboraciones entre participantes: o Es necesario el intercambio de informacin entre Estrategia y Contexto para implementar el algoritmo elegido: Parmetros de los mtodos de la estrategia: En este caso al algoritmo elegido se le pasa slo la informacin que necesita para realizar la operacin requerida. En ocasiones, como ocurra en el patrn Estado, el contexto se pasa a s mismo a la estrategia. Sin embargo si se opta por esta opcin se est haciendo ms difcil la reutilizacin de los algoritmos en otros puntos debido a que se estn uniendo las dos jerarquas (la cliente y la de estrategias). o Los clientes del contexto normalmente configuran a ste con una estrategia concreta. A partir de ah, slo se interacta con el contexto.
comportamiento, de modo que aparece una superclase con el comportamiento comn y se accede segn la interfaz de la superclase. o Necesarias distintas variantes de un algoritmo. o Un algoritmo utiliza informacin que los clientes no deberan conocer. El patrn evita la exposicin de estructuras de datos dependientes del algoritmo. o Una clase define mltiples comportamientos mediante una serie de instrucciones condicionales. En lugar de emplear las estructuras condicionales, mover el cdigo de dichas estructuras a clases propias donde se realice la estrategia pertinente.
Consecuencias:
-79-
-80-
Patrones de diseo
Patrones de diseo
o La herencia puede ayudar a factorizar las partes comunes de las familias de algoritmos. o Alternativa a la extensin de contextos cada uno con una estrategia o algoritmo. Adems al permitir la evolucin independiente se obtiene la posibilidad de realizar cambios dinmicos de algoritmos. o Reduccin de instrucciones condicionales. o Diferentes opciones de implementacin para un mismo algoritmo sin modificar el cdigo de la clase. o Los clientes deben conocer las diferentes estrategias, a diferencia de lo que ocurra en el patrn estado, y en base a la poltica estratgica decidir cul de las estrategias se va a aplicar. o Existe una pequea penalizacin en la comunicacin entre estrategia y contexto, como sucede siempre que se pasa de una clase monoltica a usar la delegacin, puesto que se produce una indireccin. o Incremento del nmero de objetos. Implementacin: o Para la definicin de la interfaz entre estrategia y contexto existen tres formas bsicas: Pasar como parmetro la informacin necesaria para la estrategia de forma explcita. Esta es la opcin ms comnmente usada. Pasar como parmetro el contexto y dejar que la estrategia explcitamente pida la informacin que necesita. Es la opcin menos usada con el patrn estrategia aunque es comn con el patrn estado. Mantener en la estrategia una referencia al contexto, es decir, hacer la asociacin bidireccional. o Cuando los objetos estrategia son opcionales cuando se vaya a emplear una determinada estrategia es necesario realizar la comprobacin de si se dispone de ella. Otra posibilidad es definir en la jerarqua estrategia la estragegia nula que es la que se asigna por defecto. Cdigo ejemplo:
o Ejercicio 1: Analiza cules son los objetos que se porporcionan en el cdigo de ejemplo y determina cul es la funcin de cada uno de ellos. o Ejemplo 2: Amplia el cdigo del ejemplo para proporcionar la estrategia de ordenacin Quicksort. Patrn Observer u Observador Clasificacin: De comportamiento porque determina como se debe realizar el intercambio de mensajes entre los diferentes objetos para resolver una tarea. Propsito: Definir una dependencia uno-a-muchos entre objetos de un modelo y sus vistas de tal forma que cuando el objeto cambie de estado, todos sus objetos dependientes sean notificados y actualizados automticamente. Motivacin: o Las aplicaciones de hoy en da, en general, se dividen en 3 partes o capas: Vista (interfaz del sistema), Modelo (lgica de la aplicacin) y Almacenamiento o Persistencia (almacena de forma persistente la inforamcin relacionada con el modelo). Estas tres partes tratan de ser lo ms independientes posible aunque tienen puntos de conexin. De este modo se permite cambiar la interfaz grfica de las aplicaciones (por ejemplo de escritorio a Web) o el modelo de almacenamiento empleado (por ejemplo de ficheros XML a una base de datos relacional) sin afectar a las dems capas. o En estos casos y otros existe una necesidad de consistencia entre clases relacionadas pero manteniendo bajo acoplamiento. Por ejemplo: Separar componentes GUI de los objetos que mantienen los datos de la aplicacin para que sean reutilizables independientemente.
-81-
-82-
Patrones de diseo
Patrones de diseo
En este ejemplo slo se ha considerado una vista pero si hubiese ms el modelo tendra que notificar la actualizacin a todas las vistas. Adems el modelo debera disponer de mtodos para que ms vistas puedan ser aadidas dinmicamente y tambin eliminadas; por ejemplo, si se cierra una ventana. Ntese que el sujeto no es consciente de cuntos observadores van a estar afectados por un cambio en concreto en su estado, puesto que no debe saber nada de su aspecto y comportamiento. Lo nico que debe saber el sujeto es que los observadores disponen de un mtodo actualizar al que debe llamar cuando cambie de estado. o Solucin 1: Se puede pensar que peridicamente los objetos presentacin preguntan al objeto subject por su estado y si este ha modificado lo actualizan. o Problema: Esto no parece lgico porque se puede llegar a sobrecargar al objeto subject aunque este cambie con muy poca frecuencia su estado. Es ms lgico que cuando se cambie el estado en subject este notifique a todos sus observadores el cambio. o Solucin 2: El comportamiento de los observadores (hoja de clculo, diagrama de barras,...) depende del sujeto observado, que debera notificar cualquier cambio en su estado. Adems el nmero de observadores no est limitado. Modelo ObtenerEstado() MetodosCambio() * Vista Actualizar() Aplicabilidad: o Una abstraccin tiene dos aspectos diferentes, uno dependiente del otro. Encapsular estos aspectos en objetos separados permite su variacin y reutilizacin de modo independiente. o Cuando una modificacin en el estado de un objeto requiere cambios de otros, y no se desea conocer cuantos objetos deben ser cambiados. o Cuando un objeto debera ser capaz de notificar a otros objetos sin hacer ninguna suposicin acerca de los objetos notificados. Estructura:
De modo que el comportamiento sera: :Controlador CambiarEstado() :Modelo :Vista Actualizar() ObtenerEstado()
-83-
-84-
Patrones de diseo
Patrones de diseo
o La relacin _subject se realiza entre los objetos concretos y no entre las interfaces, como en el caso de la relacin _observers; es decir, la relacin _observers no es bidireccional. Esto tiene que ser necesariamente as porque el ConcreteObserver tiene que ser capaz de determinar las caractersticas del ConcretSuject que le interesan y cuales no. Se podra optar por hacer la asociacin observadores bidireccional pero en ese caso en el observador concreto tendramos que hacer un downcasting al sujeto concreto. En cualquier caso la asociacin sujeto se puede evitar si en el mtodo actualizar se pasa como parmetro el sujeto de forma explcita (actualizar (Sujeto s)) de modo que se crea una dependencia temporal en tiempo de ejecucin pero no en tiempo de compilacin. Ntese que en este caso tambin es necesario realizar un downcasting. Participantes: o Sujeto (Subject): Conoce a sus observadores y proporciona una interfaz para agregar (attach) y eliminar (detach) observadores del propio Sujeto. o Observador (Observer): Define un mtodo utilizado por el Sujeto para notificar cambios en su estado (update). o SujetoConcreto (ConcreteSubject): Mantiene el estado de inters para los observadores concretos. Notificndo a los observadores el cambio en su estado. o ObservadorConcreto (ConcreteObserver): Mantiene una referencia al sujeto concreto debido a que parte de su estado debe permanecer consistente con el estado del sujeto. Para lograr esta consistencia, implementa la interfaz de actualizacin. Colaboraciones entre participantes: o El sujeto concreto notifica a sus observadores cada vez que se modifica su estado. Esta responsabilidad de notificar la hereda de su padre (sujeto). o Tras ser informado de un cambio en el sujeto concreto, un observador concreto interroga al sujeto para modificar la percepcin que tiene de dicho sujeto. Consecuencias: o Abstrae acoplamiento entre sujeto y observador, de modo que se pueden modificar y reusar las jerarquas de sujestos y observadores independientemente. Adems permite la addicin de nuvas clases observadores sin para ello tener que modificar a los sujetos ni a los dems observadores. o El sujeto no necesita especificar los observadores afectados por un cambio, es decir, cada sujeto sabe que tiene una lista de observadores pero el sujeto concreto no conoce las clases observadores concretos. Por lo tanto desconoce a cuales de sus observadores le va a afectar un determinado cambio en su estado. o Desconocimiento de las consecuencias de una actualizacin. El sujeto concreto emite una comunicacin broadcast a todos sus observadores y son estos los que preguntan el estado al sujeto concreto y determinan si se modifican o no. Implementacin: o Implementacin asociacin sujeto-observadores. En un principio la asociacin se presenta con una estructura de datos en el sujeto como por ejemplo una lista, array, etc. Sin embargo, si se est actuando en un escenario en el cual en la mayora de los casos los sujetos no tienen observadores esto produce una penalizacin por uso de una estructura que no se est empleando en cuanto a espacio se refiere. Para evitar esta
-85-
-86-
Patrones de diseo
Patrones de diseo
penalizacin se propone un objeto intermedio que sea el que tenga en cuenta la asociacin aunque esto implique un mayor coste en el acceso a los observadores. En el caso de emplear un intermediario el sujeto no tiene la responsabilidad de actualizar a todos los observadores sino que delega esta tarea en el gestor de observadores. Adems si el gestor de observadores fuese nico se podra emplear un patrn instancia nica.
cuando se recibe una actualizacin se desconoce que sujeto la ha provocado. La postura clsica es recuperar el estado de todos los sujetos que se tienen asociados. Otra alternativa es indicar el sujeto que ha provocado la actualizacin, para ello se puede pasar el sujeto como parmetro del mtodo actualizar. De este modo se puede recuperar selectivamente la inforamcin. o Responsabilidad de inicio de la notificacin: Sujeto invoca la notificacin tras ejecutarse un mtodo que cambie su estado.
Sujeto Modificar() AadirObservador(o)
Gestor de Observadores Actualizar(sujeto)
Observador Actualizar()
Ntese que en caso de emplear un gestor de observadores debe existir un mtodo que a cada sujeto le permite actualizar los observadores que tiene asociados. Adems se debe sealar que se ahorra espacio en el Sujeto, hacindolo ms ligero pero se penaliza en tiempo de ejecucin puesto que de este modo existen dos niveles de indireccin en lugar de uno solo. o Observacin de ms de un sujeto. En algunos casos los observadores dependen del estado de ms de un sujeto (de igual o de distinto tipo). En este caso es necesario cambiar la cardinalidad de la relacin sujeto o tener varias relaciones sujeto.
Clientes del sujeto (posiblemente los propios observadores u otros) son responsables de comenzar la notificacin de actualizacin cuando provoquen un cambio en el sujeto. Esto suele suponer una complicacin adicional en el cliente que, en general, se debe evitar. o Referencias invlidas tras borrar un sujeto. En los lenguajes donde es necesario hacer explcita la gestin de memoria, como por ejemplo C++, si produce un borrado de un sujeto concreto sin considerar los observadores que tiene asociados puede provocar comportamientos inesperados. Para evitar problemas antes de borrar un sujeto se debera hacer una notificacin especial a todos sus observadores. Ntese tambin que antes de proceder al borrado de un observador se debera eliminar este de la asociacin de observadores del sujeto. o Asegurar la consistencia del estado del sujeto antes de iniciar la notificacin. Es importante asegurarnos de que la notificacin se lleve a cabo cuando la transaccin que implica el cambio en el sujeto se ha finalizado. (Ver patrn plantilla). o Evitar actualizacin dependiente del observador:
Desde el punto de vista del funcionamiento del sujeto se funciona del mismo modo pero no desde el punto de vista del observador puesto que
El sujeto notifica los cambios y los observadores piden informacin necesaria para ver si se tienen que actualizar o no. Es lo que se denomina pull model. Este modelo es ineficiente en
-87-
-88-
Patrones de diseo
Patrones de diseo
cuanto a que obliga a preguntar a los observadores aunque el cambio no les vaya a afectar pero reduce el acomplamiento entre jerarquas. El sujeto enva informacin detallada sobre el cambio que ha realizado, de este modo slo los observadores a los que le afecta el cambio se actualizarn. Es lo que se denomina push model. Este modelo es ms eficiente pero menos reusable. o Especificacin explcita de las modificaciones (push model). Cdigo ejemplo: o Ejercicio 1: Analiza las clases del ejemplo proporcionado y elabora un diagrama de clases y de secuencia. o Ejercicio 2: Observa que en el cdigo de los diferentes observadores concretos existen partes comunes que se pueden factorizar. Factoriza las actuaciones comunes para evitar replicar cdigo. o Ejercicio3: Con la nueva implementacin realiza un diagrama de secuencia. o Ejercicio 4: Java proporciona una implementacin del patrn observador. Analizar la documentacin proporcionada en el javadoc de las clases Observable y Observer del paquete java.util. Patrn Iterator o Iterador Clasificacin: De comportamiento porque determina como se debe realizar el intercambio de mensajes entre los diferentes objetos para resolver una tarea. Propsito: Mecanismo de acceso a los elementos que constituyen una estructura de datos sin exponer su representacin interna; es decir, conocer los detalles internos de la estructura. Motivacin: o Se desea acceder a los elementos de un contenedor de objetos (por ejemplo, una lista enlazada) sin exponer su representacin interna: Solucin: Aadir mtodos que permitan recorrer la estructura sin referenciar explcitamente su representacin. Por ejemplo con un vector, aadir elemento, acceder a la posicin i-sima.
Problema: Puede necesitarse ms de una forma de recorrer la estructura: se complica la interfaz de la clase. Por ejemplo, con las listas tienes que aadir recorrer hacia atrs. Problema: Si se necesita un recorrido no previsto es necesario modificar la clase, que ya est funcionando o implementarlo en las clases que usan esa nueva funcionalidad lo cual no es reutilizable. Solucin: Mover la responsabilidad del recorrido a un objeto iterador. Serparar la estructura de datos en dos partes, la que contiene los propios datos y la que sabe en que posicin nos encontramos y como navegar a travs de ella.
No tiene por qu limitarse a recorrer la estructura (por ejemplo, filtrado). Problema: Los clientes de la estructura de datos deben conocer la estructura concreta para crear un iterador. Solucin: Generalizar los distintos iteradores en una superclase y dotar a las estructuras de datos de un mtodo de fabricacin que cree un iterador concreto.
-89-
-90-
Patrones de diseo
Patrones de diseo
o Iterador
Concreto
(ConcreteIterator):
Implementa
la
interfaz
propuesta por el Iterador. Mantiene la posicin actual en el recorrido de la estructura. o Agregado (Aggregate): Define la interfaz para el mtodo de fabricacin de iteradores, es decir, para la creacin de un objeto iterador de la otra jerarqua. o Agregado Concreto (ConcreteAggregate): Implementa la estructura de datos. Implementa el mtodo de fabricacin de iteradotes que crea un iterador especfico para su estructura. Colaboraciones entre participantes: Un iterador concreto mantiene la posicin actual dentro de la estructura de datos e interacta con sta para calcular el Aplicabilidad: o Acceso al contenido de una estructura sin exponer su representacin interna. o Distintos tipos de recorrido sobre la estructura. o Interfaz uniforme para recorrer diferentes tipos de estructuras. Estructura: siguiente elemento en el recorrido. Consecuencias: o Distintos tipos de recorrido. o Simplificacin de la interfaz del agregado. o Ms de un recorrido simultneo. Implementacin: o Control de la iteracin: iterador externo vs. iterador interno. o Definicin del recorrido. o Robustez del iterador ante cambios en la estructura. o Operaciones adicionales en el iterador. o Iteradores pueden necesitar acceso privilegiado. o Iteradores para Composicin. o Iteradores nulos. Patrn Template Method o Plantilla Participantes: o Iterador (Iterator): Define la interfaz para recorrer y acceder al agregado de elementos. Clasificacin: De comportamiento porque determina como se debe realizar el intercambio de mensajes entre los diferentes objetos para resolver una tarea. Propsito: Define el esqueleto de un algoritmo en una operacin, pero difiere algunos pasos a las subclases, debido a que existen partes del algoritmo que dependen de la especializacin. Estas partes se implementarn en las subclases.
-91-
-92-
Patrones de diseo
Patrones de diseo
Motivacin: o Framework para aplicaciones que permiten presentar mltiples documentos al usuario (abstracciones Aplicacin y Documento). o Para una aplicacin especfica, se especializan los conceptos de Aplicacin y Documento. o Problema: La abstraccin aplicacin conoce la operacin genrica a realizar (por ejemplo, abrir un documento), pero parte de la operacin depende del documento concreto. o Solucin: Implementar un mtodo que difiera en otros mtodos abstractos las partes del algoritmo que no se conocen o que son especficas.
o Para controlar la extensiones de las subclases. El mtodo plantilla utiliza mtodos especiales (hooks) que son los nicos puntos que pueden ser redefinidos en las subclases. Los mtodos esqueleto no se deben redefinir en las subclases por ello en Java se indican como mtodos finales (final). Estructura:
Participantes: o Clase Abstracta (AbstractClass): Define operaciones primitivas (normalmente abstractas) que las subclases implementan. Implementa un mtodo plantilla que define el esqueleto de un algoritmo y que utiliza las operaciones primitivas. o Clase Concreta (ConcreteClass): Implementa las operaciones
o Un mtodo plantilla es un mtodo que define un algoritmo en base a una serie de operaciones abstractas que son redefinidas por las. Subclases para obtener un comportamiento concreto. Es decir, hay operaciones genricas comunes a todas las subclases en las que parte de su funcionamiento no se conoce a nivel de las clases genricas. Aplicabilidad: o Implementar las partes invariables de un algoritmo una nica vez y permitir que las subclases definan el comportamiento que cambia (visin top-down). o Factorizacin de comportamiento comn de las subclases en la superclase, evitando la replicacin de cdigo mediante generalizacin (visin botton-up). -93
primitivas que definen el comportamiento especfico del algoritmo para las subclases. Colaboraciones entre participantes: Las clases concretas confan en la clase abstracta la responsabilidad de la parte invariable del algoritmo, mientras que la parte variable es responsabilidad de cada una de las subclases. Consecuencias: o Fundamental para la reutilizacin de cdigo, puesto que evita la repeticin del cdigo genrico facilitando el posterior mantenimiento de este. o Invierte el control: la superclase es la encargada de llamar a las operaciones definidas en las subclases.
-94-
Patrones de diseo
Patrones de diseo
o Distincin entre: Operacin primitiva definida en la superclase normalmente como abstracta para obligar a cada una de las subclases a implementarla. Operaciones de enganche (Hooks) proporcionan cdigo por defecto en la superclase (quiz el comportamiento por defecto, el cual puede ser no hacer nada) que puede ser refinado en las subclases si es necesario. Patrn Visitor o Visitante Clasificacin: De comportamiento porque determina como se debe realizar el intercambio de mensajes entre los diferentes objetos para resolver una tarea. Propsito: Permite definir una operacin sobre objetos de una jerarqua de clases sin modificar las clases sobre las que opera. Motivacin: o Compilador que representa programas como rboles con su sintaxis abstracta. o Necesarias diversas operaciones sobre el rbol sintctico: Comprobacin de tipos, optimizacin de cdigo, reestructuracin de cdigo, generacin de cdigo, instrumentacin... o Cada nodo en el rbol sintctico necesita un tratamiento diferente: clases.
o Problema: Difcil de entender, mantener, modificar y extender puesto que cada clase (variable, asignacin,...) tiene su parte correspondiente de cada una de las operaciones. o Solucin: Agrupar las operaciones relacionadas de cada clase en un objeto (visitante) y pasarlo como argumento a los elementos del rbol sintctico. El elemento acepta al visitante envindole una peticin especfica para su clase con l mismo como argumento: VariableRef VisitVariableRef Assignment VisitAssignment
o Para permitir ms de un visitante, se define una superclase abstracta con una operacin por cada tipo de nodo (dos jerarquas!).
Aplicabilidad: o Varias clases de objetos con interfaces diferentes y se desean realizar operaciones que dependen de sus clases concretas.
-95-
-96-
Patrones de diseo
Patrones de diseo
o Se necesitan diversas operaciones (no siempre relacionadas) sobre objetos de una jerarqua y no se desea recargar las clases con estas operaciones: Agrupa operaciones relacionadas en una clase. Si la jerarqua se usa en diversas aplicaciones, slo se incluyen las operaciones relevantes. o Las clases de la jerarqua no cambian, pero se aaden con frecuencia operaciones a la estructura. Si la jerarqua cambia, NO es aplicable. Estructura:
Colaboraciones entre participantes: o El cliente debe crear un visitante concreto y luego visitar cada elemento de la estructura de objetos con dicho visitante. o Cuando se visita un elemento, ste llama a la operacin del visitante correspondiente a su clase. o Normalmente, el objeto se pasa como argumento para permitir al visitante el acceso a su estado.
Consecuencias: o Aadir operaciones nuevas es sencillo. o Agrupa operaciones relacionadas y separa las no relacionadas. o Difcil aadir nuevas clases de elementos. o No tiene que limitarse a una nica jerarqua de elementos. o Facilita la acumulacin de estado.
Participantes: o Visitante (Visitor): Declara una operacin de visita para cada elemento concreto en la estructura de objetos, que incluye el propio objeto visitado. o Visitante Concreto (ConcreteVisitor): Implementa las operaciones del visitante y acumula resultados como estado local. o Elemento (Element): Define una operacin Accept que toma un visitante como argumento. o Elemento Concreto (ConcreteElement): Implementa la operacin Accept. -97
o Problemas con la encapsulacin. Patrn Command o Comando Clasificacin: De comportamiento porque determina como se debe realizar el intercambio de mensajes entre los diferentes objetos para resolver una tarea. Propsito: Encapsula una peticin como un objeto. Permite la parametrizacion de clientes con diferentes peticiones, crear colas de peticiones y soporte de operaciones cancelables (undo). Motivacin: o En ocasiones es necesario realizar peticiones sin: -98-
Patrones de diseo
Patrones de diseo
Conocer informacin acerca de la operacin a realizar. Conocer informacin acerca del receptor de la peticin. o Ejemplo: Herramientas para la creacin de interfaces de usuario: Botones y opciones de men ejecutan una peticin, pero esa peticin depende de la aplicacin. o Solucin: Convertir la peticin en un objeto. o Clave: Clase abstracta que declara la interfaz para la ejecucin de operaciones. o Macrocomando: composicin de comandos:
o Las subclases concretas de Command especifican el par receptor-accin: Atributo que almacena referencia al receptor. Comportamiento de la clase define la accin. o Comando Pegar: o Fundamental: Separacin del objeto que desencadena la operacin del objeto que conoce como llevarla a cabo: Comparticin de comandos por diferentes elementos. Cambio dinmico de comandos (sensible al contexto) Composicin de comandos (scripting) Aplicabilidad: o Establecer como parmetro de un objeto la accin a realizar (visin OO o Comando Abrir: de un callback) o Especificar, encolar, y ejecutar peticiones en diferentes momentos o Soporte de Deshacer El comando almacena estado para invertir su efecto Aadir mtodo Unexecute a la interfaz del comando Comandos ejecutados se guardan en una lista histrica
-99-
-100-
Patrones de diseo
Patrones de diseo
Undo-Redo recorrer la lista adelante y atrs llamando a Unexecute y Execute respectivamente o Soporte de Logging Aumentando la interfaz del comando con operaciones de salvarguardar (log persistente de cambios) Recuperacin: cargar los comandos guardados e invocar su Execute en secuencia o Soporte de Transacciones Estructura:
o El Comando Concreto invoca las operaciones sobre el receptor para realizar la peticin.
Consecuencias: o Desacoplamiento del objeto que invoca la operacin del objeto que conoce como llevarla a cabo. o Comandos pueden ser manipulados y extendidos como cualquier objeto. o Composicin de comandos. o Fcil aadir comandos: no es necesario modificar clases existentes.
Participantes: o Comando (Command): Declara la interfaz para ejecutar una operacin. o Comando Concreto (ConcreteCommand): Define un vnculo entre un objeto receptor y una accin. Implementa la interfaz Comando, invocando la operacin sobre el receptor o Cliente (Client): Crea un Comando Concreto y establece su receptor o Invocador (Invoker): Solicita al comando que ejecute su accin o Receptor (Receiver): Conoce cmo realizar las operaciones asociadas con la ejecucin de un comando Colaboraciones entre participantes: o Cliente crea Comando Concreto y especifica su receptor. o El invocador enva el mensaje Execute a un comando. o El Comando Concreto almacena el estado necesario para deshacer.
Implementacin: o Responsabilidad asignada al comando. o Soporte de Undo/Redo. o Evitar acumulacin de errores en el proceso de deshacer.
Patrn Memento o Recuerdo Clasificacin: De comportamiento porque determina como se debe realizar el intercambio de mensajes entre los diferentes objetos para resolver una tarea. Propsito: Permite capturar y extraer el estado interno de un objeto, sin violar su encapsulacin, de tal modo que se puede restaurar su estado a posteriori. Motivacin: Operaciones de deshacer, transacciones... Aplicabilidad: o Cuando se dan las dos siguientes condiciones: Una imagen del estado del objeto (o un subconjunto) debe ser almacenado de tal forma que pueda ser restaurado ms tarde. -102-
-101-
Patrones de diseo
Patrones de diseo
Una interfaz directa para obtener el estado expondra detalles de implementacin, violando la encapsulacin del objeto. Estructura:
Consecuencias: o Evita la exposicin de informacin que slo debe gestionar el originante, pero que debe guardarse fuera de ste. o Simplifica el originante, al separar la gestin de los recuerdos. o Puede resultar costoso. o Difcil en algunos lenguajes el soporte de dos visibilidades distintas. o Oculta el coste de almacenamiento del recuerdo.
Participantes: o Recuerdo (Memento): Almacena el estado interno de la clase Originante. Slo permite el acceso al estado almacenado a la clase Originante. o Originante (Originator): Crea un Recuerdo con la imagen de su estado actual. Usa un Recuerdo para restaurar su estado interno. o Cuidador (Caretaker): Responsable de almacenar los Recuerdos. No opera o examina el contenido de los Recuerdos. Colaboraciones entre participantes: o El cuidador solicita un recuerdo del originante, lo almacena por un tiempo, y si es necesario, lo devuelve al originante
Implementacin: o Soporte de dos visibilidades diferentes o Almacenamiento de cambios incrementales Particularmente til en la implementacin de operacin deshacer dado que se conoce la secuencia de cambios realizados (histrico)
Patrn Mediator o Mediador Clasificacin: De comportamiento porque determina como se debe realizar el intercambio de mensajes entre los diferentes objetos para resolver una tarea. Propsito: Define un objeto que encapsula la interaccin entre varios objetos independientes. Motivacin: o OO distribuye comportamiento/responsabilidad entre objetos: Estructura de objetos con mltiples conexiones Caso extremo: objetos totalmente conexos o Consecuencia: prdida de independencia reduce reusabilidad: El sistema acta de forma monoltica: para reusar un componente se necesitan aquellos de los que depende Difcil cambiar el comportamiento al estar repartido entre muchos objetos o Ejemplo: Ventanas de dilogo
o Los recuerdos son pasivos -103-104-
Patrones de diseo
Patrones de diseo
o Existen dependencias entre los componentes: Selecciones realizadas sobre unos componentes pueden modificar el estado de otros componentes. o Diferentes dilogos tienen diferentes dependencias entre los o El coordinador media entre la lista de seleccin y el campo de edicin: Lista de seleccin cambio al mediador. Mediador consultaba el valor actual de la lista. Mediador solicita al campo de edicin que cambie.
componentes: Necesario extender clases existentes para implementar el comportamiento especfico (tedioso, no reutilizable) o Solucin: Encapsular el comportamiento colectivo en un objeto mediador: Responsable de controlar y coordinar la interaccin. Intermediario que evita el conocimiento directo entre los objetos (los objetos slo conocen al coordinador)
Aplicabilidad:
-105-
-106-
Patrones de diseo
Patrones de diseo
o Un conjunto de objetos se comunican de manera compleja, siendo sus interdependencias difciles de entender. o Es difcil reusar un objeto porque hace referencia y se comunica con otros objetos. o El comportamiento de un conjunto de objetos debe ser personalizable sin necesidad de extender muchas clases. Estructura:
mediador en lugar de hacerlo directamente con los restantes objetos coordinados. Colaboraciones entre participantes: o Slo hay comunicacin coordinado mediador. o El mediador implementa la coordinacin redirigiendo los mensajes a los objetos apropiados. Consecuencias: o Reduce las extensiones de clases existentes. o Desacopla objetos coordinados. o Simplifica protocolo entre objetos. o Abstrae la forma de cooperacin de los objetos. o Centraliza el control. Implementacin: o Omisin de la clase abstracta Mediador. o Comunicacin medidor objetos coordinados: Patrn Observador. Interfaz de notificacin especfico. o Soporte de Observadores complejos.
Participantes: o Mediador (Mediator): Define la interfaz para la comunicacion con los objetos coordinados. o Mediador coordinados. o Clases coordinadas (Colleague classes): Cada clase coordinada conoce a su mediador. Un objeto de la clase coordinada se comunica con su Concreto (ConcreteMediator): Implementa el
comportamiento cooperativo. Conoce y mantiene a los objetos
-107-
-108-
Patrones de diseo
Patrones de diseo
BIBLIOGRAFA Y REFERENCIAS E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns. Elements of Reusable Object-Oriented Software. Addison-Wesley Professional Computing Series, 1995. ISBN: 0-201-63361-2. Sitio Web del libro anterior http://hillside.net/patterns/DPBook/DPBook.html [Ultimo acceso 10 de febrero de 2010]. Larman, Craig. UML y patrones. Segunda Edicin. Prentice Hall. 2002. Sitio Web de Vctor Gulas http://www.fi.udc.es/~gulias [ltimo acceso 20 de enero de 2009] M. Fowler, K. Scott. UML Distilled. Addison-Wesley Longman, 1997. G. Booch, I. Jacobson, J. Rumbaugh. El Lenguaje Unificado de Modelado. Gua del usuario. Addison-Wesley,1999. J. Rumbaugh, I. Jacobson, G. Booch, El Lenguaje Unificado de Modelado. Manual de referencia. Addison-Wesley, 2000. K. Arnold, J. Gosling. The Java Programming Language. The Java Series, AddisonWesley, 1998. Herbert Schilt. Java 2. Manual de Referencia. McGraw-Hill, 2001. ISBN: 8448131738.
-109-
-110-

TeoriaPatronesV2 - 2 Antecedente

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TeoriaPatronesV2 - 2 Antecedente

Uploaded by

Copyright:

Available Formats

Patrones de diseo

Mster en Bases de Datos e Internet

3 3 3 7 7 9 10 11 11 12 12 22 29 39 43 45 49 54 54 58 60 63 65 68 68 73 78 82 89 92 95 98 102 104 110

TALLER DE PATRONES DE DISEO

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Clasificacin de los patrones de diseo ms conocidos

Clasificacin de patrones de diseo Se realiza una clasificacin en base a dos criterios:

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Estructura (Generalizacin del problema para aplicarlo a diferentes mbitos):

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

objetos sin decorar y decorados se (visualComponent).

considera una interfaz comn

(responsabilidades) al componente (refinamiento). Colaboraciones entre participantes:

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Public class Main{

Unidad p = new Escudo( new Soldado("mi_unidad") ); -35-36-

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Unidad mi_unidad = new Pistola(new Escudo(new Soldado("mi_unidad"))); mi_unidad = mi_unidad.suprime_complemento("ESCUDO");

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet

Mster en Bases de Datos e Internet