GUIA DE PATRONES DE DISEÑO
Indice Introducción
1.- 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ón 2.- 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 .
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.- Gestión 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 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.
INTRODUCCION Anterior - 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 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 l os 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 m anera 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 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 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 INTENCION Objetivos del patron CONOCIDO COMO Otros nombres MOTIVO Motivaciones que justifican que se considere como un patron APLICACIONES Posibles usos ESTRUCTURA Esquema gráfico que describe el patrón. PARTICIPANTES
Descripción de los elementos que intervien COLABORACIONES Descripción de las relaciones entre los PARTICIPANTES CONSECUENCIAS Beneficios, 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 EJEMPLO Codigo de un ejemplo de utilización USOS CONOCIDOS Productos y sistemas conocidos que recuerde rápidamente el lector y facilite su comprensión P. RELACIONADOS Patrones que pueden funcionar como alternativa o de forma complementaria
Otros Patrones Anterior - Indice - Siguiente
Además de los Patrones 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 CREACION Anterior - 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 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 común para crear diferentes familias de clases. APLICACIONES En 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.
•
•
COLABORACIONES Toda 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 otr as 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ÓN Informació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 INTENCION Permite a un cliente crear un objeto especificando tipo y contenido, ocultandose el resto de detalles. CONOCIDO COMO Builder, Creador MOTIVO La creación de objetos o instanciación i nstanciació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. APLICACIONES Una 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. i nstanciar. •
•
•
ESTRUCTURA
PARTICIPANTES
COLABORACIONES
CONSECUENCIAS Reduce el acoplamiento. Permite variar la representación interna de estructuras compleja, respetando la interfaz comun de la l a 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 paso la creación del objeto. •
• •
•
Método Factoría - Factory Method - Virtual Constructor Anterior - Indice - Siguiente
Método Factoría INTENCION Abstraer la instanciación de clases clases relegando esta responsabilidad responsabilidad a las mismas clases. CONOCIDO COMO Factory Method, Virtual Constructor. MOTIVO Es un modelo que utiliza abstracción de clases para crear y relacionar objetos sin conocer de qué clase son. APLICACIONES Se 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 INTENCION Permite crear objetos copiando un modelo existente. CONOCIDO COMO Prototype MOTIVO Reducir el número de clases. APLICACIONES Se utiliza cuando se quiere abstraer el proceso de creación de objetos y cuando las clases a instanciar i nstanciar 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 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 método clone se garantiza que cada objeto crea una instancia coherente. • •
•
•
•
•
IMPLEMENTACIÓN Se 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 CONOCIDOS Los 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 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 método 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. 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 l a 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ÓN La 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 EJEMPLO class Singleton{ private static Singleton instanciaUnica=null; public static Singleton instance(){ if (instaciaUnica==null){ instanciaUnica=new Singleton(); } return instanciaUnica; instanciaUnica; } }
USOS CONOCIDOS La 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. RELACIONADOS El 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 ESTRUCTURAL ESTRUCTURALES ES 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 más compatible con nuestras necesidades. CONOCIDO COMO Class Adapter, Object Adapter, Wrapper MOTIVO Reduce 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. •
•
ESTRUCTURA Adaptador 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 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 l as 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 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ÓN El Adaptador de Clase se implementa i mplementa 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 m iembros de la interfaz destino mediante llamadas al objeto original. CODIGO DE EJEMPLO USOS CONOCIDOS HierarchyBoundsAdapter? 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 l a que se llama. Strategy Tambien es similar a Adaptor, pero Strategy además pretende cambiar la funcionalidad del método llamado. •
•
•
•
Bridge - Handle/Body Handle/Body Anterior - Indice - Siguiente
Bridge
INTENCION Separa una abstracción de su implementación de forma que ambas pueden evolucionar por separado. CONOCIDO COMO Handle/Body MOTIVO La herencia permite tener diferentes implementaciones i mplementaciones 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 l a 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ÓN
Una 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 INTENCION Un objeto sustituye a otro para controlar el acceso al mismo. CONOCIDO COMO Surrogate, Virtual Proxy MOTIVO En ocasiones se desea retrasar la instanciación i nstanciació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é. im plementa los servicios Original Es la clase que implementa 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 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 más sencillos de forma recursiva, formando una estructura similar a un arbol. CONOCIDO COMO Composite MOTIVO Las 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. 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 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 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, r emove, 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 CONOCIDOS Composite P. RELACIONADOS Chain of Responsability
Decorador Decorador - Decorator - Wrapper Anterior - Indice - Siguiente
Decorador INTENCION Añadir nuevas responsabilidades responsabilidades dinámicamente a un un objeto, es una alternativa a crear demasiadas subclases subclases por herencia. CONOCIDO COMO Decorator, wrapper MOTIVO Permite 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 ( 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. f uncionalidad. 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 l a 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 INTENCION Delega responsabilidades a una clase especializada. CONOCIDO COMO
Chain of Responsability, expert, experto MOTIVO Es 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. APLICACIONES Se 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. encapsulación. Facilita el mantenimiento. Ofrece reusabilidad.
IMPLEMENTACIÓN Se implementa asignando a cada clase las operaciones relativas a la información que contienen. CODIGO DE EJEMPLO USOS CONOCIDOS El Diseño Orientado a Objetos en general. P. RELACIONADOS Composite
Command Anterior - Indice - Siguiente
Command INTENCION Encapsula 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 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 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. APLICACIONES Cuando 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
PARTICIPANTES AbstractCommand. 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 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 l a aplicación que invoca los comandos de la implementación de los mismos. Al tratarse los comandos como objetos, 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ÓN
Combiene estudiar el conjunto de comandos a implementar im plementar 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 CONOCIDOS Las 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 l a acción Deshacer en lugar de utilizar comandos inversos. i nversos. 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 INTENCION Simplifica el desarrollo utilizando una gramatica sencilla CONOCIDO COMO Interpreter MOTIVO APLICACIONES ESTRUCTURA PARTICIPANTES COLABORACIONES CONSECUENCIAS IMPLEMENTACIÓN 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 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. 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 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ÓN IIterator 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 CONOCIDOS Las clases Collection del paquete java.util utilizan el patron Iterator. P. RELACIONADOS El 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 INTENCION Coordina interaciones entre objetos relacionados, centraliza en una clase la lógica de que realiza los cambios de estados de los l os objetos, en lugar de diseminarlo en las multiples clases que componen la aplicación. CONOCIDO COMO Mediator 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). 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 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, i ndependiente, 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 lla a aplicación. •
•
IMPLEMENTACIÓN Una 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 INTENCION Guarda el estado de un objeto para restaurarlo posteriormente CONOCIDO COMO Memento MOTIVO APLICACIONES ESTRUCTURA
PARTICIPANTES COLABORACIONES CONSECUENCIAS IMPLEMENTACIÓN CODIGO DE EJEMPLO USOS CONOCIDOS P. RELACIONADOS
Observador Observador - Observer Anterior - Indice - Siguiente
Observador INTENCION Notifica automáticamente de los cambios de estado de un objeto a todos sus dependientes. Permite de forma deinámica implementar im plementar 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 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 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. 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 fl ag 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ÓN Generalmente 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 lllega lega la noficación necesita saber de quien le viene.
Independientemente Independientemente de como implementes i mplementes 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 ti po 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
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 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. APLICACIONES En 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 l a 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ÓN Utilizar una clase abstracta que represente al objeto y su interfaz, implementar una subclase para cada uno de los l os estados y metodos para cada una de las transiciones tr ansiciones 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 CONOCIDOS StateEdit AccesibleState DirStateFactory StateEditable StateFactory P. RELACIONADOS Las 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
INTENCION Abstracción para seleccionar seleccionar entre varios algoritmos CONOCIDO COMO Strategy MOTIVO Encapsula varios algoritmos alternativos en diferentes clases y se ofrece un interfaz único (mediante (m ediante 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. APLICACIONES Cuando 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
PARTICIPANTES El 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 CONSECUENCIAS La 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ÓN 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 operación, en ciertos casos es posible que no se pueda utilizar uti lizar 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 CONOCIDOS El paquete java.util.zip en las clases CheckedInputStream y CheckedOutputStream 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. RELACIONADOS Si 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 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 información específica propia de los elementos que tenga que tratar en cada momento. APLICACIONES Aquellos algoritmos que no dependen 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 i r 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 CONSECUENCIAS El algoritmo es reutilizable para cualquier tipo de datos con el que tenga sentido. Al centralizar la lógica en una sola clase clase se simplifica el mantenimiento y cualquier mejora sobre el algoritmo beneficia directamente a todas las clases que derivan de el. IMPLEMENTACIÓN Se encapsula el algorito en una clase abstracta, cualquier operación sobre los datos se realiza llamando l lamando a un método 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],da (esMenor(datos[min],datos[j])) tos[j])) if j++){ j="1;j
USOS CONOCIDOS Es 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. RELACIONADOS El patrón Strategy nos ofrece una alternativa a la reutilización de algoritmos.
Visitor Anterior - Indice - Siguiente
Visitor INTENCION Operaciones sobre elementos de una estructura de objetos heterogénea. CONOCIDO COMO Visitor MOTIVO APLICACIONES ESTRUCTURA PARTICIPANTES COLABORACIONES CONSECUENCIAS IMPLEMENTACIÓN CODIGO DE EJEMPLO
USOS CONOCIDOS P. RELACIONADOS
Viewer/Controller - Vista/Controlador 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 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) APLICACIONES Se 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 representacione r epresentacioness 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 CONSECUENCIAS Al pasar por el controlador todos los mensajes 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.
APART APARTADO ADO A. Antipa Antipatro trones nes 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) 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 l os 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, 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 (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 suele dar cuando se considera que la documentación no es necesaria y la 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. Herramientas Anterior - 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 basado en el diseño de clases 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 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
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, Cockburn, Humans Humans and and Technology Technology Jim Coplien WardCunningham Amnon H. H. Eden, Home Home page 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 (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. Links Anterior - 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 Classification Of Of Object-Oriented Object-Oriented Design Design Patterns 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-Compu Human-Computer ter Interface 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 Introduction To Process Process Patterns 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 ADAPT ER - Adapter Adapter Known Known Uses ADAPTER ADAPT ER - Programmin Programming g Patterns Overview Overview:: Adapter
ADAPTER - CS 635 - Doc 21 Adapter ADAPTER Adapter ADAPTER ADAPT ER - Pattern: Pattern: Adapter 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 Anti-patte rns www.antipatterns.com Notes on Failure
Links de Grupos de Estudio Anterior - Indice - Siguiente
• • • • • • • • •
A Learning Learning Guide To To Design Patterns Patterns Groups Sillicon Valley Patterns Group The Israeli Patterns Reading Group The Analysis Patterns Group (news) comp.software.patterns
[email protected] The Coad Letter /languages/smalltalk/patterns/mail-archive
Links de Arquitecturas de Objetos Anterior - Indice - Siguiente • • • • •
ActiveX/COM 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.5 Optimizada para el Explorer 5.x o Netscape 6.x
