Antes de nada te pedimos que participes en la encuesta "Patrones de diseño de software"Gang of Four
En 1994 los ahora conocidos
como la banda de los cuatro (GoF) se unieron para publicar el libro
"Design Patterns: Elements of Reusable Object Oriented Software", en
él describen soluciones simples y elegantes a problemas específicos del diseño
orientado a objetos. Fue escrito por Erich Gamma, Richard Helm,
Ralph Johnson y
John Vlissides
Erich Gamma lideró el
desarrollo de la plataforma Eclipse y fue
creador junto a Kent Beck
del framework de pruebas JUnit. Erich tiene
un doctorado en Ciencias de la Computación de la Universidad de Zurich. Actualmente
se encuentra trabajando para Microsoft en el equipo de Visual Studio.
Richard Helm fue consultor
de tecnología en DMR. Allí aplicó de forma activa los patrones de diseño orientados
a sistemas comerciales. Anteriormente trabajaba en el departamento de
Tecnología de IBM. Tiene numerosas publicaciones internacionales y escribe
regularmente en el Diario del Dr. Dobb.
Además fue miembro del comité de OOPSLA
(conferencia sobre programación orientada a objetos). Richard tiene un doctorado en Ciencias de la Computación de la
Universidad de Melbourne. Actualmente se encuentra trabajando de nuevo en IBM.
Ralph Johnson ha estudiado
la programación orientada a objetos y la forma en que ha evolucionado durante
los últimos 10 años. Ha estado involucrado en el desarrollo de un sistema
operativo orientado a objetos y un compilador
de tipo Smalltalk. Ralph
tiene un doctorado por la Universidad de Cornell. Ha participado como
presidente de varias ediciones de la conferencia de OOPSLA. Actualmente está
trabajando en el Departamento de Ciencias de la Computación de la Universidad
de Illinois desarrollando un framework para contabilidad.
John Vlissides falleció
24 de noviembre de 2005. Fue investigador en el IBM T. J. Centro de
Investigación Watson. Sus investigaciones incluyen framework, herramientas y
técnicas de diseño orientado a objetos. Anteriormente John estuvo en el Departamento
de Sistemas de Computación de la Universidad de Stanford. John tiene un
doctorado en ingeniería eléctrica de la Universidad de Stanford.
Referencias
Los patrones aquí expuestos
se basan en el libro “Patronesde Diseño” que escribieron GoF y que todavía hoy en día sigue siendo una de
las principales referencias sobre el desarrollo de software y los patrones de
diseño.
Catálogo de patrones de diseño
Los patrones varían en su
nivel de abstracción y dado que existen numerosos patrones de diseño es
necesario organizarlos por familias.
El Propósito refleja que hace un patrón y puede ser:
- De Creación: Están relacionados con el proceso
de creación o instanciación de objetos.
- Estructural: Están relacionados con la
composición de clases y objetos.
- De Comportamiento: Están relacionados con el modo en
que las clases y objetos interactúan y el modo en que se reparten las
responsabilidades.
El Ámbito especifica a quién aplica el patrón y puede ser:
- Clases:
Se ocupan de la relaciones entre las clases y subclases. Las relaciones
entre clase se establecen a través de la herencia de modo que son
relaciones estáticas establecidas en tiempo de compilación.
- Objetos:
Se ocupan de las relaciones entre objetos que son relaciones dinámicas y
pueden cambiar en tiempo de ejecución.
En la siguiente tabla podemos ver los patrones
organizados por dos criterios “propósito” y “ámbito”.
| Propósito | ||||
|---|---|---|---|---|
| Creación | Estructura | Comportamiento | ||
| Ámbito | Clase | Factory Method | Adapter (clases) | Interpreter Template Method |
| Objeto | Abstract Factory Builder Prototype Singleton |
Adapter (objetos) Bridge Composite Decorator Facade Flyweight Proxy |
Chain of Responsability Command Iterator Mediator Memento Observer State Strategy Visitor |
|
Propósito de Creación:
Factory
Method (Método de Fabricación)
Define una interfaz para
crear un objeto pero deja que las subclases decidan que clase se instancia.
Permite que una clase delegue en sus subclases la creación de objetos
Abstract
Factory (Fábrica Abstracta)
Proporciona un interfaz
para crear familias de objetos relacionados o que dependen entre sí sin
necesidad de especificar sus clases concretas.
Builder
(Constructor)
Separa la construcción de
un objeto completo de su representación. De este modo el mismo proceso de
construcción puede crear diferentes representaciones.
Prototype
(Prototipo)
Especifica los tipos de
objetos a crear por medio de una instancia prototípica y crea nuevos objetos
haciendo copias del objeto prototipo.
Singleton
(Único)
Garantiza que sólo exista
una instancia de la Clase y proporciona un punto de acceso global a esa
instancia.
Propósito de Estructura:
Adapter (Adaptador)
Convierte la interfaz de
una clase en otra distinta que es la que esperan los clientes. Permite integrar
clases con interfaces incompatibles.
Bridge
(Puente)
Desacopla una abstracción
de su implementación, de manera que ambas puedan variar de forma
independientemente.
Composite
(Compuesto)
Combina objetos en
estructuras de árbol para representar jerarquías. Permite que los clientes
traten de la misma manera a los objetos individuales de los compuestos.
Decorator
(Decorador)
Añade nuevas
responsabilidades a un objeto, proporciona una alternativa flexible a la
herencia para extender funcionalidad.
Facade
(Fachada)
Proporciona una interfaz
unificada para un conjunto de interfaces. Define una interfaz de alto nivel que
hace que el subsistema sea más fácil de usar.
Flyweight
(Peso Ligero)
Usa el comportamiento para
permitir un gran número de objetos pequeños de forma eficiente.
Proxy
(Apoderado)
Proporciona un sustituto o
representante de otro objeto para controlar el acceso a este.
Propósito de Comportamiento:
Interpreter (Intérprete)
Dado un lenguaje, define una representación de su gramática junto con
un intérprete que usa dicha representación para analizar las sentencias del
lenguaje.
Template Method
(Método de plantilla)
Define en una operación el esqueleto de un algoritmo, delegando en las
subclases algunos pasos. Es decir, permite que las subclases redefinan ciertos
pasos del algoritmo sin cambiar la estructura.
Chain of
Responsibility (Cadena de Responsabilidad)
Desacopla el emisor de una petición del receptor. Crea una cadena de
objetos receptores que tienen la posibilidad de responder a la petición y la
petición pasa a través de la cadena hasta que uno de los receptores la trata.
Command (Orden)
Encapsula una petición en un objeto, permitiendo parametrizar a los
clientes con distintas peticiones.
Iterator
(Iterador)
Proporciona un modo de accede secuencialmente a los elementos de un
objeto agregado sin exponer su representación interna.
Mediator
(Mediador)
Define un objeto que encapsula cómo interactúan un conjunto de
objetos. Consigue bajo acoplamiento al evitar que los objetos se refieran unos
a otros explícitamente.
Memento
(Recuerdo)
Representa y externaliza el estado interno de un objeto sin violar la
encapsulación, de forma que éste puede volver a su estado más tarde.
Observer
(Observador)
Define una dependencia de uno a muchos entre objetos, de forma que
cuando un objeto cambie de estado se notifican todos los objetos que dependen
de él.
Strategy
(Estrategia)
Define una familia de algoritmos, encapsula cada uno de ellos y los
hace intercambiables. Permite que un algoritmo cambie independientemente del
cliente que lo usa.
Visitor
(Visitante)
Representa una operación sobre los elementos de una estructura de
objetos. Permite definir una nueva operación sin cambiar las clases de los
elementos sobre los que opera.
Otra posibilidad interesante
para categorizar los patrones, es agruparlos en función de cómo unos patrones
hacen referencia a otros.
Es importante tener
diferentes puntos de vista al pensar en patrones de diseño, de esta manera
lograremos comprender mejor lo que hacen, compararlos entre ellos y elegir cual
resuelve de una manera más eficaz el problema concreto que queremos resolver.
En próximos artículos vamos
a profundizar individualmente en cada patrón.
La dinámica a seguir para
siguientes artículos es tratar un patrón de forma aislada con el suficiente
nivel de detalle para entenderlo.
Para cada patrón
analizaremos los siguientes apartados:
- Propósito
- Motivación
- Estructura
- Participantes
- Consecuencias
- Ejemplos de Código y Funcionalidad
- Patrones Asociados
No hay comentarios:
Publicar un comentario