GUIA DE PATRONES DE DISEO

Indice
Introduccin
1.- INTRODUCCION. 1.1.- Origen. 1.2.- Qu son los Patrones de Diseo?. 1.3.- Qu ventajas ofrece?. 1.4.- Caractersticas. 1.5.- Clasificacin. 1.6.- Patrones y Armazones (Frameworks) . 1.7.- Formas de Descripcin. 1.8.- Otros Patrones .

Creacin
2.- PATRONES DE CREACION. 2.1.- Factora Abstracta. 2.2.- Builder - Creador. 2.3.- Mtodo Factora - Factory Method - Virtual Constructor. 2.4.- Prototipo - Prototype . 2.5.- Singleton .

Estructurales
3.- PATRONES ESTRUCTURALES. 3.1.- Adaptador - Class Adapter - Object Adapter - Wrapper . 3.2.- Bridge - Handle/Body. 3.3.- Proxy - Surrogate - Virtual Proxy . 3.4.- Composite . 3.5.- Decorador - Decorator - Wrapper. 3.6.- Fachada - Facade .

Comportamiento
4.- PATRONES DE COMPORTAMIENTO. 4.1.- Chain of Responsability - Expert - Experto. 4.2.- Command . 4.3.- Interprete - Interpreter . 4.4.- Iterador - Iterator . 4.5.- Mediador - Mediator . 4.6.- Memento . 4.7.- Observador - Observer. 4.8.- Estado - State . 4.9.- Estrategia - Strategy . 4.10.- Template method .

4.11.- Visitor . 4.12.- Viewer/Controller - Vista/Controlador.

Antipatrones
5.- APARTADO A. Antipatrones . 5.1.- Desarrollo de Software. 5.2.- Arquitectura del Software. 5.3.- Gestin de Proyectos Software.

Herramientas
6.- APARTADO B. Herramientas. 6.1.- ModelMaker . 6.2.- ACE . 6.3.- Code Farms . 6.4.- FAMOOS . 6.5.- SCG Research Projects.

Autores
7.- Autores.

Conferencias
8.- Conferencias.

Links
9.- APARTADO E. Links. 9.1.- Links de Patrones de Diseo. 9.2.- Links de Patrones de Arquitectura. 9.3.- Links de Patrones por Tipo. 9.4.- Links de Antipatrones. 9.5.- Links de Grupos de Estudio. 9.6.- Links de Arquitecturas de Objetos.

INTRODUCCION
Anterior - Indice - Siguiente

Los Patrones de Diseo nos hablan de como construir software, de como utilizar las clases y los objetos de forma conocida. Es necesario tener conocimientos previos de Programacin Orientada a Objetos para entender los Patrones, es conveniente tambien tener almenos nociones de UML para seguir los ejemplos y diagramas que aqu se presentan.

Origen
Anterior - Indice - Siguiente

Los precedentes a los patrones de diseo vienen del campo de la Arquitectura, Christopher Alexander a finales de los 70 escribe varios libros acerca de urbanismo y construccin de edificios, y se plantea reutilizar diseos ya aplicados en otras construcciones que cataloga como modelos a seguir.

En 1987 Ward Cunningham y Kent Beck utilizan las ideas de Alexander para desarrollar un lenguaje de patrones como gua para los programadores de Smaltalk, dando lugar al libro "Using Pattern Languajes dor Object-Oriented Programs". Posteriormente en 1991 Jim Coplien publica el libro "Advanced C++ Programming Styles and Idioms", donde realiza un catalogo de "idioms" (especie de patrones) Entre 1990 y 1994, Erich Gamma, Richard Helm, Ralph Johnson y Hohn Vlissides (conocidos como el grupo de los cuatro) realizan el primer catlogo de patrones de diseo, que publican en el libro "Design Patterns: Elements of Reusable Object-Oriented Software" (Gang of Four)

Qu son los Patrones de Diseo?

Anterior - Indice - Siguiente

Christopher da la siguiente definicin de patrn: "Cada patrn describe un problema que ocurre una y otra vez en nuestro entorno, para describir despus el ncleo de la solucin a ese problema, de tal manera que esa solucin pueda ser usada ms de un milln de veces sin hacerlo ni siquiera dos veces de la misma forma".

Qu ventajas ofrece?
Anterior - Indice - Siguiente

El software ha ido aumentando su complejidad de forma pareja a la potencia de las computadoras, el aumento del conocimiento de

los usuarios, incremento de las posibilidades de la informtica, de las nuevas posibilidades que ofrecen las redes e Internet, etc. Los patrones de diseo proponen una forma reutilizar la experiencia de los desarrolladores, para ello clasifica y describe formas de solucionar problemas que ocurren de forma frecuente en el desarrollo. Por tanto est basado en la recopilacin del conocimiento de los expertos en desarrollo de software. No debe verse los Patrones de Diseo como una teora o una corriente. No trata de tomar partido por una u otra alternativa. Es una experiencia real, probada y que funciona. Es Historia y nos ayuda a no cometer los mismos errores.

Caractersticas
Anterior - Indice - Siguiente

Son soluciones concretas. Proponen soluciones a problemas concretos, no son teoras genricas. Son soluciones tcnicas. Indican resoluciones tcnicas basadas en Programacin Orientada a Objetos (POO). En ocasiones tienen ms utilidad con algunos lenguajes de programacin y en otras son aplicables a cualquier lenguaje. Se utilizan en situaciones frecuentes. Ya que se basan en la experiencia acumulada la resolver problemas reiterativos. Favorecen la reutilizacin de cdigo. Ayudan a contruir software basado en la reutilizacin, a construir clases reutilizables. Los propios patrones se reutilizan cada vez que se vuelven a aplicar. El uso de un patrn no se refleja en el cdigo. Al aplicar un patrn, el cdigo resultante no tiene por que delatar el patrn o patrones que lo inspir. No obstante ltimamente hay multiples esfuerzos enfocados a la construccin de herramientas de desarrollo basados en los patrones y frecuentemente se incluye en los nombres de las clases el nombre del patrn en que se basan facilitando as la comunicacin entre desarrolladores. Es dificil reutilizar la implementacin de un patrn. Al aplicar un patron aparecen clases concretas que solucinan un problema concreto y que no ser aplicable a otros problemas que requieran el mismo patrn: Una ventana es una solucin para ventilar e iluminar un habitculo, pero la ventana de mi casa no es util en el camarote de un barco.

Clasificacin
Anterior - Indice - Siguiente

Clasificacin segn su propsito: Patrones de Creacin: Tratan la creacin de instancias. Patrones Estructurales: Tratan la relacin entre clases, la combinacin clases y la formacin de estructuras de mayor complejidad. Patrones de Comportamiento: Tratan la interaccin y cooperacin entre clases.

Clasificacin segn su mbito: De clase: Basados en la herencia de clases. De objeto: Basados en la utilizacin dinmica de objetos.

Patrones y Armazones (Frameworks)

Anterior - Indice - Siguiente

Los armazones estn bastante relacionados con los Patrones. Un armazn es un modelo arquitectonico que describe una estructura de software facilmente ampliable y reutilizable.

Formas de Descripcin
Anterior - Indice - Siguiente

Los autores del Libro AIS proponen un modelo de descripcin de los patrones que seguiremos en este documento:

Patron
INTENCION Objetivos del patron CONOCIDO COMO Otros nombres MOTIVO Motivaciones que justifican que se considere como un patron APLICACIONES Posibles usos ESTRUCTURA Esquema grfico que describe el patrn. PARTICIPANTES

Descripcin de los elementos que intervien COLABORACIONES Descripcin de las relaciones entre los PARTICIPANTES CONSECUENCIAS Beneficios, riesgos, perjuicios que puede ocasionar su uso IMPLEMENTACIN Informacin de detalle sobre la implementacin, decisiones de diseo, formas de codificacin CODIGO DE EJEMPLO Codigo de un ejemplo de utilizacin USOS CONOCIDOS Productos y sistemas conocidos que recuerde rpidamente el lector y facilite su comprensin P. RELACIONADOS Patrones que pueden funcionar como alternativa o de forma complementaria

Otros Patrones
Anterior - Indice - Siguiente

Adems de los Patrones de Diseo tenemos: Patrones de Arquitectura. Formas de descomponer, conectar y relacionar sistemas, trata conceptos como: niveles, tuberas y filtros. Es un nivel de abstraccin mayor que el de los Patrones de Diseo. Patrones de Programacin (Idioms Patterns). Patrones de bajo nivel acerca de un lenguaje de programacin concreto, describen como implementar cuestiones concretas. Patrones de Analisis. Conjunto de reglas que permiten modelar un sistema de forma satisfactoria. Patrones de Organizacionales. Describen como organizar grupos humanos, generalmente relacionados con el software. Otros Patrones de Software. Se puede hablar de patrones de Programacin concurrente, de Interfaz Grfica, de Organizacin de Cdigo, de Optimizacin de Cdigo, de Robustez de Cdigo, de Fase de Prueba.

PATRONES DE CREACION
Anterior - Indice - Siguiente

Los patrones de creacin abstraen la forma en que se crean los objetos, de forma que permite tratar las clases a crear de forma

genrica apartando la decisin de qu clases crear o como crearlas. Pero los Patrones de Diseo son conceptos aplicables directamente en la produccin de software, cualquier abstraccin no se queda en el aire como una entelequia que solo sirve para dar discursos, as: Segn a donde quede desplazada dicha decisin se habla de Patrones de Clase (utiliza la herencia para determinar la creacin de las instancias, es decir en los constructores de las clases) o Patrones de Objeto (es en mtodos de los objetos creados donde se modifica la clase)

Patrones de Creacin de Clase:

Factora Abstracta Builder

Patrones de Creacin de Objeto:

Mtodo Factora Prototipo Singleton Object Pool

Factora Abstracta
Anterior - Indice - Siguiente

Factora Abstracta
INTENCION Proporciona un Interfaz para crear familias de objetos sin especificar su clase de forma concreta CONOCIDO COMO Abstract Factory, Kit. MOTIVO Proporciona un interfaz comn para crear diferentes familias de clases. APLICACIONES En muchas ocasiones existen diferentes recursos para realizar lo mismo, e incluso se presume que existirn nuevos recursos y queremos desarrollar sistemas compatibles con todos ellos, piensese en el caso de los escritorios KDE/GNOME, las libreras MOTIF/Windos/OpenView, las libreras OpenGL/DirecX. Si deseamos que nuestro software funcione sobre distintos recursos debemos abstraernos de que libreras utilizamos. ESTRUCTURA

PARTICIPANTES FACTORIA ABSTRACTA: Abstrae que clases se instancian. Encapsula la funcionalidad que se desea, es la via de comunicacin hacia las clases concretas instanciadas. FACTORAS CONCRETAS: Clases encargadas de la instanciacin de clases de una familia u otra.

COLABORACIONES Toda relacin entre el exterior del sistema y las clases de la factoria se realiza nicamente a travs de los metodos de la clase abstracta, se puede utilizar metodos virtuales en la clase abstracta para acceder a los mtodos de las clases a instanciar. CONSECUENCIAS Ocultacin de las clases de implementacin. Esto tambien permite ofrecer clases sin mostrar su implementacin, pudiendonos reservar la posibilidad de cambiar la implementacin en el futuro. Facilidad de sustitucin de conjuntos de clases por otras equivalentes. Consistencia entre productos, al desarrollarse las aplicaciones con un mismo conjunto homogneo de clases, dichas aplicaciones son ms consistentes entre ellas.

IMPLEMENTACIN Informacin de detalle sobre la implementacin, decisiones de diseo, formas de codificacin CODIGO DE EJEMPLO

USOS CONOCIDOS

P. RELACIONADOS

Builder - Creador
Anterior - Indice - Siguiente

Builder
INTENCION Permite a un cliente crear un objeto especificando tipo y contenido, ocultandose el resto de detalles. CONOCIDO COMO Builder, Creador MOTIVO La creacin de objetos o instanciacin de clases es uno de los temas ms frecuentes en la Programacin Orientada a Objetos. Este patrn permite tener una poltica general para la creacin de objetos, centralizandolo en una clase Builder. APLICACIONES Una clase superior Builder se aplica en la creacin de clases menores... Cuando sea necesario crear y agregar instancias de clases. Cuando sea necesario contener multiples instancias de clases. Cuando la clase superior dispone de los datos necesarios para la clase a instanciar.

ESTRUCTURA

PARTICIPANTES

COLABORACIONES

CONSECUENCIAS Reduce el acoplamiento. Permite variar la representacin interna de estructuras compleja, respetando la interfaz comun de la clase Builder. Se independiza el cdigo de construccin de la representacin. Las clases concretas que tratan las representaciones internas no forman parte de la interfaz del Builder. Cada ConcreteBuilder tiene el cdigo especifico para crear y modificar una estructura interna concreta. Distintos Director con distintas utilidades (visores, parsers, etc) pueden utilizar el mismo ConcreteBuilder. Permita un mayor control en el proceso de creacin del objeto. El Director controla la creacin paso a paso, solo cuando el Builder ha terminado de construir el objeto lo recupera el Director.

IMPLEMENTACIN El Builder posee un interfaz con cada operacin que se puede realizar, el ConcreteBuilder implementa esas operaciones.

CODIGO DE EJEMPLO

USOS CONOCIDOS Tratamiento de diferentes formatos de archivos. Creacin de objetos complejos independientes de los elementos que lo componen.

P. RELACIONADOS Composite. La clase Builder suele devolver un Composite. Director. Mtodo Factora. Se puede utilizar el Mtodo Factora para decidir que clase concreta instanciar. Factora Abstracta y Visitor: A diferencia de la Factora Abstracta y Visitor, el Builder permite controlar paso a paso la creacin del objeto.

Mtodo Factora - Factory Method - Virtual Constructor

Anterior - Indice - Siguiente

Mtodo Factora
INTENCION Abstraer la instanciacin de clases relegando esta responsabilidad a las mismas clases. CONOCIDO COMO Factory Method, Virtual Constructor. MOTIVO Es un modelo que utiliza abstraccin de clases para crear y relacionar objetos sin conocer de qu clase son. APLICACIONES Se utiliza cuando la aplicacin no sabe de antemano el tipo de objeto que se va a crear, es en tiempo de ejecucin cuando toma la decisin. ESTRUCTURA

PARTICIPANTES

COLABORACIONES

CONSECUENCIAS

IMPLEMENTACIN

CODIGO DE EJEMPLO

USOS CONOCIDOS

P. RELACIONADOS

Prototipo - Prototype
Anterior - Indice - Siguiente

Prototipo
INTENCION Permite crear objetos copiando un modelo existente. CONOCIDO COMO Prototype MOTIVO Reducir el nmero de clases. APLICACIONES Se utiliza cuando se quiere abstraer el proceso de creacin de objetos y cuando las clases a instanciar se conocen en tiempo de ejecucin. Para reducir el nmero de clases a desarrollar (que implicara una grn cantidad de factoras). Cuando los objetos de una clase tengan pocas combinaciones de estados distintos. ESTRUCTURA

PARTICIPANTES Cliente La clase que crea nuevos objetos mediante el mtodo clone de los prototipos. Prototype Clase (generalmente abstracta) que declara el mtodo clone().

PrototypeConcreto1 y PrototypeConcreto2 Clases que heredan de Prototype e implementan el mtodo clone() para realizar copias de si mismo.

COLABORACIONES

CONSECUENCIAS Reduce el nmero de clases. Permite crear objetos en tiempo de ejecucin con los atributos o valores de otro existente. La clse cliente no necesita conocer las clases de los objetos a crear, le basta con sable que heredan de Prototype. No es necesario crear una estructura de herencia de clses complicada. La clase cliente puede crear nuevos prototipos variando los existentes. Al implementar cada clase su mtodo clone se garantiza que cada objeto crea una instancia coherente.

IMPLEMENTACIN Se puede tener una Factora Abstracta u otro sistema para gestionar los prototipos. La implementacin del mtodo Clone se puede hacer en profundidad (Deep Copy) o superficial (Shadow Copy): Superficial Se copian los valores de los atributos y las referencias a otros objetos, con

lo cual el original y la copia contienen referencias a los mismos objetos que los componen. En Profundidad Se copian los valores y se clonan los objetos contenidos o se crean nuevas instancias para luego asignarles los mismos valores. En este caso se obtiene una copia identica al original pero con referencias a objetos particulares. La clonacin debe devolver un objeto identico al clonado, en todos sus atributos, para luego modificarlo. En caso de necesitarse uno "vacio" se construir apartir de la clase de forma normal o clonando una instancia no modificada. CODIGO DE EJEMPLO

USOS CONOCIDOS Los JavaBean de Java se basan en el patrn Prototype. P. RELACIONADOS Composite Es utilizado a menudo junto a Prototype, sobre todo en la parte de la clase Cliente, de forma que el cliente se compone de objetos que puede crear clonando otros. Ciertos atributos de los objetos que lo componen van a ser semejantes, como toda la informacin referente a la clase que componen y referente al contexto del mismo. Facade La clase cliente se comporta frecuentemente como un patrn Facade que independiza al resto de la aplicacin de las clases prototipo. Factory Method El patron prototype es util como alternativa a Factory Method cuando ste provoca un nmero muy elevado de clases.

Singleton
Anterior - Indice - Siguiente

Singleton
INTENCION Ofrecer una instancia de una clase y un punto de acceso a la misma. CONOCIDO COMO Singleton MOTIVO Modelo que garantiza que solo hay una instancia y que se puede acceder a ella por todos. Para ello en lugar de tener una variable global, la instancia se almacena un un atributo estatico de la clase y se accede a ella por el mtodo getInstance.

APLICACIONES Para aquellos casos en que hay que compartir recursos nicos como una memoria compartida por varios Threads, un Spool, etc. ESTRUCTURA

PARTICIPANTES Singleton La clase singleton ofrece los servicios que se desean controlar desde una instancia nica. Aplicacin La aplicacin que hace uso de la clase Singleton para acceder a sus servicios.

COLABORACIONES

CONSECUENCIAS Solo existe una instancia de la clase Singleton. Las clases que requieran acceder a la instancia de Singleton lo consiguen mediante el mtodo de recuperacin de la instancia Singleton: getInstance. Evidentemente el metodo getInstance debe ser esttico (para acceder sin una instancia concreta) o mtodo de clase, en lenguajes que no dispongan de esta facilidad se puede usar una funcin global.

IMPLEMENTACIN La implementacin consiste en utilizar un metodo esttico de clase para recuperar la nica instancia de la clase o crear una instancia si no exista ninguna. CODIGO DE EJEMPLO
class Singleton{ private static Singleton instanciaUnica=null; public static Singleton instance(){ if (instaciaUnica==null){ instanciaUnica=new Singleton(); } return instanciaUnica; } }

USOS CONOCIDOS La clase java.lang.Runtime del API de Java es una clase Singleton, no tiene constructores pblicos y se obtiene su nica instancia llamando a getRuntime() P. RELACIONADOS El patrn Singleton se puede combinar con otros muchos, no obstante es muy frecuente utilizarlo junto a patrones Abstract

Factory, Builder y Prototype, es decir, para obtener una instancia nica que utilizaremos para construir objetos. Tambien se le ha relacionado con el patrn Cache Management, utilizado para implementar cache de objetos, solo que el patrn Singleton tendra un cache de un solo objeto.

PATRONES ESTRUCTURALES
Anterior - Indice - Siguiente

Patrones de Estructurales de Clase:

Herencia Multiple Class Adapter

Patrones de Estructurales de Objeto:

Object Adapter Bridge Composite Decorator Facade Flyweight Proxy

Adaptador - Class Adapter - Object Adapter Wrapper

Anterior - Indice - Siguiente

Adaptador
INTENCION Convierte la interfaz de una clase en otra ms compatible con nuestras necesidades. CONOCIDO COMO Class Adapter, Object Adapter, Wrapper MOTIVO Reduce la dependencia entre clases. APLICACIONES Para utilizar la interfaz de una librera que no coincide con la que se requiere. Para extender la funcionalidad de una librera existente.

ESTRUCTURA Adaptador de Clase

Adaptador de Objeto

PARTICIPANTES Cliente Clase que hace uso de otras clases a travs de un interfaz que no se tiene por que corresponder con el implementado en dichas clases. InterfazObjetivo Clase que declara el interfaz al que llama la clase cliente. Adaptador Clase que implementa el enlace entre el interfaz desdeado (u objetivo) y el que realmente existe (ofrecido por la ClaseExistente) ClaseExistente Tambien llamada adaptada o adaptee, el la clase original de que se dispone.

COLABORACIONES

CONSECUENCIAS El cliente es independiente de las clases finales que utiliza. Es posible utilizar la clase Adaptador para monitorizar que clases llaman a qu mtodos de las clases finales.

Adaptador de Clase:

El cliente es independiente de las clases que utiliza.

La clase adaptadora puede redefinir y ampliar la interfaz de la clase adaptada. La clase adaptadora utiliza la interfaz de la clase adaptada, puede ser que no sean vlidos todas las subclases de la clase adaptada (ya que hereda una clase concreta). Es posible utilizar la clase Adaptador para monitorizar que clases llaman a qu mtodos de las clases finales.

Adaptador de Objeto: La clase adaptadora puede utilizar todas las subclases de la clase adaptada, ya que tiene constancia de los objetos que instancia.

IMPLEMENTACIN El Adaptador de Clase se implementa mediante una clase que hereda simultaneamente de dos clases, la objetivo que contiene el interfaz deseado y la clase original, que contiene la implementacin. Mediante sobrecarga (caso de C++ p.e) o implementacin de la interfaz (caso de Java, ActiveX, etc) se conecta el interfaz con los mtodos de la clase original. El Adaptador de Objeto se implementa mediante una clase con el interfaz objetivo que contiene una instancia de la clase original (la que contiene la implementacin), se construyen los miembros de la interfaz destino mediante llamadas al objeto original. CODIGO DE EJEMPLO

USOS CONOCIDOS HierarchyBoundsAdapter? WindowAdapter? P. RELACIONADOS Facade Es una alternativa a Adaptor cuando en lugar de a un solo objeto se necesita llamar a varios. Iterator Es un Adaptador especializado en recorrer colecciones de objetos. Proxy Es similar a Adaptor excepto en que Proxy ofrece el mismo interfaz al de la clase a la que se llama. Strategy Tambien es similar a Adaptor, pero Strategy adems pretende cambiar la funcionalidad del mtodo llamado.

Bridge - Handle/Body
Anterior - Indice - Siguiente

Bridge

INTENCION Separa una abstraccin de su implementacin de forma que ambas pueden evolucionar por separado. CONOCIDO COMO Handle/Body MOTIVO La herencia permite tener diferentes implementaciones de una abstraccin. En ocasiones una jerarqua de clases requiere implementaciones para diferentes plataformas, por lo que hay que separar la abstraccin de la implementacin.

APLICACIONES Para evitar una vinculacin permanente entre un interfaz y su implementacin, ya que la ligadura se produce en tiempo de ejecucin. Cuando tanto la abstraccin como la implementacin van a formar un arbol de clases derivadas. Para evitar recompilar los clientes cuando cambien las implementaciones. El patrn Adaptador se suele utilizar entre clases ya esistentes, el patron Bridge se suele utilizar al comienzo del proyecto, cuando tanto las abstracciones como las implementaciones estn en evolucin.

ESTRUCTURA

PARTICIPANTES

COLABORACIONES

CONSECUENCIAS

IMPLEMENTACIN

Una Factoria Abstracta permite crear y configurar un Bridge concreto, decidiendo qu clase instanciar, esta factora puede ser un Singleton. CODIGO DE EJEMPLO

USOS CONOCIDOS ContentHandler/ContentHandlerFactory P. RELACIONADOS

Proxy - Surrogate - Virtual Proxy

Anterior - Indice - Siguiente

Proxy
INTENCION Un objeto sustituye a otro para controlar el acceso al mismo. CONOCIDO COMO Surrogate, Virtual Proxy MOTIVO En ocasiones se desea retrasar la instanciacin de un objeto hasta que sea necesario utilizarlo. As el objeto proxy lo sustituye ofreciendo la misma interfaz, solo cuando es necesario le solicita al objeto real la informacin que necesita. Otro motivo para su uso es sustituir a un sistema remoto, de forma que se accede al mismo atravs de una clase proxy, que permite controlar el acceso al mismo. APLICACIONES Proxy Remoto Cuando el objeto est en un sistema remoto. Proxy Virtual Para retrasar la creacin de objetos hasta que sean necesarios. Proxy de Proteccin Para controlar el acceso a un objeto. Proxy de Sincronizacin Para gestionar accesos de multiples clientes a un recurso. Referencias Inteligentes Para gestin y mantenimiento del acceso a un objeto real, permite contabilizar su utilizacin de cara a gestionar sus recursos e incluso destruirlo cuando ya no se necesita. Tambien permite sincronizar accesos concurrentes al mismo, bloqueandolo mientras est en uso.

ESTRUCTURA

PARTICIPANTES Cliente La aplicacin, utiliza el interfaz de la clase proxy para hacer uso de la clase original. Proxy Ofrece un interfaz equivalente al de la clase Original, pudiendo derivar de una clase comn. Puede realizar un preprocesamiento y un postprocesamiento sobre los servicios ofrecidos por la clase original, este procesamiento adicional puede tener los objetivos de: transformar infomacin (parametros de llamada y resultados), control de acceso, tareas de conexin remota, retraso en la instanciacin, destruccin de instancias y cach. Original Es la clase que implementa los servicios ofrecidos, puede ser una instancia local o remota.

COLABORACIONES

CONSECUENCIAS Puede mejora la eficiencia al controlar la instanciacin de recursos y al hacer cache. Aumenta la seguridad. Los clientes se desentienden de la ubicacin de los componentes accedidos.

IMPLEMENTACIN Se disea la clase Proxy con iguan interfaz que la clase original, si es posible se hereda de una clase abstracta comn a la clase original. Segn el tipo de proxy (remoto, virual, etc) se le aaden mtodos de preprocesamiento y postprocesamiento donde se implementan las funciones de control, etc. Se enlaza el Proxy con la clase Original mediante instancias locales, referencias o punteros, sockets, etc. Se implementa el cliente haciendo uso de la clase Proxy en lugar de la Original.

CODIGO DE EJEMPLO

USOS CONOCIDOS OMG-CORBA, Orbix, Clase Proxy del API Java. P. RELACIONADOS

Composite

Anterior - Indice - Siguiente

Composite
INTENCION Construir objetos de complejidad mayor mediante otros ms sencillos de forma recursiva, formando una estructura similar a un arbol. CONOCIDO COMO Composite MOTIVO Las aplicaciones grficas frecuentemente requieren agrupar objetos en contenedores y utilizarlos de forma semejante aun siendo elementos individuales distintos. Permite a las clases cliente utilizar de igual forma los objetos compuestos que los individuales. APLICACIONES Cuando sea necesario utilizar de igual forma objetos sencillos que agrupaciones de estos. ESTRUCTURA

PARTICIPANTES Cliente Clase que crea los objetos. ComponenteAbstracto Clase abstracta comn a todos los objetos, define los mtodos u operaciones que pueden realizar tanto los objetos individuales como los compuestos. CompositeAbstracto Declara los mtodos propios de los objetos compuestos, normalmente add(Componente) para aadir componentes tanto individuales como compuestos, remove(componente) para eliminarlos,

getChild(n) para poder recuperar los distintos objetos que lo compone. Componente Representa as clases individuales, no compuestas. CompositeConcreto1 y CompositeConcreto2 Clases concreta compuestas. COLABORACIONES

CONSECUENCIAS Se crea una jerarquia de objetos bsicos y de composiciones de estos. Simplifica el cliente al tratar todos de igual forma. Facilita agregar nuevas clases insertandolas en un contenedor compatible. Generaliza el diseo.

IMPLEMENTACIN Gestionar los enlaces al padre. Estudiar si se desea que una agrupacin admite agrupaciones o solo objetos simples. Operaciones de gestin de nodos hijos (add, remove, getChild). Estudiar si interesa que tenga significado el orden de los hijos. Estudiar la destruccin de los objetos. Por ejemplo las VCL de Borland independizan al padre (parent, contenedor que contiene los hijos) del propietario (owner, padre responsable de crearlos/destruirlos) Se pueden utilizar Iteradores para recorrer los integrantes. Visitor puede realizar operaciones para evitar el distribuirlas por los hijos.

CODIGO DE EJEMPLO

USOS CONOCIDOS Composite P. RELACIONADOS Chain of Responsability

Decorador - Decorator - Wrapper

Anterior - Indice - Siguiente

Decorador
INTENCION Aadir nuevas responsabilidades dinmicamente a un objeto, es una alternativa a crear demasiadas subclases por herencia. CONOCIDO COMO Decorator, wrapper MOTIVO Permite aadir nuevas responsabilidades a una instancia concreta y no a toda la clase y subclases. APLICACIONES Para aadir funcionalidad a una clase sin utilizar herencia. Cunado se quiera aadir funcionalidad a una clase de forma dinmica en tiempo de ejecucin.

ESTRUCTURA

PARTICIPANTES Componente Clase abstracta comn a todas las clases susceptibles de ser ampliadas con el decorator. ComponenteConcreto Son las clases cuya funcionalidad se puede exteder y en los que se delega en ultima instancia para realizar las operaciones propias de la clase. Decorator Clase abstracta que declara la estructura comn a todos los decoradores y declara (o implementa, segn) la responsabilidad de mantener una referencia al objeto que se extiende. Es posible que sobrecargue todos los mtodos de la clase Componente con llamadas al componente concreto, de forma que aquellos mtodos cuya funcionalidad no se extiende simplemente llaman a los originales.

Decorator1 y Decorator2 Son clases concretas que heredan de Decorator e implementan las extensiones de funcionalidad de la clase original ComponenteConcreto.

COLABORACIONES

CONSECUENCIAS Ofrece ms flexibilidad que la herencia esttica. Se consiguen componentes pequeos. Se reduce el nmero de clases y el arbol de herencia de clases.

IMPLEMENTACIN Los decoradores deben conocer el interfaz del componente para poder utilizarlo, se puede realizar mediante interfaz o mediante herencia. Decorator y Strategy. La accin del decorador se puede realizar antes o despues de llamar a los mtodos de otro objeto, el patron Strategy nos permite especificar lo que se produce en medio de la llamada a un mtodo.

CODIGO DE EJEMPLO

USOS CONOCIDOS

P. RELACIONADOS Delegation El prototipo Decorator es en ltima instancia una forma de llevar a cabo el patrn Delegation. Filter Es un patron Decorator especializado enla manipulacin de stremas de datos. Strategy Mientras que el patrn Decorator permite especificar lo que ocurre antes y despues de llamar a un mtodo de otro objeto, para controlar lo que se produce entre ambos se puede utilizar el patrn Strategy. Template Method Es una alternativa a Decorator util para indicar lo que sucede en medio de una llamada a un mtodo (en lugar de antes y despus). Adaptor El patrn Decorator no ampla el interfaz de la clase original sino solo su funcionalidad. Para cambiar el interfaz utilizamos Adaptor. Composite Est relacionado aunque Decorator no est orientado a agrupar componentes.

Fachada - Facade
Anterior - Indice - Siguiente

Fachada
INTENCION Simplifica el acceso a un conjunto de clases o interfaces. CONOCIDO COMO Facade MOTIVO Reducir la dependencia entre clases, Facade ofrece un punto de acceso al resto de clases, si estas cambian o se sustituyen por otras solo hay que actualizar la clase Facade sin que el cambio afecte a las aplicaciones cliente. Facade no oculta las clases sino que ofrece una forma ms sencilla de acceder a ellas, en los casos en que se requiere se puede acceder directamente a ellas. APLICACIONES Para ofrecer un acceso sencillo a subsistemas complejos. Para descomponer un sistema en capas, utilizando Facade para ofrecer un interfaz de acceso entre las mismas

ESTRUCTURA

PARTICIPANTES

COLABORACIONES

CONSECUENCIAS

Oculta a los clientes parte de la complejidad de los subsistemas. Disminuye el acoplamiento entre subsistemas y cliente.

IMPLEMENTACIN

CODIGO DE EJEMPLO

USOS CONOCIDOS

P. RELACIONADOS

PATRONES DE COMPORTAMIENTO
Anterior - Indice - Siguiente

Los patrones de comportamiento hablan de como interaccionan entre si los objetos para conseguir ciertos resultados. Los principales patrones de comportamiento son:

Experto Comando Interprete Iterator Mediador Memento Observador Estado Estrategia Plantilla Visitante Vista/Controlador

Chain of Responsability - Expert - Experto

Anterior - Indice - Siguiente

Chain of Responsability
INTENCION Delega responsabilidades a una clase especializada. CONOCIDO COMO

Chain of Responsability, expert, experto MOTIVO Es una forma de distribuir la ejecucin repartiendo las responsabilidades. Es la forma bsica de repartir las responsabilidades al realizar un Diseo Orientado a Objetos, por lo tanto lo utilizamos de forma intuitiva en este tipo de diseos. APLICACIONES Se puede utilizar junto al patron Composite, de forma que los hijos tienen un enlace al padre que les permite acceder a informacin sin conocer la clase que las contiene as como propagar la ejecucin. ESTRUCTURA

PARTICIPANTES

COLABORACIONES

CONSECUENCIAS Ofrece las principales ventajas de la Programacin Orientada a Objetos.

Mejora la encapsulacin. Facilita el mantenimiento. Ofrece reusabilidad.

IMPLEMENTACIN Se implementa asignando a cada clase las operaciones relativas a la informacin que contienen. CODIGO DE EJEMPLO

USOS CONOCIDOS El Diseo Orientado a Objetos en general. P. RELACIONADOS Composite

Command
Anterior - Indice - Siguiente

Command
INTENCION Encapsula una peticin como un objeto, esto facilita la parametrizacin de los requerimientos (inicializacin de los parmetros por el constructor), el encolado de multiples peticiones (estructura de datos de objetos comando) y su reordenacin, y

permite implementar el hacer/deshacer (do/undo) mediante mtodos. Por otro lado se facilita la creacin de macros agrupando los comandos ms frecuentes. CONOCIDO COMO Command MOTIVO El concepto de "comando" puede ser ambiguo y complejo en los sistemas actuales y al mismo tiempo muy extendido: interpretes de comandos del sistema operativo, lenguajes de macros de paquetes ofimticos, gestores de bases de datos, protocolos de servidores de Internet, etc. Este patron presenta una forma sencilla y versatil de implementar un sistema basado en comandos facilitandose su uso y ampliacin. APLICACIONES Cuando se requiera: Facilitar la parametrizacin de las acciones a realizar. Independizar el momento de peticin del de ejecucin. Implementar CallBacks, especificando que comandos queremos que se ejecuten en ciertas situaciones de otros comandos. Es decir un parametro de un comando puede ser otro comando a ejecutar. Soportar el "deshacer". Desarrollar sistemas utilizando comandos de alto nivel que se construyen con operaciones ms sencillas (primitivas).

ESTRUCTURA

PARTICIPANTES AbstractCommand. Clase que ofrece un interfaz para la ejecucin de comandos. Define los mtodos do y undo que se implementarn en cada clase concreta. ConcreteCommand. Clase que implementa un comando concreto y sus mtodos do y undo. Su constructor debe inicializar los parmetros del comando. Invoker. Clase que instancia los comandos, puede a su vez ejecutarlos inmediatamente (llamando a do) o dejar que el CommandManager lo haga. CommandManager. Responsable de gestionar una coleccin de objetos comando creadas por el Invoker. llamar a los mtodos doIt y unDoIt. Gestionar su secuenciacin y reordenacin (en base a prioridades por ejemplo). COLABORACIONES

CONSECUENCIAS Se independiza la parte de la aplicacin que invoca los comandos de la implementacin de los mismos. Al tratarse los comandos como objetos, se puede realizar herencia de los mismos, composiciones de comandos (mediante el patrn Composite) Se facilita la ampliacin del conjunto de comandos.

IMPLEMENTACIN

Combiene estudiar el conjunto de comandos a implementar y si se observan comandos demasiado complejos dividirlos en subcomandos ms sencillos y utilizarlos de forma combinada. Si se implementan las operaciones Undo hay que almacenar el estado de los objetos que se modifiquen para su posterior restauracin al ejecutar Undo (pensar en el patrn Memento). Pueden aparecer comandos cuya accin sea imposible Deshacer (como el borrado de archivos) Si se dota al manejador de comando de un mecanismo para que sea consciente de que comandos se pueden deshacer y cuales no, entonces podemos centralizar el tratamiento de los mismos en el manejador, por ejemplo puede comportarse advirtiendo al usuario de que tal operacin no podr deshacerse dandole la opcin de cancelarlo. Si el manejador de comandos ejecuta un comando que no se puede deshacer y es consciende de ello puede borrar el historial de comandos ya que no se va a poder volver atrs. Esto supone un ahorro de memoria considerable ya que se descartan todos los estados guardados de los comandos previos. Se puede implementar un sistema de direccionamiento hacia los comandos mediante Factory Method. CODIGO DE EJEMPLO

USOS CONOCIDOS Las clases Button y MenuItem de Java facilitan la utilizacin de este patrn, declaran los mtodos getActionCommand y setActionCommand para dar nombres a las acciones realizadas por los objetos, facilitandose una correspondencia entre ambos. P. RELACIONADOS Factory Method Ofrece una forma alternativa de llamar a los comandos adems del uso del command manager. Interprete Se puede imnplementar un pequeo Interprete mediante clases Command. Snapshot Puede facilitar el almacenamiento del estado de los objetos para implementar la accin Deshacer en lugar de utilizar comandos inversos. Template Method Puede servir para implementar la lgica de Deshacer de forma un tanto automtica o a alto nivel. Composite Permite realizar agrupaciones de comandos de forma similar a una macro.

Prototype Hay quien lo utiliza para implementar la copia del comando al historico de comandos.

Interprete - Interpreter
Anterior - Indice - Siguiente

Interprete
INTENCION Simplifica el desarrollo utilizando una gramatica sencilla CONOCIDO COMO Interpreter MOTIVO

APLICACIONES

ESTRUCTURA

PARTICIPANTES

COLABORACIONES

CONSECUENCIAS

IMPLEMENTACIN

CODIGO DE EJEMPLO

USOS CONOCIDOS

P. RELACIONADOS

Iterador - Iterator
Anterior - Indice - Siguiente

Iterador

INTENCION Permite acceder secuencialmente a los elementos de estructura de datos u objetos preservando su estructura interna. CONOCIDO COMO Iterator MOTIVO

APLICACIONES Cuando se desea acceder al contenido de una coleccin sin depender demasiado de la estructura de clase de los elementos contenidos. Para disponer de una forma homognea de acceder al contenido de distintas colecciones. Cuando se quiere recorrer una coleccin de mltiples formas.

ESTRUCTURA

PARTICIPANTES IIterator: Interfaz que define los mtodos de acceso a los elementos. Iterator: Clase que implementa el acceso secuencial. ICollection: Interfaz de la clase Collection. La clase Collection ofrece sus propios objetos Iterator especializados.

COLABORACIONES

CONSECUENCIAS Podemos recorrer una estructura de objetos sin conocer los detalles internos de las clases que forman los elementos. Se puede recorrer simultaneamente (y en un mismo bloque) la misma coleccin utilizando varios Iteratos, cada uno se encarga de controlar en que posicin est.

Se simplifica el cdigo de la clase Collection, ya que la implementacin de la forma de recorrido se encuentra en las clases Iterator. IMPLEMENTACIN IIterator define los mnimos mtodos para situarse al principio/final de la coleccin, avanzar/retroceder y recuperar un elemento. La clase Iterator est intimamente ligada a la clase Collection ya que debe acceder a sus estructuras de datos, por ello se suelen implementar como clases amigas de la clase Collection. Hay que tener cuidado con la posibilidad de que la coleccin cambie mientras est siendo recorrida, se puede implementar un contador de cambios en la clase Collection y el Iterator puede observar cuando se ha producido un cambio para reiniciar (o invalidar o lo que se desee) el recorrido. CODIGO DE EJEMPLO

USOS CONOCIDOS Las clases Collection del paquete java.util utilizan el patron Iterator. P. RELACIONADOS El patrn Iterator se puede considerar una forma de Adapter especializado en recorrer una estructura. Se puede emplear un Factory Method para determinar que Iterator instanciar. Se puede utilizar un Null Iterator (que no devuelve ningun elemento) para implementar el patrn Null Object.

Mediador - Mediator
Anterior - Indice - Siguiente

Mediador
INTENCION Coordina interaciones entre objetos relacionados, centraliza en una clase la lgica de que realiza los cambios de estados de los objetos, en lugar de diseminarlo en las multiples clases que componen la aplicacin. CONOCIDO COMO Mediator MOTIVO Ofrece una forma sistematizada de aumentar la cohesin (se centraliza la lgica) y reducir el acoplamiento entre clases (se reducen la dependencias entre ellas). APLICACIONES

Cuando tienes varias clases relacionadas entre si y existen muchas dependencias entre ellas. Cuando las clases son dificiles de reutilizar porque existen muchas relaciones de interdependencia que les hacen inoperativos por si solos. ESTRUCTURA

PARTICIPANTES Clase1 y Clase2 Son las clases que presentan interdependencia entre ellas. Ahora en lugar de acceder directamente la una a la otra notificarn de sus cambios a la clase Mediator. EventListener1 a 3 Son los interfaces para recibir notificaciones de cambios de estadod e las clases Clase1 y Clase2, existirn tantos EventListeners como tipos de notificaciones distintas existan. Mediator Implemneta los Interfaces EventListener para recibir las notificaciones de cambio, implementa la logica e interactua con las clases.

COLABORACIONES

CONSECUENCIAS Toda la complejidad de tratamiento de las interdependencias entre clases se centraliza en la clase

Mediator. Con lo que las clases son ms fciles de manejar e implementar. Las clases son ms faciles de reutilizar ya que no dependen unas de otras, como se puede observar se pueden utilizar de forma independiente, ya que no es imprescindible que alguien est a la escucha de sus notificaciones. La clase mediator normalmente no es reutilizable, ya que implementa la lgica de la aplicacin. IMPLEMENTACIN Una consideracin a tener en cuanta a la hora de implementar la clase Mediator es si te interesa que el propio Mediator guarde informacin sobre el estado de cada una de las clases o acude a las mismas para recuperar dicha informacin. La primera de las alternativas es ms arriesgada pues se pueden producir diferencias entre el estado real de los objetos y la informacin que el Mediator guarda. CODIGO DE EJEMPLO

USOS CONOCIDOS

P. RELACIONADOS Observer Las clases Mediator frecuentemente utilizan el patrn Observer para recibir notificaciones de las diferentes clases. Adapter Puedes utilizar el patron Adapter para independizar la clase Mediator de las clases concretas que gestiona.

Memento
Anterior - Indice - Siguiente

Memento
INTENCION Guarda el estado de un objeto para restaurarlo posteriormente CONOCIDO COMO Memento MOTIVO

APLICACIONES

ESTRUCTURA

PARTICIPANTES

COLABORACIONES

CONSECUENCIAS

IMPLEMENTACIN

CODIGO DE EJEMPLO

USOS CONOCIDOS

P. RELACIONADOS

Observador - Observer
Anterior - Indice - Siguiente

Observador
INTENCION Notifica automticamente de los cambios de estado de un objeto a todos sus dependientes. Permite de forma deinmica implementar dependenias entre objetos, de forma que los objetos dependientes sean notificados de los cambios que se producen en los objetos de los que dependen. CONOCIDO COMO Observer MOTIVO

Encapsular la gestin de las dependencias dinmicas permite centralizar su gestin, realizar cambios futuros en una sola clase y reutilizar el mecanismo de interdependencia. APLICACIONES Cuando un sistema requiere que unos elementos sean conscientes de los cambios producidos en otros. Cuando la dependencia entre instancias se produce de forma dinmica, en tiempo de ejecucin y no siempre. Cuando la dependencia se produce de un objeto hacia muchos y un sistema simple de eventos no sirve porque solo permite notificar a una sola instancia. En ocasiones se implementan sistemas de eventos mediante este sistema, por ejemplo en el API de Java, de forma que los objetos que notifican de eventos implementan el interfaz observable y los que reciben las notificaciones de eventos implementan el interfaz observer. Esto permite que muchos objetos reciban eventos de otro objeto en lugar de los sistemas de eventos bsicos que solo permiten notificar a un nico objeto.

ESTRUCTURA

PARTICIPANTES IObserver Interfaz orientado a las clases dependientes, declara un mtodo Notify() que permite al objeto observado notificar de sus cambios alos que dependen de el. IObservable Interfaz que implementarn los clases de las que se depende, declara los mtodos addObserver que permite registrar una instancia dependiente y removeObserver para eliminar la dependencia. Esta caracterstica le da el aspecto dinmico al sistema de notificacin, ya que el enlace entre el objeto dependiente y del que se depende se realiza en tiempo de ejecucin mediante el empleo de estos mtodos. Observer y Observable Son las clases concretas que implementan los interfaces anteriores.

Multicaster No es imprescindible, ya que sus funciones las puede llevar a cabo la propia clase Observable, pero delegar el registro de observers y la notificacin en una sola clase permite reutilizar facilmente el mecanismo.

COLABORACIONES

CONSECUENCIAS Permite enviar notificaciones desde un objeto a muchos, de forma dinmica y sin que las clases implicadas sean conscientes de las clases del resto. Un objeto observable puede ser a su ver observer respecto de otros.

En ocasiones se pueden producir consecuencias no deseables: Cuando existen muchos observers registrados se puede ralentizar notablemente el envio de notificaciones, tambien cuando aun siendo pocos los observers registrados estos producen a su vez indirectamente nuevas notificaciones en cascada. Cuando se producen ciclos de notificaciones, de forma que la notificacin de un cambio en el objeto Observable produce de forma indirecta una cadena de notificaciones que vuelve a provocar un cambio en el objeto (reproduciendose el ciclo) o simplemente el objeto observable est de forma indirecta destro de un ciclo de observers. En ambos casos se produce un bucle infinito que termina cuando se agota la memoria (generalmente un Stack Overflow). Este problema no obstante no es inherente al patron Observer, tambien se puede producir en la notificacin de eventos normales en cuanto se produzca un ciclo de objetos que capturan eventos y los lanzan a su vez. Una forma trivial de evitar esto consiste en utilizar un flag que indica que se est procesando una notificacin, de forma qeu el objeto no aceptar nuevas notificaciones hasta que haya terminado con la anterior, de forma que se interrumpe el ciclo.

IMPLEMENTACIN Generalmente el objeto Observable al notificar al objeto Observer le pasa una referencia de si mismo como parmetro del mtodo notify (o de alguna otra forma) de manera que el objeto receptor de la notificacin puede acceder a los atributos del objeto que observa. Hay qeu tener en cuenta que un mismo objeto observer puede haberse registrado como observador de varios objetos observables, de forma que cuando le llega la noficacin necesita saber de quien le viene.

Independientemente de como implementes la solucin a esto siempre llegars a la conclusin de que las formas ms prcticas requieren que la clase Observer conozca concretamente la clase Observable o se utilicen interfaces especificos para cada tipo de notificacin segn la clase origen, lo cual se presenta frecuentemente como una desventaja o inconveniente, pero... de que otra forma se puede acceder a los atributos de una clase si no es conociendola o utilizando un interfaz especfico? Particularmente prefiero pasar una referencia del objeto Observable (o de una clase padre) como parmetro del mtodo notify. En ocasiones conviene reducir el nmero de notificaciones simplemente por que se van a producir ms cambios, en este caso se espera a que se produzcan todos los cambios y se retrasa la notificacin hasta que se han completado todos. Se puede implementar aadiendo dos mtodos a la clase Observable para indicar el comienzo de cambios y el final de los mismos, de forma que las notificaciones estn desacivadas entre tanto. Esta solucin se complica si son multiples objetos los que participan en ese conjunto de cambios, se puede utilizar un patrn Mediator en este caso. CODIGO DE EJEMPLO

USOS CONOCIDOS

Delegacin de eventos en Java. ImageObserver Observer TileObserver

P. RELACIONADOS Adapter Puede ser util para permitir que clases que no implementen el interfaz IObserver puedan recibir notificaciones. Delegation El patrn observer utiliza el patron delegation si se utiliza la clase Multicaster. Mediator Se puede utilizar para coordinar multiples cambios de estado de un mismo Observable provocados por diferentes objetos (con la finalidad de reducir el nmero de notificaciones)

Estado - State
Anterior - Indice - Siguiente

Estado

INTENCION Modelo para que un objeto cambie su comportamiento dependiendo de su estado, pudiendo incluso aparentar que cambia de clase. CONOCIDO COMO State MOTIVO Incorpora a los patrones el concepto de "Maquina Abstracta" o autmata, utilizado desde los orgenes de la Informtica y estudiado mucho antes. Ofrece un modelo basado en la programacin orientada a objetos frente a las formas clasicas de programacin de autmatas finitos. APLICACIONES En principio para aquellos sitemas que representemos como un autmata o mquina abstracta: Analizadores (Parsers) lxicos y sintacticos en desarrollos de lenguajes (compiladores, intrpretes, etc). Sistemas interactivos con el usuario, de forma que las posibles acciones del usuario van cambiando el estado de la interfaz y ofreciendo nuevas operaciones.

ESTRUCTURA

PARTICIPANTES AppContexto La aplicacin que utiliza una mquina de estados. AppState La parte de la aplicacin que gestiona los estados de la mquina. EstadoConcreto* Clases para cada uno de los estados en que puede estar, es una clase derivada de AppState y gestiona el comportamiento de la mquina para cada uno de los estados.

COLABORACIONES

CONSECUENCIAS

IMPLEMENTACIN Utilizar una clase abstracta que represente al objeto y su interfaz, implementar una subclase para cada uno de los estados y metodos para cada una de las transiciones posibles. Todas estas clases mantendrn una referencia al objeto que encapsule el estado o devolvern la instancia de la clase que representa el estado actual. Esto permite aadir nuevos estados simplemente incorporando nuevas subclases. CODIGO DE EJEMPLO

USOS CONOCIDOS StateEdit AccesibleState DirStateFactory StateEditable StateFactory P. RELACIONADOS Las mquinas abstractas (o autmatas) suelen responder a mensajes con una respuesta y un cambio de estado, por lo que el patrn controller estara bien para la gestin de los mensajes. Si se opta por la alternativa de que el estado actual se almacene en un objeto se puede acceder al mismo utilizando el patrn singleton.

Estrategia - Strategy
Anterior - Indice - Siguiente

Estrategia

INTENCION Abstraccin para seleccionar entre varios algoritmos CONOCIDO COMO Strategy MOTIVO Encapsula varios algoritmos alternativos en diferentes clases y se ofrece un interfaz nico (mediante una superclase) para acceder a la funcionalidad ofrecida, la eleccin del algoritmo se vuelve transparente para el cliente, pudiendo depender del objeto e incluso variar en el tiempo. APLICACIONES Cuando la aplicacin debe ofrecer varios algoritmos alternativos para un mismo comportamiento. Una operacin de "Guardar" un documento puede ser distinta segn sea el destino elegido un directorio local o un servidor ftp remoto. La funcionalidad de comprobacin de integridad de un archivo puede realizarse mediante CRC u otro algoritmo. Un sistema puede requerir cifrar un contenido mediante diferentes metodos de encriptacin. ESTRUCTURA

PARTICIPANTES El Cliente delega una operacin en la superclase, abstrayendose de los detalles de la misma. La superclase AlgoritmoAbstracto ofrece un interfaz comn y oculta la eleccin del algoritmo empleado. Las clases AlgoritmoConcreto implementa cada una de las diferentes alternativas del algoritmo. COLABORACIONES

CONSECUENCIAS La eleccin del algoritmo se realiza de forma dinmica en tiempo de ejecucin.

Se simplifica la clase cliente al independizarse de la decisin de qu algoritmo utilizar. Se reducen las estrcturas if y switch en el cliente. Segn el caso se puede incrementar la velocidad de ejecucinde los objetos cliente al no tener que realizar ellos mismos el algoritmo (en entornos concurrentes) IMPLEMENTACIN Si hay comportamientos comunes en varios algoritmos se puede colocar en una superclase de la que se deriven las diferentes alternativas. Informar al cliente de si se puede realizar la operacin, en ciertos casos es posible que no se pueda utilizar ninguna de las alternativas, esto se puede implementar inicializando a null el objeto Strategy de forma que el cliente compruebe primero si es null antes de llamar a ninguna operacin. CODIGO DE EJEMPLO

USOS CONOCIDOS El paquete java.util.zip en las clases CheckedInputStream y CheckedOutputStream utilizan la clase Checksum la cual sigue el patrn Strategy para elegir entre los algoritmos de comprobacin de errores en Streams de bytes ya sea CRC32 o Adler32. P. RELACIONADOS Si existen muchas instancias de Cliente es mejor utilizar el patron Flyweights en lugar de Strategy. El patrn Template Method utiliza diferentes algoritmos mediante subclases en lugar de mediante delegacin.

Template method
Anterior - Indice - Siguiente

Template method
INTENCION Encapsula un algoritmo en una clase abstracta de forma que puede ser reutilizada. CONOCIDO COMO Template method MOTIVO Muchos algoritmos pueden ser reutilizados aportando cierta informacin especfica propia de los elementos que tenga que tratar en cada momento. APLICACIONES Aquellos algoritmos que no dependen directamente del tipo de objetos con los que operan.

Un algoritmo de ordenacin en general no depende de si ordena nmeros o palabras, el proceso de ir colocando cada elemento en su lugar es generalizable para cualquier tipo de datos, en este caso solo es necesario aportar un metodo especifico para la clase a ordenar que compare dos elementos de su clase y nos diga cual es menor. ESTRUCTURA

PARTICIPANTES Clase Abstracta Contiene la codificacin del algoritmos y declara mtodos virtuales que realizarn las operaciones dependientes de cada tipo de datos. Clase Concreta Deriva de la clase abstracta, con lo que ya hereda el algoritmo genrico. Debe implementar los mtodos virtuales para permitirle operar con un tipo concreto de datos.

COLABORACIONES

CONSECUENCIAS El algoritmo es reutilizable para cualquier tipo de datos con el que tenga sentido. Al centralizar la lgica en una sola clase se simplifica el mantenimiento y cualquier mejora sobre el algoritmo beneficia directamente a todas las clases que derivan de el. IMPLEMENTACIN Se encapsula el algorito en una clase abstracta, cualquier operacin sobre los datos se realiza llamando a un mtodo que se declara como virtual para que sean especificadas por las clases derivadas. CODIGO DE EJEMPLO
public abstract class insertSorter { // Template method public void sort(Object[] datos){ for ( int i=0; i< } obj2); obj1,Object esMenor(Object boolean abstract public datos[min]="tmp;"

datos[i]="datos[min];" tmp="datos[i];" Object min="j;" (esMenor(datos[min],datos[j])) if j++){ j="1;j

USOS CONOCIDOS Es muy frecuente su utilizacin en algoritmos genricos de ordenacin y bsqueda. En la plataforma .NET se utiliza un patrn template para implementar una forma gnerica de gestin de eventos, puede verse en la direccin: .NET Event Handling using the Template Method Design
Pattern

P. RELACIONADOS El patrn Strategy nos ofrece una alternativa a la reutilizacin de algoritmos.

Visitor
Anterior - Indice - Siguiente

Visitor
INTENCION Operaciones sobre elementos de una estructura de objetos heterognea. CONOCIDO COMO Visitor MOTIVO

APLICACIONES

ESTRUCTURA

PARTICIPANTES

COLABORACIONES

CONSECUENCIAS

IMPLEMENTACIN

CODIGO DE EJEMPLO

USOS CONOCIDOS

P. RELACIONADOS

Viewer/Controller - Vista/Controlador
Anterior - Indice - Siguiente

Vista Controlador
INTENCION El controlador tiene la responsabilidad de gestionar un sistema de mensajes. CONOCIDO COMO Modelo Vista Controlador, Viewer Controller Model, MVC MOTIVO En sistemas complejos de eventos y mensajes en ocasiones es dificil determinar quien debe responder a un mensaje. Este patrn encapsula en una sola clase la atencin a todos los eventos y mensajes, y se encarga de operar con los objetos que contienen los datos. El modelo vista-controlador se basa en delegar en una clase controlador la atencin de los eventos y la modificacin de los datos y a su vez se delega en una clase vista la representacin de dicha informacin, es decir la actualizacin de los cambios en el sistema de representacin (sistema de ventanas habitualmente) APLICACIONES Se utiliza sobre todo en entornos grficos de usuario interactivos, ya que el nmero y posibilidades de mensajes, as como el elevado nmero de objetos visuales dificultan la gentin de la informacin y las operaciones sobre ellos. El modelo Vista-controlador es util tambien cuando es necesario proporcionar mutiples representaciones de los mismos datos, en teste contexto el controlador gestiona la informacin, y multiples clases Vista ofrecen las diferente representaciones de la misma informacin, por ejemplo diferentes diagramas (de barras, de tarta, etc) de una aplicacin estadstica u hoa de clculo. ESTRUCTURA

PARTICIPANTES

Controller Recibe los eventos o mensajes, opera sobre los objetos de datos. Vista Representa la informacin en pantalla o sistema de representacin concreto, actualiza la visualizacin de los cambios realizados en la informacin.

COLABORACIONES

CONSECUENCIAS Al pasar por el controlador todos los mensajes se garantiza que las operaciones se realizan en el orden correcto, ya que si se atienden por diferentes objetos se complica la comunicacin entre ellos para informar de cuando se puede realizar ciertas operaciones y cuando no, en el caso de que estas reglase sean complejas puede ser interesante combinarlo con un patrn State. IMPLEMENTACIN

CODIGO DE EJEMPLO

USOS CONOCIDOS

P. RELACIONADOS

State. Vista - View.

APARTADO A. Antipatrones
Anterior - Indice - Siguiente

Si los patrones nos ofrecen una forma de resolver un problema tpico, los antipatrones nos hablan de actitudes o formas de entrentarse a los problemas con consecuencias negativas conocidas, de experiencias que han arruinado otros proyectos. La fuerza de los antipatrones se basa en que puede ser ms facil de detectar a priori las malas lineas en el desarrollo de software que elegir el camino correcto, o dicho de otra forma, descartar las alternativas incorrectas nos puede ayudar en la eleccin de la alternativa mejor. Se clasifican en antipatrones de desarrollo, de arquitectura del software y de gestin de proyectos.

Desarrollo de Software
Anterior - Indice - Siguiente

The Blob (Clases Gigantes) Lava Flow (Cdigo Muerto) Cuando se continua incluyendo cdigo en la aplicacin que ya no se utiliza, como continuar incluyendo cdigo para Win16 cuando la aplicacin ya solo funciona para 32 bits. Se mantiene cdigo que se supone importante aunque se desconoce si se seguir utilizando. Un exceso de rotacin de personal unida a una pobre documentacin puede provocar esta situacin. El cdigo se llena de comentarios del tipo "//Importante, no quitar" y nadie recuerda porque era necesario. La solucin pasa por mantener actualizada la documentacin y por depurar el cdigo obsoleto, Java facilita este mantenimiento al disponerse de la clausula "deprecated" para mantener el cdigo obsoleto solo por un tiempo. Functional Decomposition (Diseo No Orientado a Objetos) Poltergeists (No se sabe lo que hacen algunas clases) Golden Hammer (Para un martillo todo son clavos) Spaghetti Code (Muchos if o switch) Cut-and-paste programming (cortar y pegar cdigo)

Arquitectura del Software

Anterior - Indice - Siguiente

Stovepipe enterprise (Aislamiento en la empresa, Islas de Automatizacin o Empresa con sistemas parcheados). Se produce cuando en la empresa se desarrollan sistemas de manera independiente, esto dificulta la interconexin de sistemas y la reutilizacin e incrementa los costes de desarrollo. Es cuando se crean Islas de automatizacin, y provoca que existan tecnologas incompatibles, arquitecturas monolticas y falta de documentacin (no es necesario hacer un mapa de la isla, sus habitantes la conocen bien). Se dificulta la ampliacin de los sistemas, suelen faltar estndares (si se utilizasen estndares tendramos sistemas homogneos y no diferentes). La causa suele estar en una falta de estrategia tecnolgica en la empresa, falta de cooperacin y comunicacin entre departamentos y niveles, deficiencias en el conocimiento

de la tecnologa, en definitiva ausencia de un Plan Informtico. Stovepipe system (Legacy System, Sistema Heredado, Aislamiento entre sistemas o Sistema Parcheado) De manera semejante al Aislamiento en la Empresa pero aplicado a uno de sus sistemas, se produce por un desarrollo mal planificado en el que sus subsistemas parecen haber sido desarrollados por equipos distintos sin comunicacin y descoordinados, los diferentes subsistemas se conenctan unos a otros directamente, por lo aparecen fuertes dependencias (alto acoplamiento entre clases). Al ampliarse el sistema aumenta la interdependencia y la complejidad con lo que el mantenimiento llega a ser insostenible y se plantea la sustitucin completa. Suele producirse un distanciamiento entre la documentacin y el desarrollo. Los diseadores ignoran los detalles de integracin. Se suele producir al superarse el presupesto para el desarrollo y se postponen las fechas de entrega, para "llegar a tiempo" se desarrolla con prisas y sin actualizar la documentacin. Los cambios requieren fuertes esfuerzos y se recurre a parches provisionales. La causa puede ser la utilizacin de multiples formas de integracin de los subsistemas (por ejemplo modulos enlazados estticamente en unos casos y de forma dinmica en otros) con lo que el sistema es dificil de documentar y mantener, Falta de Abstraccin ofreciendose interfaces nicos y rgidos, Ausencia de Metadatos ofreciendose pocas alternativas a la ampliacin y configuracin del sistema. una solucin es la Arquitectura basada en Componentes ya que permite una facil sustitucin de los mdulos del sistema, usar ISO IDL (CORBA) o semejantes. Vendor Lock-In (Arquitectura dependiente del producto, Ammarrado por el vendedor, Esclavitud y Sumisin) Cuando los proyectos de desarrollo de software se basan en soluciones tecnolgicas propietarias de un vendedor concreto, al tomar la tecnologa de un producto se depende del vendedor. Nuevas versiones del producto comercial pueden ser incompatibles, alejadas de los estndares y las arquitecturas abiertas, todo ello dificulta el mantenimiento del sistema. La solucin a este problema pasa por no adquirir paquetes en base a la publicidad del vendedor sin un examen tcnico detallado y pruebas de validacin. Se puede minimizar su impacto utilizando el Patrn Adaptador (Wrapper), de forma que encapsulamos el acceso a la clase y futuros cambios del producto solo afectaran al adaptador y no a toda la aplicacin. Architecture by implication (Arquitectura Implcita). Sucede cuando no se especifica la arquitectura del sistema o ignora alguno de sus apartados: Arquitectura del software

(especificacin del lenguaje, bibliotecas, nomenclaturas), Arquitectura hardware (configuracin de clientes y servidores), Arquitectura de comunicacin (protocolos y dispositivos de red), Arquitectura de Datos (archivos y Bases de Datos), Arquitectura de seguridad, Administracin de Sistemas, etc. Se suele dar cuando se considera que la documentacin no es necesaria y la arquitectura a utilizar se da por suspuesta, puede ser un exceso de confianza de desarrolladores con experienzas exitosas en otros proyectos, ausencia de soporte tcnico, etc. Design by committee (Diseo por Comit, Navaja suiza, Chapa de Oro, Enfermedad de Estandarizacin) Se da cuando el proyecto se disea a travs de las reuniones de un comit demasiado numeroso o inexperto. Las reuniones se hacen largas e improductivas, se pretende incorporar las ideas de todos al proyecto. Falta un responsable nico del proyecto, se incorporan "Chapas de Oro", elementos que aumentan la dependencia de nosotros por el cliente , la documentacin se hace voluminosa e ilegible, aumenta la complejidad de las abstracciones pretendiendo que sirva para todo, las decisiones solo se pueden realizar por el comit con lo que se retrasa el avance del proyecto. La solucin implica que: Los equipos que elaboran las abstracciones deben ser reducidos y de expertos, asignar responsabilidades a cada miembro del equipo o comit, las reuniones deben ser concisas y con unos objetivos concretos, asignar prioridades a los requerimientos y ceir las abstracciones a los mismos. Reinvent the wheel Se supone que se debe desarrollar desde cero, falta informacin y tecnologa reusable entre proyectos. Falta de visin empresarial. Arquitectura cerrada y especfica para un proyecto. La solucin es la bsqueda de tecnologa reutilizable (la reusabilidad empieza por reutilizar lo existente antes que por disear sistemas reutilizables), identificar interfaces estndar.

Gestin de Proyectos Software

Anterior - Indice - Siguiente

Analysis paralysis Se da cuando un equipo de inteligentes analistas comienzan una fase de anlisis que solo acaba cuando se cancela el proyecto. El propio nombre del proyecto puede anticiparnos esta situacin (si incluye "Super", "Mega", "2000", "Galaxia", "Global" etc. cuidado!) este sndrome del gran proyecto se refleja en la pretensin de que el sistema lo haga todo, se realize con

las ltimas herramientas, se utilizen los ltimos paradigmas, etc, todo esto requiere nuevos equipos de desarrollo, con lo que el proyecto se reinicia a cada nueva crisis de grandiosidad. Tambien influye el emplear analistas con reducidos conocimientos, de forma que las simultaneas curvas de aprendizaje cuestionan lo ya analizado y obligan a una revisin contnua. Pueden existir conflictos entre objetivos en ocasiones por causas polticas. La solucin consiste en realizar desarrollos pequeos (tengase en cuenta la velocidad de evolucin de la tecnologa, un proyecto a ms de 6 meses se topar con cambios tecnolgicos). Utilizar desarrolladores antes que analistas, los desarrolladores pueden aprender a analizar un requerimiento, mientras que la mayora de los analistas no son capaces de desarrollar una solucin. Comenzar el proyecto con un prototipo de arquitectura y un conjunto reducido de requerimientos para desarrollar en no ms de un mes. Death by planning Corncob (Personas problematicas) Irrational management Project mismanegement

APARTADO B. Herramientas
Anterior - Indice - Siguiente

En la actualidad no se dispone de ninguna herramienta para la utilizacin directa de los Patrones de Diseo en el proceso de desarrollo de una manera completa. Algunos intentos se han basado en el diseo de clases que representan al patrn para poderse utilizar directamente, en otros casos se han utilizado plantillas (templates). En la red se pueden encontrar algunos proyectos universitarios en forma de tesis o similares que no ofrecen nada interesante. El problema reside en el propio concepto de Patrn, ya que un mismo patrn puede tener muchas implementaciones diferentes (tomar una codificacin concreta puede ser util en unos casos y molesta en otros) ya que el patrn es solo la "idea" y no una codificacin concreta. De hecho al codificar un patrn ste deja de serlo, ya no es una solucin a un problema reiterativo, sino un ejemplo de una solucin a un problema concreto. Por otro lado el no disponer de una herramienta capaz de gestionar los patrones dificulta el seguimiento de los mismos a partir del cdigo (en la depuracin o al hacer ingeniera inversa)

La solucin ms frecuente pasa por incluir en los nombres de las clases el nombre del patrn (o del colaborador concreto), de esta forma podemos suponer que la clase SingletonVentana se trata de una clase para el acceso a algntipo de ventanas y que se forma en base al patrn Singleton, con tolo lo que implica: instancia nica para el acceso a ese recurso, provablemente tendr algn mtodo de tipo getInstance o getVentana, as en base a la intuicin y a los nombres utilizados podemos preveer los patrones. No obstante no es un mtodo lo suficientemente convincente. Personalmente veo los patrones como un wizard o asistente ms que como clases o plantillas.

ModelMaker
Anterior - Indice - Siguiente

Herramienta para el desarrollo de paquetes de componentes para Borland Delphi.

Al estilo de una herramienta case orientada a UML ofrece ingeniera inversa y Patrones de Diseo, de los cuales soporta: Wrapper, Singleton, Mediator, Decorator, Visitor, Observer, Lock y Reference Count Disponible en http://www.modelmakertools.com

ACE
Anterior - Indice - Siguiente The ADAPTIVE Communication Environment (ACE)

Code Farms
Anterior - Indice - Siguiente Code Farms

FAMOOS
Anterior - Indice - Siguiente FAMOOS

SCG Research Projects

Anterior - Indice - Siguiente SCG Research Projects

Autores
Anterior - Indice - Siguiente Christopher Alexander Christopher Alexander: An Introduction for Object-Oriented Designers Christopher Alexander: The Search for Beauty Christopher Alexander: An Introduction for Object-Oriented Designers Brad Appleton's Home Page Kent Beck Frank Buschmann Alistair Cockburn, Humans and Technology Jim Coplien WardCunningham Amnon H. Eden, Home page Martin Fowler Ralph E. Johnson homepage Doug Lea's Workstation Bobby Woolf

Conferencias
Anterior - Indice - Siguiente EuroPLoP 2002 EuroPLoP 2000 EuroPLoP '99 Conference Page

EuroPLoP '98 Conference Page EuroPLoP96 Writers Workshops PLoP 2002 PLoP 2001 PLoP 2000 PLoP 1999 PLoP '98 Proceedings PLoP 97 -- Washington University TR 97-34 PLoP 96 Writer's Workshops PLoP 94 Papers The Pattern Languages of Programs Conference ChiliPLoP 2002 - AGCS ChiliPLoP 2001 - AGCS ChiliPLoP 2000 - AGCS ChiliPLoP'99 Hot Topic CFPs ChiliPLoP '99 - AGCS Patterns: ChiliPLoP '98 Koala PLoP 2002 KoalaPLoP 2000 Asian Pacific

(old webpage

for PLoP)

Conference, first held in

2000
Mensore PLoP 2001: First East Asian Conference on Pattern Languages of Programs SugarloafPLoP 2002 SugarloafPLoP 2001 ECOOP Home Page European Conference for Object-

Oriented Programming ECOOP 2002 Malaga, Spain, June 10-14, 2002

ECOOP 2000 Home Page ECOOP'99 - Lisbon ECOOP Home Page OOPSLA 2002 OOPSLA 2001, Conference On Object-Oriented Programming, Systems, Languages and Applications OOPSLA 2000, Conference On Object-Oriented Programming, Systems, Languages and Applications OOPSLA 99 Home Page OOPSLA'98 Home OOPSLA 98 Mid-Year Workshop OOPSLA'96 Electronic Information Hotline

APARTADO E. Links
Anterior - Indice - Siguiente

Links de Patrones de Diseo

Anterior - Indice - Siguiente

Gang of Four Design Patterns Wiki - History Of Patterns Patterns and Software: Essential Concepts and Terminology Net Objectives: Design Patterns Patterns in a Nutshell Design Patterns Tutorial The Elementary Patterns Home Page Design Patterns for Data Structures Patterns Home Page A Classification Of Object-Oriented Design Patterns Huston Design Patterns Patterns-Discussion FAQ Software Design Patterns: Common Questions and Answers Portland Pattern Repository www.patterndepot.com Wiki's Home at UIUC Lecture Notes Programming Patterns Overview Programming Patterns Overview /GOF/source/ada/ Implementations of all GoF Patterns in C# Wiki - Website Patterns A Pattern Language for Human-Computer Interface Design www.teleprogramadores.com - Gua de Patrones de Diseo Branching Patterns for Parallel Software Process Patterns The Process Patterns Resource Page An Introduction To Process Patterns

Links de Patrones de Arquitectura

Anterior - Indice - Siguiente Managing Change with Patterns Four Layer Architecture Form-Based User Interface - The Architectural Patterns Crossing Chasms: The Architectural Patterns Software: Abstract: Architectural Styles, Design Patterns, and Objects

Links de Patrones por Tipo

Anterior - Indice - Siguiente ITERATOR/OBSERVER - The trick to "Iterator Observers" ADAPTER - Adapter Known Uses ADAPTER - Programming Patterns Overview: Adapter

 ADAPTER - CS 635 - Doc 21 Adapter ADAPTER - Pattern: Adapter BRIDGE - Subject-oriented programming and the bridge pattern BUILDER - Builder pattern COMMAND - How to Implement the Command Pattern in Java COMMAND - Command Processor MEDIATOR - Mediator MEDIATOR - Experience in Applying Design Patterns to Decouple Object Interactions on the Intelligent Peripheral Prototype OBSERVER - How to decouple the Observer/Observable object model OBSERVER - Observer Design Pattern OBSERVER - Observer OBSERVER - Observer pattern OBSERVER - (ootips) Observer Pattern OBSERVER - PatternStories: ObserverPattern OBSERVER - Pattern: Observer SINGLETON - When is a singleton not a singleton? STATE - How to implement state-dependent behavior STATE - Discussion about Event-pattern, related to State? STATE - Models for Object-Oriented Design of State VISITOR - Reflect on the Visitor design pattern The Visitor Design Pattern VARIOS - PLoPD: 27. Self-encapsulation VARIOS - Lazy Optimization VARIOS - The Type Object Pattern VARIOS - Patterns for Building an Unusually Adaptable Java Framework VARIOS - PLoPD3: The Null Object Pattern VARIOS - A Generalized Null Object Pattern VARIOS - Null Object Pattern Revisited VARIOS - Strategy and Null Object

Links de Antipatrones
Anterior - Indice - Siguiente Big Ball of Mud design pitfalls as negative patterns Wiki - AntiPatterns Wiki - Design by Committee Anti-patterns www.antipatterns.com Notes on Failure

Links de Grupos de Estudio

Anterior - Indice - Siguiente

A Learning Guide To Design Patterns Patterns Groups Sillicon Valley Patterns Group The Israeli Patterns Reading Group The Analysis Patterns Group (news) comp.software.patterns patterns@acm.org The Coad Letter /languages/smalltalk/patterns/mail-archive

Links de Arquitecturas de Objetos

Anterior - Indice - Siguiente ActiveX/COM SOM CORBA ILU Object Oriented FAQ

2002 - Teleprogramadores.com - David Hernndez Tejada ltima modificacin: 08/09/2002 | Peso HTML: 152.12 Kb. | Peso imgenes (32): 75.45 Kb. | Peso Total: 227.57 Optimizada para el Explorer 5.x o Netscape 6.x