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".
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
Proporciona un interfaz para crear familias de objetos relacionados o que dependen entre sí sin necesidad de especificar sus clases concretas.
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.
Especifica los tipos de objetos a crear por medio de una instancia prototípica y crea nuevos objetos haciendo copias del objeto prototipo.
Garantiza que sólo exista una instancia de la Clase y proporciona un punto de acceso global a esa instancia.
Propósito de Estructura:
Convierte la interfaz de una clase en otra distinta que es la que esperan los clientes. Permite integrar clases con interfaces incompatibles.
Desacopla una abstracción de su implementación, de manera que ambas puedan variar de forma independientemente.
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.
Añade nuevas responsabilidades a un objeto, proporciona una alternativa flexible a la herencia para extender funcionalidad.
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.
Usa el comportamiento para permitir un gran número de objetos pequeños de forma eficiente.
Proporciona un sustituto o representante de otro objeto para controlar el acceso a este.
Propósito de Comportamiento:
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.
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.
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.
Encapsula una petición en un objeto, permitiendo parametrizar a los clientes con distintas peticiones.
Proporciona un modo de accede secuencialmente a los elementos de un objeto agregado sin exponer su representación interna.
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.
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.
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.
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.
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: