« Späť

Aprendiendo a leer la documentación de un patrón de diseño : Método factoría

La documentación de los patrones de diseño

Los patrones de diseño se documentan utilizando plantillas formales con unos campos estandarizados. Existen varias plantillas ampliamente aceptadas, aunque todas ellas deben al menos documentar las siguientes partes de un patrón:

- Nombre: describe el problema de diseño.
- El problema: describe cuándo aplicar el patrón.
- La solución: describe los elementos que componen el diseño, sus relaciones, responsabilidades y colaboración.

La plantilla más utilizada es la plantilla GOF que consta de los siguientes campos:

  • Nombre del patrón: Ayuda a recordar la esencia del patrón.
  • Clasificación: Los patrones originalmente definidos por GOF se clasifican en tres categorías "Creacional", "Estructural", "Comportamiento".
  • Propósito / Problema: ¿Qué problema aborda el patrón?
  • También conocido como ... : Otros nombres comunes con los que es conocido el patrón.
  • Motivación: Escenario que ilustra el problema.
  • Aplicabilidad: Situaciones en las que el patrón puede ser utilizado.
  • Estructura: Diagramas UML que representan las clases y objetos en el patrón.
  • Participantes: Clases y/o objetos que participan en el patrón y responsabilidades de cada uno de ellos
  • Colaboraciones: ¿Cómo trabajan en equipo los participantes para llevar a cabo sus responsabilidades?
  • Consecuencias: ¿Cuales son los beneficios y resultados de la aplicación del patrón?
  • Implementación: Detalles a considerar en las implementaciones. Cuestiones específicas de cada lenguaje OO.
  • Código de ejemplo
  • Usos conocidos: Ejemplos del mundo real.
  • Patrones relacionados: Comparación y discusión de patrones relacionados. Escenarios donde puede utilizarse en conjunción con otros patrones.

De todos ellos, los más importantes, en mi opinión, son: "Propósito / Problema" que nos introduce en el problema y el de "Estructura" ya que en él está la documentación más formal y menos sujeta a interpretaciones del patrón: los diagramas UML que nos dicen cómo resolver el problema. Además, en los diagramas UML aparecerán una serie de elementos que tienen que estar documentados en la sección "Participantes". Vamos a centrarnos en un patrón concreto y vamos a intentar entenderlo y aplicarlo en base a su documentación.

El patrón método factoría

Patrón Método factoría - DIagrama de clases - Versión con interfaces

Método factoría - Diagrama de clases - Herencia

Centrémonos en los diagramas de arriba que documentan la estructura de Method Factory. En primer lugar debes ser capaz de identificar qué tipo de diagramas tenemos delante. En este caso son diagramas de clases que documentan la estructura estática (las estructuras que tenemos en tiempo de desarrollo y no de ejecución) de la solución. Su comprensión es indispensable para entender y aplicar correctamente el patrón. ¡¡En este diagrama de clases no nos están mostrando los objetos que tendremos en tiempo de ejecución sino sus clases y las funcionalidades que tienen!!.

Nótese que hemos documentado dos posibles versiones del patrón método factoría (cada una de ellas aparece dentro de un paquete). Ambas son equivalentes desde el punto de vista de diseño, pero difieren en la estrategia de implementación. La versión que aparece en primer lugar prioriza el uso de interfaces sobre el uso de la herencia. Siempre que puedas, utiliza la versión basada en interfaces si estás usando Java (la razón es que Java no tiene herencia múltiple y por tanto aplicar herencia para obligar a un objeto a implementar un método o contrato, el abstracto, limita el uso de este mecanismo para reutilizar implementaciones, algo que es mucho más interesante) . A partir de ahora nos vamos a centrar en esta versión, basada en interfaces.

En segundo lugar vamos a ver qué elementos hay:

- Dos interfaces: ICreador y IProducto. Estas interfaces están definiendo las capacidades o funcionalidades que tendrán los objetos que las realicen. La interfaz "ICreador" modela la capacidad de "saber crear un producto" a través del método denominado "metodoFactoria". Nótese que el tipo devuelto por este método (aparece detrás de los dos puntos) es justamente un "Producto". Por otro lado tenemos la interfaz "Producto" que, aunque no tiene en el diagrama ningún atributo ni operación, debería tener en nuestro sistema todas aquellas que fueran comunes a todos los productos.

- Las clases "CreadorConcreto" y "ProductoConcreto". Son realizaciones de las dos interfaces previamente mencionadas. O lo que es lo mismo, el "CreadorConcreto" es una clase cuyos objetos son capaces de hacer todo lo que dice la interfaz "Creador" que es justamente crear objetos de tipo "Producto". Por su parte "ProductoConcreto" es una clase cuyos objetos pueden ser procesados como "Producto" porque tendrán todas sus operaciones y atributos.

Nuestro objetivo era ser capaces de crear objetos de una manera "aséptica", de tal manera que el cliente no tuviera que conocer los detalles de implementación de dicho objeto ni cómo se inicializa. Los objetos que vamos a crear son los "productos" que propone el patrón método factoría. Y los creadores serán otros objetos cuya única responsabilidad es crear a los productos. De esta forma, podríamos enunciar informalmente el método factoría como ...

"Si tienes que crear objetos y su creación te está generando problemas porque no sabes qué clase instanciar ( no puedes anticipar el tipo de objetos que debes crear ), el proceso de creación es muy complejo y se repite o necesitas conocer la estructura interna del objeto, entonces, delega esta responsabilidad en un objeto especializado y llámalo "Creador". Cada vez que tengas que construir el objeto "producto" tan sólo tendrás que solicitarle al creador que te lo construya".

¿Suena raro, verdad? Pues esto es algo muy habitual en el Diseño Orientado a Objetos: introducir elementos que a priori pueden parecer extraños como el "creador" para obtener diseños de más calidad.

Ejemplo práctico y justificación de la calidad de nuestro diseño cuando se aplica Método Factoría

Vamos a estudiar un caso de aplicación de método factoría. El escenario es el siguiente: "Necesitamos crear un programa principal que actúe como una máquina expededora de bebidas. Según el valor de un entero dispensaremos "Bebida de cola" en el caso de que valga 1, "Bebida de naranja" en el caso 2, "Bebida de limon" en el caso 3. Justo antes de servir el producto al cliente hay que leer la fecha de caducidad que tiene cualquiera de estos productos y cancelar la compra en caso de que el producto esté caducado. ".

El primer diseño: ¡lancémonos a codificar directamente sin pensar!

Inicialmente podríamos hacer algo así:

 

Si nos paramos a reflexionar sobre el diseño inherente que tiene este programa podríamos extraer un diagrama de clases como el que sigue:

 

¿Qué problemas tiene este diseño?

Komentáre
Trackback URL:

comments powered by Disqus