Identificación de patrones de diseño

Programación Orientada a Objetos 
Semana 9 

Para esta semana el trabajo a entregar es un texto con diagramas que explique cuáles patrones se aprovechan en nuestro proyecto.

Algunas personas definen un patrón como una solución recurrente para un problema en un contexto. Primero, un contexto es el entorno, situación, o condiciones interrelacionadas dentro de las cuales existe algo. Segundo, un problema es una cuestión insatisfecha, algo que se necesita investigar y resolver. Un problema se puede especificar mediante un conjunto de causas y efectos. Normalmente un problema está restringido al contexto en el que ocurre. Finalmente, la solución se refiere a la respuesta al problema dentro de un contexto que ayuda a resolver las dificultades.

Entonces, si tenemos una solución a un problema en un contexto, ¿Será este un patrón? No necesariamente. También necesitamos asociar la característica de recurrencia con la definición de un patrón. Los patrones deberían comunicar soluciones de diseño a los desarrolladores que los leen y los utilizan. Como puedes ver, aunque el concepto de patrón es bastante simple, definir realmente el término es muy complejo.

Abstracción de patrones

Un patrón describe, con algún nivel de abstracción, una solución experta a un problema. Los patrones solucionan problemas que existen en muchos niveles de abstracción. Hay patrones que describen soluciones para todo, desde el análisis hasta el diseño y desde la arquitectura hasta la implementación.

Identificar un patrón

Se han manejado muchos proyectos J2EE en Sun Java Center, y, con el tiempo, se ha notado que ocurren problemas similares en todos estos proyectos. También se ha visto que han emergido soluciones similares para todos estos problemas. Aunque las estrategias de implementación variaran, las soluciones generales eran bastante similares.

Cuando se ha visto un problema y una solución recurrentes, se ha intentado identificar y documentar sus características usando la plantilla de patrón. También se emprendió el procesamiento de significado de los patrones buscando patrones en soluciones ya implementadas.

Muchas veces, soluciones similares podrían representar un sólo patrón. Cuando se decide cómo formar un patrón, es importante considerar cual es la mejor forma de comunicar la solución. Algunas veces, un nombre independiente mejora la comunicación entre los desarrolladores. Si es así, es mejor considerar la documentación de dos soluciones similares como dos patrones diferentes.

Existen tres categorías de patrones de diseño de acuerdo a su propósito, y son los siguientes:

Creacionales: Inicialización y configuración de objetos.

Estructurales: Separan la interfaz de la implementación. Se ocupan de cómo las clases y objetos se agrupan, para formar estructuras más grandes.

Comportamiento: Más que describir objetos o clases, describen la comunicación entre ellos.

En cuanto a mi proyecto muestro cuales patrones creo que me servirían implementar y les explico el porque creo que me ayudan de alguna forma.

Patrón creacional: Builder

El patrón Builder es usado para permitir la creación de una variedad de objetos complejos desde un objeto fuente, el objeto fuente se compone de una variedad de partes que contribuyen individualmente a la creación de cada objeto complejo a través de un conjunto de llamadas a interfaces comunes de la clase Abstract Builder.

Abstrae el proceso de creación de un objeto complejo, centralizando dicho proceso en un único punto, de tal forma que el mismo proceso de construcción pueda crear representaciones diferentes.

Diagrama de ejemplo:

Algunas ventajas:

• Varia la representación interna de estructuras compleja, respetando la interfaz común.
• Se independiza el código de construcción de la representación.
• Evita el acoplamiento.
• Cada ConcreteBuilder tiene el código especifico para crear y modificar una estructura interna concreta.
• Permite un mayor control en el proceso de creación del objeto.

¿Porqué creo se aplica a mi proyecto?
En mi proyecto cada clase se encarga de crear un objeto diferente, por ejemplo una crea la ventana con ciertas opciones, la clase de registro muestra en un label un cuadro con la información almacenada en los registros guardados, otro crea una gráfica y la inserta en un label que remplazaría al de registros.

Patrón estructural: Composite

El patrón Composite describe un grupo de objetos deben ser tratados de la misma manera que una sola instancia de un objeto. La intención de un compuesto es la de "componer" objetos en estructuras de árbol para representar jerarquías parte-todo. Aplicación del modelo compuesto permite a los clientes tratar objetos individuales y composiciones de manera uniforme

Composite puede ser utilizado cuando los clientes deben pasar por alto la diferencia entre las composiciones de objetos y objetos individuales. Si los programadores encuentran que están utilizando varios objetos de la misma manera, y con frecuencia tienen casi idéntico código para manejar cada uno de ellos, entonces este patrón es una buena opción, es menos complejo en esta situación para tratar primitivos y compuestos como homogéneos.

Diagrama de ejemplo:

Patrón de comportamiento: Mediator

Un Mediator es un patrón de diseño que coordina las relaciones entre sus asociados. Permite la interacción de varios objetos, sin generar acoples fuertes en esas relaciones.

Cuando muchos objetos interactúan con otros objetos, se puede formar una estructura muy compleja, con objetos con muchas conexiones con otros objetos. En un caso extremo cada objeto puede conocer a todos los demás objetos. Para evitar esto el patrón Mediator encapsula el comportamiento de todo un conjunto de objetos en un solo objeto.

Usar el patrón Mediator cuando:
Un conjunto grande de objetos se comunica de una forma bien definida, pero compleja.
Reutilizar un objeto se hace difícil por que se relaciona con muchos objetos.
El comportamiento de muchos objetos que esta distribuido entre varias clases, puede resumirse en una o varias por subclasificación.

¿Porqué se aplica a mi proyecto?
Mi proyecto necesita la interacción entre clases para la creación de los objetos en una ventana, y para evitar sobrecargar el sistema este serviría para esto ya que evitaríamos tener que estar regresando a la clase principal para crear todos los objetos nuevamente, ya que por ejemplo en la clase Gráfica se crea la gráfica pero mi idea es no quitar de vista las opciones de la ventana mostrada anterior a esta.

Diagrama de ejemplo:

Ventajas y desventajas:
Simplifica la comunicación entre objetos: Los objetos que se comunican de la forma "muchos a muchos" puede ser remplazada por una forma "uno a muchos" que es menos compleja y más elegante.
Abstrae como los objetos cooperan: Haciendo a la mediación un concepto independiente y encapsulandolo en un objeto permite enfocar como los objetos interactúan. Esto ayuda a clarificar como los objetos se relacionan en un sistema.
Centraliza el control: El mediador es el que se encarga de comunicar a los colegas, este puede ser muy complejo, difícil de entender y modificar.

Bibliografía:
Patrones de diseño en Java
¿Qué es un patrón de diseño
Builder | Composite | Mediator