Patrones de Diseño (I – Introducción)

Uno de mis objetivos para el blog, es el de realizar un monográfico sobre los patrones de diseño: qué son, cuándo usarlos, de dónde vienen y cómo se implementan.

Así que sin más dilación, empiezo con el primero de muchos post. Espero muchas críticas y sobre todo, que os sirva de algo.

¿Qué son los patrones de diseño?

En el contexto del diseño orientado a objetos, son soluciones a problemas de diseño comunes. Para ser patrones, dichas soluciones deben poseer las siguientes características:

  1. Son reusables: para problemas de diseño similares, la solución puede ser usada como solución (de ahí la palabra «patrón»).
  2. Son efectivas: han sido usadas y probadas tantas veces que se puede confiar en la eficacia y robustez de la solución.

Evidentemente, al ser soluciones realizadas una y otra vez con la misma estructura, además del alivio virtual que nos supone que ya existe gente que ha probado el diseño hasta la saciedad, tenemos la ventaja de que parte de esa gente ha agrupado en catálogos patrones para describir en ellos los contextos en los que se pueden usar y cómo usarlos.

Dichos catálogos se pueden clasificar en dos grupos bien diferenciados, los dedicados a los patrones de diseño genéricos y los patrones de diseño específicos de un dominio (como pueden ser, por ejemplo patrones de diseño para el desarrollo de interfaces de usuario).

Para este conjunto de entradas sólo voy a hablar de los patrones definidos por el GoF en su libro “Design Patterns. Elements of Reusable Object-Oriented Software”. Éste engloba los patrones de diseño que aparecen en el «Code Complete» de Steve McConnell, además de añadir unos cuantos propios. Aún así en al bibliografía hay enlaces a otros catálogos de patrones.

En su libro, los Cuatro describían una serie de patrones que a lo largo de su carrera habían detectado como soluciones. Decidieron agrupar el catálogo de patrones en tres conjuntos que representarían su cometido: creación, composición y comportamiento.

Paso a enumerarlos y a dar una pequeña descripción. Desde luego, intentar resumir en una frase lo que significan los patrones es un crimen. Espero que los que sepan no me lapiden (mejor si me ayudan a intentar ofrecer un mejor resumen explicarlo mejor). La idea es que una vez se hayan escrito los artículos, este artículo sirva de referencia.

Patrones de creación

Son solucines a problemas relativos al proceso de creación de objetos. En el libro, los autores definen cinco patrones:

  • Abstract Factory: cómo crear objetos de la misma familia sin especificar directamente las implementaciones.
  • Builder: separa el proceso de creación de un objeto complejo de la representación del objeto en sí. Así podemos usa el mismo proceso de construcción para crear representaciones diferentes.
  • Factory Method: define la interfaz de creación de un objeto, dejando su proceso de creación a la clase que la implementa.
  • Prototype: crea objetos a partir de la clonación de objeto prototipo de la misma clase.
  • Singleton: crea un único objeto de una clase en particular.

Patrones estructurales

Éstos patrones definen cómo estructurar o disponer los objetos ante determinadas situaciones. El el libro se definen siete patrones diferentes:

  • Adapter: «adapta» la interfaz de una clase servidora a una interfaz comprensible para una clase cliente.
  • Bridge: separa de una abstracción respecto a su implementación, de tal forma que pueden ser modificadas si afectarse mutuamente.
  • Composite: cómo componer un objeto de tal forma que sus partes y el todo pertenecen a la misma estructura jerárquica (y por tanto son similares).
  • Decorator: añade funcionalidades o responsabilidades dinámicamente a un objeto.
  • Facade: especifica una única interfaz que engloba las funcionalidades ofrecidas por un conjunto de interfaces.
  • Flyweight: compartición de objetos para minimizar su uso.
  • Proxy: crea un objeto intermediario entre el objeto cliente y servidor de tal forma que podemos controlar el acceso a éste.

Patrones de comportamiento

Definen relaciones entre objetos y cómo éstos se reparten sus responsabilidades entre sí. Se definen once patrones:

  • Chain of Responsibility: una secuencia o cadena de objetos por la que pasa una petición, actuando éstos en consecuencia
  • Command: una forma de actuar ante una petición cuando no conocemos los detalles de ésta ni quién se encarga de actuar sobre ella.
  • Interpreter: definición de una gramática más una forma de interpretarla.
  • Iterator: patrón para recorrer secuencialmente una colección de elementos sin conocer realmente la implementación de dicha colección.
  • Mediator: objeto que encapsula la relación entre un conjunto de objetos evitando que los objetos se relacionen entre sí directamente.
  • Memento: almacena el estado de un objeto en un momento dado.
  • Observer: objeto/s que reaccionan en el momento que el objeto con el que están relacionados cambian de estado.
  • State: cambia el comportamiento de un objeto dependiendo del estado en el que se encuentre.
  • Strategy: define una familia de algoritmos más una interfaz que los encapsula de tal forma el el cliente use el interfaz, independientemente de la implementación de dicho algoritmo.
  • Template Method: método abstracto perteneciente a un algoritmo de una superclase que las subclases deberán implementar.
  • Visitor: o cómo separar un algoritmo de unas estructura sobre la que trabaja.

¿Cuándo, por qué y cómo usarlos?

Esto depende principalmente del contexto del problema y del patrón a usar. Estas preguntas serán resueltas en los sucesivos post dedicados a cada uno de los patrones (además de mejores explicaciones, ejemplos y dibujitos).

Saludos y disfrutad de la semana

Bibliografía

Stakeholders

Según el «Concise Oxford Spanish Dictionary», stakeholder se traduciría como «interesado». Y según Wordreference se podría traducir como «accionista», «parte interesada», «participante» o «inversor».

Existen muchos ámbitos en los que se puede definir stakeholder, pero nos centraremos en la Ingeniería del Software.

En ingeniería del software, el significado es muy similar a los anteriores (personalmente no recomiendo la traducción). Más formalmente podríamos decir que un stakholder es una persona u organización que tiene influencia – directa o indirecta – o se ve influenciado por un proceso software. También son aquellos que tienen interés en el proyecto, o gente u organizaciones que serán afectadas por el sistema o tendrán alguna influencia en los requisitos del sistema.

¿Y esto qué quiere decir exactamente? ¿Mi abuela es un stakeholder? Si usa el sistema, ha ayudado en su desarrollo, lo ha pagado o tiene algo que ver con él, sí lo es. Si está tranquilamente haciendo bolillo en casa, puedes estar tranquilo, no es un stakeholder. Con este chascarrillo, a lo que quiero referirme es que, aunque existen muchas personas que lo son, existen unos límites, todos dentro del ciclo de vida del Software al completo (desde que se idea hasta que se retira).

Los stakeholders más representativos y más fáciles de identificar pueden ser los clientes, los usuarios finales y los desarrolladores. Sin embargo existen muchos otros también relacionados con el software como pueden ser: auditores, accionistas, proveedores, directivos, administradores, etc.

Si pensamos en cualquier software que hayamos desarrollado podremos determinar primero los stakeholders obvios: el equipo de desarrollo (analistas, programadores, equipo de testing, GIP, etc.), usuarios finales (usuarios y administradores) y clientes (que son los que contratan el desarrollo del software).

Si vamos un poco más lejos, existe mucha otra gente que a priori no parecemos relacionar con este grupo, pero que giran también en torno al software. Desde la persona que firma las facturas, hasta el director de la empresa, pasando por los entrevistados en el proceso de toma de requisitos, los auditores, los colegios profesionales o los tipos que despliegan la aplicación en las «salas frías».

Una idea interesante para identificar stakeholders podría ser preguntar a cada stakeholder detectado «¿Con quién más piensa que debería hablar?» (Pressman) e ir añadiéndolos al catálogo de stakeholders.

Los diferentes stakeholders dan distintos puntos de vista sobre un mismo sistema, así que conviene al menos identificarlos y, si es posible, conocer su relaciones con la aplicación y entre ellos mismos.

Bibliografía:
Ingeniería del Software. Ian Sommerville (Google Books)
– Software engineering, a practitioner’s approach. Pressman.

Aunque pongo aquí abajo un link al libro en español, me produce urticaria visual ver «requerimientos» en lugar de «requisitos», entre otras lindezas de las traducciones técnicas…