GUIA DE PATRONES DE DISEÑO

Indice Introducción1.- INTRODUCCION.

1.1.- Origen.1.2.- ¿Qué son los Patrones de Diseño?.1.3.- ¿Qué ventajas ofrece?.1.4.- Características.1.5.- Clasificación.1.6.- Patrones y Armazones (Frameworks) .1.7.- Formas de Descripción.1.8.- Otros Patrones .

Creación2.- PATRONES DE CREACION.

2.1.- Factoría Abstracta.2.2.- Builder - Creador.2.3.- Método Factoría - Factory Method - Virtual Constructor.2.4.- Prototipo - Prototype .2.5.- Singleton .

Estructurales3.- 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 .

Comportamiento4.- 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.

Antipatrones5.- APARTADO A. Antipatrones .

5.1.- Desarrollo de Software.5.2.- Arquitectura del Software.5.3.- Gestión de Proyectos Software.

Herramientas6.- APARTADO B. Herramientas.

6.1.- ModelMaker .6.2.- ACE .6.3.- Code Farms .6.4.- FAMOOS .6.5.- SCG Research Projects.

Autores7.- Autores.Conferencias8.- Conferencias.Links9.- APARTADO E. Links.

9.1.- Links de Patrones de Diseño.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.

INTRODUCCIONAnterior - Indice - Siguiente

Los Patrones de Diseño nos hablan de como construir software, de como utilizar las clases y los objetos de forma conocida.

Es necesario tener conocimientos previos de Programación 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 diseño vienen del campo de la Arquitectura, Christopher Alexander a finales de los 70 escribe varios libros acerca de urbanismo y construcción de edificios, y se plantea reutilizar diseños 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 guía 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 catálogo de patrones de diseño, que publican en el libro "Design Patterns: Elements of Reusable Object-Oriented Software" (Gang of Four)

¿Qué son los Patrones de Diseño?

Anterior - Indice - Siguiente

Christopher da la siguiente definición de patrón:

"Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, para describir después el núcleo de la solución a ese problema, de tal manera que esa solución pueda ser usada más de un millón 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 informática, de las nuevas posibilidades que ofrecen las redes e Internet, etc.

Los patrones de diseño 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 recopilación del conocimiento de los expertos en desarrollo de software.

No debe verse los Patrones de Diseño como una teoría 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.

Características

Anterior - Indice - Siguiente

Son soluciones concretas. Proponen soluciones a problemas concretos, no son teorías genéricas.

Son soluciones técnicas. Indican resoluciones técnicas basadas en Programación Orientada a Objetos (POO). En ocasiones tienen más utilidad con algunos lenguajes de programación 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 reutilización de código. Ayudan a contruir software basado en la reutilización, a construir clases reutilizables. Los propios patrones se reutilizan cada vez que se vuelven a aplicar.

El uso de un patrón no se refleja en el código. Al aplicar un patrón, el código resultante no tiene por que delatar el patrón o patrones que lo inspiró. No obstante últimamente hay multiples esfuerzos enfocados a la construcción de herramientas de desarrollo basados en los patrones y frecuentemente se incluye en los nombres de las clases el nombre del patrón en que se basan facilitando así la comunicación entre desarrolladores.

Es dificil reutilizar la implementación de un patrón. Al aplicar un patron aparecen clases concretas que soluciónan un problema concreto y que no será aplicable a otros problemas que requieran el mismo patrón: Una ventana es una solución para ventilar e iluminar un habitáculo, pero la ventana de mi casa no es util en el camarote de un barco.

Clasificación

Anterior - Indice - Siguiente

Clasificación según su propósito:

Patrones de Creación: Tratan la creación de instancias. Patrones Estructurales: Tratan la relación entre clases, la

combinación clases y la formación de estructuras de mayor complejidad.

Patrones de Comportamiento: Tratan la interacción y cooperación entre clases.

Clasificación según su ámbito:

De clase: Basados en la herencia de clases. De objeto: Basados en la utilización dinámica de objetos.

Patrones y Armazones (Frameworks)

Anterior - Indice - Siguiente

Los armazones están bastante relacionados con los Patrones. Un armazón es un modelo arquitectonico que describe una estructura de software facilmente ampliable y reutilizable.

Formas de Descripción

Anterior - Indice - Siguiente

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

Patron INTENCIONObjetivos del patron CONOCIDO COMOOtros nombres MOTIVOMotivaciones que justifican que se considere como un patron APLICACIONESPosibles usos ESTRUCTURAEsquema gráfico que describe el patrón. PARTICIPANTESDescripción de los elementos que intervien COLABORACIONESDescripción de las relaciones entre los PARTICIPANTES CONSECUENCIASBeneficios, riesgos, perjuicios que puede ocasionar su uso IMPLEMENTACIÓN

Información de detalle sobre la implementación, decisiones de diseño, formas de codificación CODIGO DE EJEMPLOCodigo de un ejemplo de utilización USOS CONOCIDOSProductos y sistemas conocidos que recuerde rápidamente el lector y facilite su comprensión P. RELACIONADOSPatrones que pueden funcionar como alternativa o de forma complementaria

Otros Patrones

Anterior - Indice - Siguiente

Además de los Patrones de Diseño tenemos:

Patrones de Arquitectura. Formas de descomponer, conectar y relacionar sistemas, trata conceptos como: niveles, tuberías y filtros. Es un nivel de abstracción mayor que el de los Patrones de Diseño.

Patrones de Programación (Idioms Patterns). Patrones de bajo nivel acerca de un lenguaje de programación 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 Programación concurrente, de Interfaz Gráfica, de Organización de Código, de Optimización de Código, de Robustez de Código, de Fase de Prueba.

PATRONES DE CREACIONAnterior - Indice - Siguiente

Los patrones de creación abstraen la forma en que se crean los objetos, de forma que permite tratar las clases a crear de forma genérica apartando la decisión de qué clases crear o como crearlas.

Pero los Patrones de Diseño son conceptos aplicables directamente en la producción de software, cualquier abstracción no se queda en el aire como una entelequia que solo sirve para dar discursos, así:

Según a donde quede desplazada dicha decisión se habla de Patrones de Clase (utiliza la herencia para determinar la creación de las instancias, es decir en los constructores de las clases) o

Patrones de Objeto (es en métodos de los objetos creados donde se modifica la clase)

Patrones de Creación de Clase:

Factoría Abstracta Builder

Patrones de Creación de Objeto:

Método Factoría Prototipo Singleton Object Pool

Factoría Abstracta

Anterior - Indice - Siguiente

Factoría Abstracta INTENCIONProporciona un Interfaz para crear familias de objetos sin especificar su clase de forma concreta CONOCIDO COMOAbstract Factory, Kit. MOTIVOProporciona un interfaz común para crear diferentes familias de clases. APLICACIONESEn muchas ocasiones existen diferentes recursos para realizar lo mismo, e incluso se presume que existirán nuevos recursos y queremos desarrollar sistemas compatibles con todos ellos, piensese en el caso de los escritorios KDE/GNOME, las librerías MOTIF/Windos/OpenView, las librerías OpenGL/DirecX. Si deseamos que nuestro software funcione sobre distintos recursos debemos abstraernos de que librerías utilizamos. ESTRUCTURA

PARTICIPANTES FACTORIA ABSTRACTA: Abstrae que clases se instancian.

Encapsula la funcionalidad que se desea, es la via de comunicación hacia las clases concretas instanciadas.

FACTORÍAS CONCRETAS: Clases encargadas de la instanciación de clases de una familia u otra.

COLABORACIONESToda relación entre el exterior del sistema y las clases de la factoria se realiza únicamente a través de los metodos de la clase abstracta, se puede utilizar metodos virtuales en la clase abstracta para acceder a los métodos de las clases a instanciar. CONSECUENCIAS

Ocultación de las clases de implementación. Esto tambien permite ofrecer clases sin mostrar su implementación, pudiendonos reservar la posibilidad de cambiar la implementación en el futuro.

Facilidad de sustitución de conjuntos de clases por otras equivalentes.

Consistencia entre productos, al desarrollarse las aplicaciones con un mismo conjunto homogéneo de clases, dichas aplicaciones son más consistentes entre ellas.

IMPLEMENTACIÓNInformación de detalle sobre la implementación, decisiones de diseño, formas de codificación CODIGO DE EJEMPLO

USOS CONOCIDOS

P. RELACIONADOS

Builder - Creador

Anterior - Indice - Siguiente

Builder INTENCIONPermite a un cliente crear un objeto especificando tipo y contenido, ocultandose el resto de detalles. CONOCIDO COMOBuilder, Creador MOTIVOLa creación de objetos o instanciación de clases es uno de los temas más frecuentes en la Programación Orientada a Objetos. Este patrón permite tener una política general para la creación de objetos, centralizandolo en una clase Builder. APLICACIONESUna clase superior Builder se aplica en la creación 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 representación interna de estructuras

compleja, respetando la interfaz comun de la clase Builder. Se independiza el código de construcción de la

representación. Las clases concretas que tratan las representaciones internas no forman parte de la interfaz del Builder.

Cada ConcreteBuilder tiene el código 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 creación del objeto. El Director controla la creación paso a paso, solo cuando el Builder ha terminado de construir el objeto lo recupera el Director.

IMPLEMENTACIÓN El Builder posee un interfaz con cada operación que se

puede realizar, el ConcreteBuilder implementa esas operaciones.

CODIGO DE EJEMPLO

USOS CONOCIDOS Tratamiento de diferentes formatos de archivos. Creación de objetos complejos independientes de los

elementos que lo componen.

P. RELACIONADOS Composite. La clase Builder suele devolver un Composite. Director. Método Factoría. Se puede utilizar el Método Factoría para

decidir que clase concreta instanciar. Factoría Abstracta y Visitor: A diferencia de la Factoría

Abstracta y Visitor, el Builder permite controlar paso a paso la creación del objeto.

Método Factoría - Factory Method - Virtual Constructor

Anterior - Indice - Siguiente

Método Factoría INTENCIONAbstraer la instanciación de clases relegando esta responsabilidad a las mismas clases. CONOCIDO COMOFactory Method, Virtual Constructor. MOTIVOEs un modelo que utiliza abstracción de clases para crear y relacionar objetos sin conocer de qué clase son. APLICACIONESSe utiliza cuando la aplicación no sabe de antemano el tipo de objeto que se va a crear, es en tiempo de ejecución cuando toma la decisión. ESTRUCTURA

PARTICIPANTES

COLABORACIONES

CONSECUENCIAS

IMPLEMENTACIÓN

CODIGO DE EJEMPLO

USOS CONOCIDOS

P. RELACIONADOS

Prototipo - Prototype

Anterior - Indice - Siguiente

Prototipo INTENCIONPermite crear objetos copiando un modelo existente. CONOCIDO COMOPrototype MOTIVOReducir el número de clases. APLICACIONESSe utiliza cuando se quiere abstraer el proceso de creación de objetos y cuando las clases a instanciar se conocen en tiempo de ejecución. Para reducir el número de clases a desarrollar (que implicaría una grán cantidad de factorías). Cuando los objetos de una clase tengan pocas combinaciones de estados distintos. ESTRUCTURA

PARTICIPANTES Cliente La clase que crea nuevos objetos mediante el

método clone de los prototipos. Prototype Clase (generalmente abstracta) que declara el

método clone(). PrototypeConcreto1 y PrototypeConcreto2 Clases que

heredan de Prototype e implementan el método clone() para realizar copias de si mismo.

COLABORACIONES

CONSECUENCIAS Reduce el número de clases. Permite crear objetos en tiempo de ejecución 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 método clone se garantiza que

cada objeto crea una instancia coherente.

IMPLEMENTACIÓNSe puede tener una Factoría Abstracta u otro sistema para gestionar los prototipos.

La implementación del método 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 clonación 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 CONOCIDOSLos JavaBean de Java se basan en el patrón 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 información referente a la clase que componen y referente al contexto del mismo.

Facade La clase cliente se comporta frecuentemente como un patrón Facade que independiza al resto de la aplicación de las clases prototipo.

Factory Method El patron prototype es util como alternativa a Factory Method cuando éste provoca un número muy elevado de clases.

Singleton

Anterior - Indice - Siguiente

Singleton INTENCIONOfrecer una instancia de una clase y un punto de acceso a la misma. CONOCIDO COMOSingleton MOTIVOModelo 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 método getInstance. APLICACIONESPara 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. Aplicación La aplicación 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 método de recuperación de la instancia Singleton: getInstance.

Evidentemente el metodo getInstance debe ser estático (para acceder sin una instancia concreta) o método de clase, en lenguajes que no dispongan de esta facilidad se puede usar una función global.

IMPLEMENTACIÓNLa implementación consiste en utilizar un metodo estático de clase para recuperar la única instancia de la clase o crear una instancia si no existía ninguna. CODIGO DE EJEMPLOclass Singleton{

private static Singleton instanciaUnica=null;public static Singleton instance(){

if (instaciaUnica==null){instanciaUnica=new Singleton();

}return instanciaUnica;

}}

USOS CONOCIDOSLa clase java.lang.Runtime del API de Java es una clase Singleton, no tiene constructores públicos y se obtiene su única instancia llamando a getRuntime() P. RELACIONADOSEl patrón 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 patrón Cache Management, utilizado para implementar cache de objetos, solo que el patrón Singleton tendría un cache de un solo objeto.

PATRONES ESTRUCTURALESAnterior - 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 INTENCIONConvierte la interfaz de una clase en otra más compatible con nuestras necesidades. CONOCIDO COMOClass Adapter, Object Adapter, Wrapper MOTIVOReduce la dependencia entre clases. APLICACIONES

Para utilizar la interfaz de una librería que no coincide con la que se requiere.

Para extender la funcionalidad de una librería existente.

ESTRUCTURAAdaptador de Clase

Adaptador de Objeto

PARTICIPANTES Cliente Clase que hace uso de otras clases a través 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é métodos 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 válidos 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é métodos 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.

IMPLEMENTACIÓNEl 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 implementación. Mediante sobrecarga (caso de C++ p.e) o implementación de la interfaz (caso de Java, ActiveX, etc) se conecta el interfaz con los métodos 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 implementación), se construyen los miembros de la interfaz destino mediante llamadas al objeto original.

CODIGO DE EJEMPLO

USOS CONOCIDOSHierarchyBoundsAdapter? 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 además pretende cambiar la funcionalidad del método llamado.

Bridge - Handle/Body

Anterior - Indice - Siguiente

Bridge INTENCIONSepara una abstracción de su implementación de forma que ambas pueden evolucionar por separado. CONOCIDO COMOHandle/Body

MOTIVO La herencia permite tener diferentes implementaciones de

una abstracción. En ocasiones una jerarquía de clases requiere

implementaciones para diferentes plataformas, por lo que hay que separar la abstracción de la implementación.

APLICACIONES Para evitar una vinculación permanente entre un interfaz y su

implementación, ya que la ligadura se produce en tiempo de ejecución.

Cuando tanto la abstracción como la implementación van a formar un arbol de clases derivadas.

Para evitar recompilar los clientes cuando cambien las implementaciones.

El patrón 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 están en evolución.

ESTRUCTURA

PARTICIPANTES

COLABORACIONES

CONSECUENCIAS

IMPLEMENTACIÓNUna Factoria Abstracta permite crear y configurar un Bridge concreto, decidiendo qué clase instanciar, esta factoría puede ser un Singleton. CODIGO DE EJEMPLO

USOS CONOCIDOS

ContentHandler/ContentHandlerFactory P. RELACIONADOS

Proxy - Surrogate - Virtual Proxy

Anterior - Indice - Siguiente

Proxy INTENCIONUn objeto sustituye a otro para controlar el acceso al mismo. CONOCIDO COMOSurrogate, Virtual Proxy MOTIVOEn ocasiones se desea retrasar la instanciación 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 información que necesita.

Otro motivo para su uso es sustituir a un sistema remoto, de forma que se accede al mismo através 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 creación de objetos hasta que

sean necesarios. Proxy de Protección Para controlar el acceso a un objeto. Proxy de Sincronización Para gestionar accesos de

multiples clientes a un recurso. Referencias Inteligentes Para gestión y mantenimiento del

acceso a un objeto real, permite contabilizar su utilización 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 aplicación, 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 común. Puede realizar un preprocesamiento y un postprocesamiento sobre los servicios ofrecidos por la clase original, este procesamiento adicional puede tener los objetivos de: transformar infomación (parametros de llamada y resultados), control de acceso, tareas de conexión remota, retraso en la instanciación, destrucción 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 instanciación de

recursos y al hacer cache. Aumenta la seguridad. Los clientes se desentienden de la ubicación de los

componentes accedidos.

IMPLEMENTACIÓN Se diseña la clase Proxy con iguan interfaz que la clase

original, si es posible se hereda de una clase abstracta común a la clase original.

Según el tipo de proxy (remoto, virual, etc) se le añaden métodos 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 CONOCIDOSOMG-CORBA, Orbix, Clase Proxy del API Java. P. RELACIONADOS

Composite

Anterior - Indice - Siguiente

Composite INTENCIONConstruir objetos de complejidad mayor mediante otros más sencillos de forma recursiva, formando una estructura similar a un arbol. CONOCIDO COMOComposite MOTIVOLas aplicaciones gráficas 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.

APLICACIONESCuando sea necesario utilizar de igual forma objetos sencillos que agrupaciones de estos. ESTRUCTURA

PARTICIPANTES Cliente Clase que crea los objetos. ComponenteAbstracto Clase abstracta común a todos los

objetos, define los métodos u operaciones que pueden realizar tanto los objetos individuales como los compuestos.

CompositeAbstracto Declara los métodos propios de los objetos compuestos, normalmente add(Componente) para añadir 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 básicos 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 diseño.

IMPLEMENTACIÓN Gestionar los enlaces al padre. Estudiar si se desea que una agrupación admite

agrupaciones o solo objetos simples. Operaciones de gestión de nodos hijos (add, remove,

getChild). Estudiar si interesa que tenga significado el orden de los

hijos. Estudiar la destrucción 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 CONOCIDOSComposite P. RELACIONADOSChain of Responsability

Decorador - Decorator - Wrapper

Anterior - Indice - Siguiente

Decorador INTENCIONAñadir nuevas responsabilidades dinámicamente a un objeto, es una alternativa a crear demasiadas subclases por herencia. CONOCIDO COMO

Decorator, wrapper MOTIVOPermite añadir nuevas responsabilidades a una instancia concreta y no a toda la clase y subclases. APLICACIONES

Para añadir funcionalidad a una clase sin utilizar herencia. Cunado se quiera añadir funcionalidad a una clase de forma

dinámica en tiempo de ejecución.

ESTRUCTURA

PARTICIPANTES Componente Clase abstracta común 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 común a todos los decoradores y declara (o implementa, según) la responsabilidad de mantener una referencia al objeto que se extiende. Es posible que sobrecargue todos los métodos de la clase Componente con llamadas al componente concreto, de forma que aquellos métodos 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 más flexibilidad que la herencia estática. Se consiguen componentes pequeños. Se reduce el número de clases y el arbol de herencia de

clases.

IMPLEMENTACIÓN Los decoradores deben conocer el interfaz del componente

para poder utilizarlo, se puede realizar mediante interfaz o mediante herencia.

Decorator y Strategy. La acción del decorador se puede realizar antes o despues de llamar a los métodos de otro objeto, el patron Strategy nos permite especificar lo que se produce en medio de la llamada a un método.

CODIGO DE EJEMPLO

USOS CONOCIDOS

P. RELACIONADOS Delegation El prototipo Decorator es en última instancia una

forma de llevar a cabo el patrón Delegation. Filter Es un patron Decorator especializado enla

manipulación de stremas de datos. Strategy Mientras que el patrón Decorator permite

especificar lo que ocurre antes y despues de llamar a un método de otro objeto, para controlar lo que se produce entre ambos se puede utilizar el patrón Strategy.

Template Method Es una alternativa a Decorator util para indicar lo que sucede en medio de una llamada a un método (en lugar de antes y después).

Adaptor El patrón Decorator no amplía 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 INTENCIONSimplifica el acceso a un conjunto de clases o interfaces. CONOCIDO COMOFacade MOTIVOReducir 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 más 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.

IMPLEMENTACIÓN

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 INTENCIONDelega responsabilidades a una clase especializada. CONOCIDO COMOChain of Responsability, expert, experto MOTIVOEs una forma de distribuir la ejecución repartiendo las responsabilidades. Es la forma básica de repartir las responsabilidades al realizar un Diseño Orientado a Objetos, por lo tanto lo utilizamos de forma intuitiva en este tipo de diseños. APLICACIONESSe puede utilizar junto al patron Composite, de forma que los hijos tienen un enlace al padre que les permite acceder a información sin conocer la clase que las contiene así como propagar la ejecución. ESTRUCTURA

PARTICIPANTES

COLABORACIONES

CONSECUENCIAS

Ofrece las principales ventajas de la Programación Orientada a Objetos.

Mejora la encapsulación. Facilita el mantenimiento. Ofrece reusabilidad.

IMPLEMENTACIÓNSe implementa asignando a cada clase las operaciones relativas a la información que contienen. CODIGO DE EJEMPLO

USOS CONOCIDOSEl Diseño Orientado a Objetos en general. P. RELACIONADOSComposite

Command

Anterior - Indice - Siguiente

Command INTENCIONEncapsula una petición como un objeto, esto facilita la parametrización de los requerimientos (inicialización de los parámetros por el constructor), el encolado de multiples peticiones (estructura de datos de objetos comando) y su reordenación, y permite implementar el hacer/deshacer (do/undo) mediante métodos.

Por otro lado se facilita la creación de macros agrupando los comandos más frecuentes.

CONOCIDO COMOCommand MOTIVOEl 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 ofimáticos, 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 ampliación.

APLICACIONESCuando se requiera:

Facilitar la parametrización de las acciones a realizar. Independizar el momento de petición del de ejecución.

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 más sencillas (primitivas).

ESTRUCTURA

PARTICIPANTESAbstractCommand. Clase que ofrece un interfaz para la ejecución de comandos. Define los métodos do y undo que se implementarán en cada clase concreta.

ConcreteCommand. Clase que implementa un comando concreto y sus métodos do y undo. Su constructor debe inicializar los parámetros 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 colección de objetos comando creadas por el Invoker. llamará a los métodos doIt y unDoIt. Gestionará su secuenciación y reordenación (en base a prioridades por ejemplo).

COLABORACIONES

CONSECUENCIAS

Se independiza la parte de la aplicación que invoca los comandos de la implementación de los mismos.

Al tratarse los comandos como objetos, se puede realizar herencia de los mismos, composiciones de comandos (mediante el patrón Composite)

Se facilita la ampliación del conjunto de comandos.

IMPLEMENTACIÓNCombiene estudiar el conjunto de comandos a implementar y si se observan comandos demasiado complejos dividirlos en subcomandos más 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 restauración al ejecutar Undo (pensar en el patrón Memento).

Pueden aparecer comandos cuya acción 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 operación no podrá deshacerse dandole la opción 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 atrás. 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 CONOCIDOSLas clases Button y MenuItem de Java facilitan la utilización de este patrón, declaran los métodos 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 además del uso del command manager.

Interprete Se puede imnplementar un pequeño Interprete mediante clases Command.

Snapshot Puede facilitar el almacenamiento del estado de los objetos para implementar la acción Deshacer en lugar de utilizar comandos inversos.

Template Method Puede servir para implementar la lógica de Deshacer de forma un tanto automática 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 INTENCIONSimplifica el desarrollo utilizando una gramatica sencilla CONOCIDO COMOInterpreter MOTIVO

APLICACIONES

ESTRUCTURA

PARTICIPANTES

COLABORACIONES

CONSECUENCIAS

IMPLEMENTACIÓN

CODIGO DE EJEMPLO

USOS CONOCIDOS

P. RELACIONADOS

Iterador - Iterator

Anterior - Indice - Siguiente

Iterador INTENCIONPermite acceder secuencialmente a los elementos de estructura de datos u objetos preservando su estructura interna. CONOCIDO COMOIterator MOTIVO

APLICACIONES Cuando se desea acceder al contenido de una colección sin

depender demasiado de la estructura de clase de los elementos contenidos.

Para disponer de una forma homogénea de acceder al contenido de distintas colecciones.

Cuando se quiere recorrer una colección de múltiples formas.

ESTRUCTURA

PARTICIPANTES IIterator: Interfaz que define los métodos 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

CONSECUENCIASPodemos 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 colección utilizando varios Iteratos, cada uno se encarga de controlar en que posición está.

Se simplifica el código de la clase Collection, ya que la implementación de la forma de recorrido se encuentra en las clases Iterator.

IMPLEMENTACIÓNIIterator define los mínimos métodos para situarse al principio/final de la colección, 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 colección 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 CONOCIDOSLas clases Collection del paquete java.util utilizan el patron Iterator. P. RELACIONADOSEl patrón 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 patrón Null Object.

Mediador - Mediator

Anterior - Indice - Siguiente

Mediador INTENCIONCoordina interaciones entre objetos relacionados, centraliza en una clase la lógica de que realiza los cambios de estados de los objetos, en lugar de diseminarlo en las multiples clases que componen la aplicación. CONOCIDO COMOMediator MOTIVO

Ofrece una forma sistematizada de aumentar la cohesión (se centraliza la lógica) y reducir el acoplamiento entre clases (se reducen la dependencias entre ellas). APLICACIONESCuando 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 notificarán 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, existirán 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 más fáciles de manejar e implementar.

Las clases son más 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 lógica de la aplicación.

IMPLEMENTACIÓNUna consideración a tener en cuanta a la hora de implementar la clase Mediator es si te interesa que el propio Mediator guarde información sobre el estado de cada una de las clases o acude a las mismas para recuperar dicha información. La primera de las alternativas es más arriesgada pues se pueden producir diferencias entre el estado real de los objetos y la información que el Mediator guarda. CODIGO DE EJEMPLO

USOS CONOCIDOS

P. RELACIONADOS Observer Las clases Mediator frecuentemente utilizan el

patrón 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 INTENCIONGuarda el estado de un objeto para restaurarlo posteriormente CONOCIDO COMOMemento MOTIVO

APLICACIONES

ESTRUCTURA

PARTICIPANTES

COLABORACIONES

CONSECUENCIAS

IMPLEMENTACIÓN

CODIGO DE EJEMPLO

USOS CONOCIDOS

P. RELACIONADOS

Observador - Observer

Anterior - Indice - Siguiente

Observador INTENCIONNotifica automáticamente de los cambios de estado de un objeto a todos sus dependientes.

Permite de forma deinámica 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 COMOObserver MOTIVO

Encapsular la gestión de las dependencias dinámicas permite centralizar su gestión, 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 dinámica, en tiempo de ejecución 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 básicos que solo permiten notificar a un único objeto.

ESTRUCTURA

PARTICIPANTES IObserver Interfaz orientado a las clases dependientes,

declara un método Notify() que permite al objeto observado notificar de sus cambios alos que dependen de el.

IObservable Interfaz que implementarán los clases de las que se depende, declara los métodos addObserver que permite registrar una instancia dependiente y removeObserver para eliminar la dependencia. Esta característica le da el aspecto dinámico al sistema de notificación, ya que el enlace entre el objeto dependiente y del que se depende se realiza en tiempo de ejecución mediante el empleo de estos métodos.

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 notificación en una sola clase permite reutilizar facilmente el mecanismo.

COLABORACIONES

CONSECUENCIAS Permite enviar notificaciones desde un objeto a muchos, de

forma dinámica 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 notificación 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 notificación 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 notificación, de forma qeu el objeto no aceptará nuevas notificaciones hasta que haya terminado con la anterior, de forma que se interrumpe el ciclo.

IMPLEMENTACIÓNGeneralmente el objeto Observable al notificar al objeto Observer le pasa una referencia de si mismo como parámetro del método notify (o de alguna otra forma) de manera que el objeto receptor de la notificación 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 noficación necesita saber de quien le viene.

Independientemente de como implementes la solución a esto siempre llegarás a la conclusión de que las formas más prácticas requieren que la clase Observer conozca concretamente la clase Observable o se utilicen interfaces especificos para cada tipo de

notificación según 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 específico?

Particularmente prefiero pasar una referencia del objeto Observable (o de una clase padre) como parámetro del método notify.

En ocasiones conviene reducir el número de notificaciones simplemente por que se van a producir más cambios, en este caso se espera a que se produzcan todos los cambios y se retrasa la notificación hasta que se han completado todos. Se puede implementar añadiendo dos métodos a la clase Observable para indicar el comienzo de cambios y el final de los mismos, de forma que las notificaciones están desacivadas entre tanto. Esta solución se complica si son multiples objetos los que participan en ese conjunto de cambios, se puede utilizar un patrón Mediator en este caso.

CODIGO DE EJEMPLO

USOS CONOCIDOS Delegación 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 patrón 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 número de notificaciones)

Estado - State

Anterior - Indice - Siguiente

Estado INTENCIONModelo para que un objeto cambie su comportamiento dependiendo de su estado, pudiendo incluso aparentar que cambia de clase. CONOCIDO COMOState MOTIVO

Incorpora a los patrones el concepto de "Maquina Abstracta" o autómata, utilizado desde los orígenes de la Informática y estudiado mucho antes.

Ofrece un modelo basado en la programación orientada a objetos frente a las formas clasicas de programación de autómatas finitos.

APLICACIONESEn principio para aquellos sitemas que representemos como un autómata o máquina abstracta:

Analizadores (Parsers) léxicos y sintacticos en desarrollos de lenguajes (compiladores, intérpretes, 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 aplicación que utiliza una máquina de

estados. AppState La parte de la aplicación que gestiona los estados

de la máquina. EstadoConcreto* Clases para cada uno de los estados en

que puede estar, es una clase derivada de AppState y gestiona el comportamiento de la máquina para cada uno de los estados.

COLABORACIONES

CONSECUENCIAS

IMPLEMENTACIÓNUtilizar 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 mantendrán una referencia al objeto que encapsule el estado o devolverán la instancia de la clase que representa el estado actual.

Esto permite añadir nuevos estados simplemente incorporando nuevas subclases.

CODIGO DE EJEMPLO

USOS CONOCIDOSStateEdit AccesibleState DirStateFactory StateEditable StateFactory P. RELACIONADOSLas máquinas abstractas (o autómatas) suelen responder a mensajes con una respuesta y un cambio de estado, por lo que el patrón controller estaría bien para la gestión 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 patrón singleton.

Estrategia - Strategy

Anterior - Indice - Siguiente

Estrategia

INTENCIONAbstracción para seleccionar entre varios algoritmos CONOCIDO COMOStrategy MOTIVOEncapsula varios algoritmos alternativos en diferentes clases y se ofrece un interfaz único (mediante una superclase) para acceder a la funcionalidad ofrecida, la elección del algoritmo se vuelve transparente para el cliente, pudiendo depender del objeto e incluso variar en el tiempo. APLICACIONESCuando la aplicación debe ofrecer varios algoritmos alternativos para un mismo comportamiento.

Una operación de "Guardar" un documento puede ser distinta según sea el destino elegido un directorio local o un servidor ftp remoto.

La funcionalidad de comprobación de integridad de un archivo puede realizarse mediante CRC u otro algoritmo.

Un sistema puede requerir cifrar un contenido mediante diferentes metodos de encriptación.

ESTRUCTURA

PARTICIPANTESEl Cliente delega una operación en la superclase, abstrayendose de los detalles de la misma. La superclase AlgoritmoAbstracto ofrece un interfaz común y oculta la elección del algoritmo empleado. Las clases AlgoritmoConcreto implementa cada una de las diferentes alternativas del algoritmo. COLABORACIONES

CONSECUENCIASLa elección del algoritmo se realiza de forma dinámica en tiempo de ejecución.

Se simplifica la clase cliente al independizarse de la decisión de qué algoritmo utilizar. Se reducen las estrcturas if y switch en el cliente.

Según el caso se puede incrementar la velocidad de ejecuciónde los objetos cliente al no tener que realizar ellos mismos el algoritmo (en entornos concurrentes)

IMPLEMENTACIÓNSi 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 operación, 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 operación.

CODIGO DE EJEMPLO

USOS CONOCIDOSEl paquete java.util.zip en las clases CheckedInputStream y CheckedOutputStream utilizan la clase Checksum la cual sigue el patrón Strategy para elegir entre los algoritmos de comprobación de errores en Streams de bytes ya sea CRC32 o Adler32. P. RELACIONADOSSi existen muchas instancias de Cliente es mejor utilizar el patron Flyweights en lugar de Strategy.

El patrón Template Method utiliza diferentes algoritmos mediante subclases en lugar de mediante delegación.

Template method

Anterior - Indice - Siguiente

Template method INTENCIONEncapsula un algoritmo en una clase abstracta de forma que puede ser reutilizada. CONOCIDO COMOTemplate method MOTIVOMuchos algoritmos pueden ser reutilizados aportando cierta información específica propia de los elementos que tenga que tratar en cada momento. APLICACIONESAquellos algoritmos que no dependen directamente del tipo de objetos con los que operan.

Un algoritmo de ordenación en general no depende de si ordena números 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 codificación del algoritmos y

declara métodos virtuales que realizarán las operaciones dependientes de cada tipo de datos.

Clase Concreta Deriva de la clase abstracta, con lo que ya hereda el algoritmo genérico. Debe implementar los métodos virtuales para permitirle operar con un tipo concreto de datos.

COLABORACIONES

CONSECUENCIASEl algoritmo es reutilizable para cualquier tipo de datos con el que tenga sentido.

Al centralizar la lógica en una sola clase se simplifica el mantenimiento y cualquier mejora sobre el algoritmo beneficia directamente a todas las clases que derivan de el.

IMPLEMENTACIÓNSe encapsula el algorito en una clase abstracta, cualquier operación sobre los datos se realiza llamando a un método que se declara como virtual para que sean especificadas por las clases derivadas. CODIGO DE EJEMPLOpublic abstract class insertSorter {

// Template methodpublic 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 CONOCIDOSEs muy frecuente su utilización en algoritmos genéricos de ordenación y búsqueda.

En la plataforma .NET se utiliza un patrón template para implementar una forma génerica de gestión de eventos, puede verse en la dirección: .NET Event Handling using the Template Method Design Pattern

P. RELACIONADOSEl patrón Strategy nos ofrece una alternativa a la reutilización de algoritmos.

Visitor

Anterior - Indice - Siguiente

Visitor INTENCIONOperaciones sobre elementos de una estructura de objetos heterogénea. CONOCIDO COMOVisitor MOTIVO

APLICACIONES

ESTRUCTURA

PARTICIPANTES

COLABORACIONES

CONSECUENCIAS

IMPLEMENTACIÓN

CODIGO DE EJEMPLO

USOS CONOCIDOS

P. RELACIONADOS

Viewer/Controller - Vista/Controlador

Anterior - Indice - Siguiente

Vista Controlador INTENCIONEl controlador tiene la responsabilidad de gestionar un sistema de mensajes. CONOCIDO COMOModelo Vista Controlador, Viewer Controller Model, MVC MOTIVOEn sistemas complejos de eventos y mensajes en ocasiones es dificil determinar quien debe responder a un mensaje. Este patrón encapsula en una sola clase la atención 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 atención de los eventos y la modificación de los datos y a su vez se delega en una clase vista la representación de dicha información, es decir la actualización de los cambios en el sistema de representación (sistema de ventanas habitualmente)

APLICACIONESSe utiliza sobre todo en entornos gráficos de usuario interactivos, ya que el número y posibilidades de mensajes, así como el elevado número de objetos visuales dificultan la gentión de la información 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 información, y multiples clases Vista ofrecen las diferente representaciones de la misma información, por ejemplo diferentes diagramas (de barras, de tarta, etc) de una aplicación estadística u hoa de cálculo.

ESTRUCTURA

PARTICIPANTES Controller Recibe los eventos o mensajes, opera sobre los

objetos de datos.

Vista Representa la información en pantalla o sistema de representación concreto, actualiza la visualización de los cambios realizados en la información.

COLABORACIONES

CONSECUENCIASAl 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 comunicación 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 patrón State. IMPLEMENTACIÓN

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 típico, 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 más 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 elección de la alternativa mejor.

Se clasifican en antipatrones de desarrollo, de arquitectura del software y de gestión de proyectos.

Desarrollo de Software

Anterior - Indice - Siguiente

The Blob (Clases Gigantes) Lava Flow (Código Muerto) Cuando se continua incluyendo

código en la aplicación que ya no se utiliza, como continuar incluyendo código para Win16 cuando la aplicación ya solo funciona para 32 bits. Se mantiene código que se supone importante aunque se desconoce si se seguirá utilizando. Un exceso de rotación de personal unida a una pobre documentación puede provocar esta situación. El código se llena de comentarios del tipo "//Importante, no quitar" y nadie recuerda porque era necesario. La solución pasa por mantener actualizada la documentación y por depurar el código obsoleto, Java facilita este mantenimiento al disponerse de la clausula "deprecated" para mantener el código obsoleto solo por un tiempo.

Functional Decomposition (Diseño 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 código)

Arquitectura del Software

Anterior - Indice - Siguiente

Stovepipe enterprise (Aislamiento en la empresa, Islas de Automatización o Empresa con sistemas parcheados). Se produce cuando en la empresa se desarrollan sistemas de manera independiente, esto dificulta la interconexión de sistemas y la reutilización e incrementa los costes de desarrollo. Es cuando se crean Islas de automatización, y provoca que existan tecnologías incompatibles, arquitecturas monolíticas y falta de documentación (no es necesario hacer un mapa de la isla, sus habitantes la conocen bien). Se dificulta la ampliación de los sistemas, suelen faltar estándares (si se utilizasen estándares tendríamos sistemas homogéneos y no diferentes). La causa suele estar en una falta de estrategia tecnológica en la empresa, falta de cooperación y comunicación entre departamentos y niveles, deficiencias en el conocimiento de la tecnología, en definitiva ausencia de un Plan Informático.

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 comunicación 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 sustitución completa. Suele producirse un distanciamiento entre la documentación y el desarrollo. Los diseñadores ignoran los detalles de integración. 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 documentación. Los cambios requieren fuertes esfuerzos y se recurre a parches provisionales. La causa puede ser la utilización de multiples formas de integración de los subsistemas (por ejemplo modulos enlazados estáticamente en unos casos y de forma dinámica en otros) con lo que el sistema es dificil de documentar y mantener, Falta de Abstracción ofreciendose interfaces únicos y rígidos, Ausencia de Metadatos ofreciendose pocas alternativas a la ampliación y configuración del sistema. una solución es la Arquitectura basada en Componentes ya que permite una facil sustitución de los módulos del sistema, usar ISO IDL (CORBA) o semejantes.

Vendor Lock-In (Arquitectura dependiente del producto, Ammarrado por el vendedor, Esclavitud y Sumisión) Cuando los proyectos de desarrollo de software se basan en soluciones tecnológicas propietarias de un vendedor concreto, al tomar la tecnología de un producto se depende del vendedor. Nuevas versiones del producto comercial pueden ser incompatibles, alejadas de los estándares y las arquitecturas abiertas, todo ello dificulta el mantenimiento del sistema. La solución a este problema pasa por no adquirir paquetes en base a la publicidad del vendedor sin un examen técnico detallado y pruebas de validación. Se puede minimizar su impacto utilizando el Patrón 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 aplicación.

Architecture by implication (Arquitectura Implícita). Sucede cuando no se especifica la arquitectura del sistema o ignora alguno de sus apartados: Arquitectura del software (especificación del lenguaje, bibliotecas, nomenclaturas), Arquitectura hardware (configuración de clientes y servidores), Arquitectura de comunicación (protocolos y dispositivos de red), Arquitectura de Datos (archivos y Bases de Datos), Arquitectura de seguridad, Administración de Sistemas, etc. Se suele dar cuando se considera que la documentación 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 técnico, etc.

Design by committee (Diseño por Comité, Navaja suiza, Chapa de Oro, Enfermedad de Estandarización) Se da cuando el proyecto se diseña a través 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 documentación 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 solución 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 ceñir las abstracciones a los mismos.

Reinvent the wheel Se supone que se debe desarrollar desde cero, falta información y tecnología reusable entre proyectos. Falta de visión empresarial. Arquitectura cerrada y específica para un proyecto. La solución es la búsqueda de tecnología reutilizable (la reusabilidad empieza por reutilizar lo existente antes que por diseñar sistemas reutilizables), identificar interfaces estándar.

Gestión de Proyectos Software

Anterior - Indice - Siguiente

Analysis paralysis Se da cuando un equipo de inteligentes analistas comienzan una fase de análisis que solo acaba cuando se cancela el proyecto. El propio nombre del proyecto puede anticiparnos esta situación (si incluye "Super", "Mega", "2000", "Galaxia", "Global" etc. ¡cuidado!) este síndrome del gran proyecto se refleja en la pretensión 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 revisión contínua. Pueden existir conflictos entre objetivos en ocasiones por causas políticas. La solución consiste en realizar desarrollos pequeños (tengase en cuenta la velocidad de evolución de la tecnología, un proyecto a más de 6 meses se topará con cambios tecnológicos). Utilizar

desarrolladores antes que analistas, los desarrolladores pueden aprender a analizar un requerimiento, mientras que la mayoría de los analistas no son capaces de desarrollar una solución. Comenzar el proyecto con un prototipo de arquitectura y un conjunto reducido de requerimientos para desarrollar en no más de un mes.

Death by planning Corncob (Personas problematicas) Irrational management Project mismanegement

APARTADO B. HerramientasAnterior - Indice - Siguiente

En la actualidad no se dispone de ninguna herramienta para la utilización directa de los Patrones de Diseño en el proceso de desarrollo de una manera completa.

Algunos intentos se han basado en el diseño de clases que representan al patrón 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 Patrón, ya que un mismo patrón puede tener muchas implementaciones diferentes (tomar una codificación concreta puede ser util en unos casos y molesta en otros) ya que el patrón es solo la "idea" y no una codificación concreta. De hecho al codificar un patrón éste deja de serlo, ya no es una solución a un problema reiterativo, sino un ejemplo de una solución 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 código (en la depuración o al hacer ingeniería inversa)

La solución más frecuente pasa por incluir en los nombres de las clases el nombre del patrón (o del colaborador concreto), de esta forma podemos suponer que la clase SingletonVentana se trata de una clase para el acceso a algúntipo de ventanas y que se forma en base al patrón Singleton, con tolo lo que implica: instancia única para el acceso a ese recurso, provablemente tendrá algún método de tipo getInstance o getVentana, así en base a la intuición y a los nombres utilizados podemos preveer los patrones. No obstante no es un método lo suficientemente convincente.

Personalmente veo los patrones como un wizard o asistente más 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 ingeniería inversa y Patrones de Diseño, 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

AutoresAnterior - 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

ConferenciasAnterior - 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 (old webpage for

PLoP) 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 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. LinksAnterior - Indice - Siguiente

Links de Patrones de Diseño

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 - Guía de Patrones de Diseño 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 Hernández Tejada Última modificación: 08/09/2002 | Peso HTML: 152.12 Kb. | Peso imágenes (32): 75.45 Kb. | Peso Total: 227.57 Kb.

Optimizada para el Explorer 5.x o Netscape 6.x