PDF de programación - tema 6. Patrones de Diseño

Ingeniería del Software II 2011


Tema 6. Patrones de diseño.

Introducción.

Durante el diseño Orientado a Objetos es frecuente encontrarse repetidamente con ciertos
tipos de problemas, para analizar, compartir y documentar el conocimiento sobre dichos tipos
de problemas se han desarrollado los patrones de diseño.

Dichos patrones también se aplican en otras partes del desarrollo (análisis) y es recomendable
usarlos en cualquier momento para aprovechar el conocimiento y la experiencia existente y no
partir de cero.

Los patrones constituyen la solución base ideal o por lo menos la más recomendable a un
problema concreto.

Definición.

Un patrón es un conjunto de información que proporciona respuesta a un conjunto de
problemas similares. Para ello se aíslan los aspectos comunes y su solución y se añaden
cuantos comentarios y ejemplos sean oportunos.´

Podríamos definir patrón como una solución a un problema en un contexto.

 Contexto. Las situaciones recurrentes.



 Problema. Metas y restricciones en el contexto.



 Solución. Diseño para conseguir las metas dentro de las restricciones.

Los patrones ayudan a capturar conocimiento y a crear un vocabulario técnico, hacen el
diseño orientado a objetos más flexible, elegante y en algunos casos reusable.

Normalmente un patrón se compone de los siguientes elementos:

 Nombre. Una o dos palabras, alto nivel de abstracción para facilitar la asimilación del

funcionamiento del mismo. Estos nombres se incorporan a la memoria y son utilizados
en la comunicación.


 Problema. Describe cuando se debe aplicar el patrón y su contexto.



 Solución. Detalla el mejor diseño disponible.



 Consecuencias. Describe las ventajas y desventajas del mismo.

Los patrones de diseño pueden relacionarse y aplicarse de forma simultánea en muchos casos.



1

Patrones GRASP.

General Responsibility Assignment Software Patterns (GRASP) nos da unos principios
generales para asignar responsabilidades y se utiliza sobre todo en la realización de diagramas
de interacción.

Una vez que tenemos el Modelo de dominio hay que decidir qué métodos añadir y dónde
(parte esencial del desarrollo OO)

Básicamente las responsabilidades de un objeto son conocer y hacer. Dichas
responsabilidades implicarán más o menos métodos y clases.

Principales patrones GRASP:

1. Experto (en Información).
2. Creador.
3. Alta Cohesión.
4. Bajo Acoplamiento.
5. Controlador.

Experto.

Problema:

¿Cuál es el principio más básico para añadir responsabilidades en una clase?

Solución:

Asignar responsabilidades al experto de la información, es decir, a la clase que tiene la
información necesaria para llevar la tarea a cabo.

Consecuencias:

 Encapsulamiento de la información y, por ende, el bajo acoplamiento.



 El comportamiento distribuido entre las clases, es decir, clases más cohesivas.

Ejemplo:



2

Contraindicaciones:

En algunas ocasiones no es una guía deseable sobre todo por problemas de cohesión,
acoplamiento y duplicación de código. (Si venta debe ser almacenada en una base de datos, el
Experto sugiere a Venta como responsable, pues contiene mucha de la información a
almacenar.

Patrones relacionados:

Bajo Acoplamiento y Alta Cohesión.

Creador.

Problema:

¿Quién debe ser responsable en la creación de una nueva instancia de una clase?

Solución:

Una clase B tiene la responsabilidad para crear una instancia de la clase A si:

 B agrega objetos de A.
 B contiene objetos de A.
 B almacena objetos de A.
 B usa objetos de A.
 B tiene los datos necesarios para inicializar a A cuando este es creado.

Consecuencias:

Soporta el bajo acoplamiento, es decir, este no se incrementa.

Ejemplo:

En la aplicación PDV, ¿quién debería crear una LineaDeVenta? Venta de hecho contiene
(agrega) muchos objetos de LIneaDeVenta, debe tener, por lo tanto, la responsabilidad de la
creación de instancias de esta clase y por lo tanto contener un método crearLineaDeVenta.

Contraindicaciones:

A menudo la creación de instancias es una tarea compleja, en estos casos es aconsejable
delegar la creación a una clase auxiliar denominada Factoria.

Patrones relacionados:

Bajo Acoplamiento y Factoría.

Alta Cohesión.

Problema:



3

¿Cómo lograr que la complejidad sea lo más manejable posible? Alta cohesión: lo relacionadas
que están las responsabilidades de una clase, o una clase con responsabilidades altamente
relacionadas y que no lleva a cabo gran cantidad de trabajo.

Solución:

Asignar responsabilidades procurando que la cohesión sea lo más alta posible.

Consecuencias:

 Se incrementa la claridad y facilita la comprensión, se simplifica el mantenimiento.


Implica casi siempre bajo acoplamiento, incrementando la reutilización.



Ejemplo:

Este ejemplo es una contradicción, es decir, el ejemplo va en contra del patrón de Alta
Cohesión.



Patrones relacionados:

Bajo Acoplamiento.

Bajo Acoplamiento.

Problema:

¿Cómo soportar baja dependencia e incrementar la reutilización? Acoplamiento indica que tan
fuertemente está conectada una clase con otra, tiene conocimiento de, o influye sobre otra
clase, una clase con bajo acoplamiento no depende de otras clases.

Solución:

Asignar responsabilidades de tal manera que el acoplamiento sea el menor posible.

Consecuencias:



4

 Mejor compresión de las clases aisladas.



 Facilitan la reutilización de código.



 No afectan los cambios en otros componentes.

Ejemplo:



Patrones relacionados:

Variaciones Protegidas.

Controlador.

Problema:

¿Quién debe manejar eventos del sistema? Un controlador es un objeto responsable del
manejo de los eventos del sistema, que no pertenece a la interfaz del usuario, el controlador
recibe la solicitud del servicio desde la capa GUI y coordina su realización delegando a otros
objetos.

Solución:

Responsabilidades para el manejo de mensajes de eventos del sistema a una clase que:

 Representa al conjunto del sistema o negocio (Controlador Fachada).



 Representa algo del mundo real que está activo (Controlador de Roles).



 Representa un administrador artificioso para todos los eventos del sistema

(Controlador Caso de Uso).

Ejemplo:



5

En el PDV hay varias operaciones del sistema como finalizarVenta(), introducirArticulo() o
introducirArticuloDevuelto().

Siguiendo el patrón Controlador podríamos asignar la responsabilidad de manejar estos
eventos a una clase que represente al sistema como Registro (Controlador Fachada).

O si hay muchos eventos de sistema, también podríamos asignársela a controladores de los
distintos casos de uso como: ProcesarVentaControlador o GestionarDevolucionesControlador.

Si el Registro asume demasiadas responsabilidades pierde la cohesión (el compromiso).

Consecuencias:

 Potencial para reutilizar interfaces conectables.



 Razonamiento sobre el funcionamiento de los casos de uso, es decir, valida la

secuencia de operaciones, capturando información de estado.

Patrones relacionados:

Command, Fachada, Capas, Fabricación Pura.

Más Patrones GRASP.

Más patrones GRASP:

1. Polimorfismo.
2. Fabricación Pura.
3.
4. Variaciones Protegidas.

Indirección.

Polimorfismo.

Problema:

¿Cómo manejar alternativas basadas en el tipo? ¿Cómo crear componentes conectables?

Solución:

Cuando el comportamiento relacionado varía según el tipo (clase) asigne la responsabilidad
para el comportamiento utilizando operaciones polimórficas a los tipos para los que varía el
comportamiento.

 Corolario: Evítense las comprobaciones acerca del tipo de un objeto y procure no

utilizar la lógica condicional.

Consecuencias:

 Se añaden fácilmente extensiones necesarias para nuevas variaciones.



6



Las nuevas implementaciones se introducen sin afectar a los clientes.

Ejemplo:

Patrones relacionados:

Variaciones Protegidas, varios de los patrones de diseño GoF como Adaptador, Command,
Composite, Proxy, Estado y Estrategia.

Fabricación Pura.

Problema:

¿Qué objetos deberían tener la responsabilidad cuando no se quiere violar los objetivos de alta
cohesión y bajo acoplamiento?

Solución:

Asigne un conjunto de responsabilidades altamente cohesivas a una clase artificial que no
representa un concepto del dominio.

Consecuencias:

 Se soporta alta cohesión puesto que las responsabilidades se factorizan en una clase

de grano fino.


 El potencial para reutilizar aumenta.

Ejemplo:

 Se necesita soporte para almacenar la Venta en una base de datos se podría suponer

según el Experto que la propia clase debería tener la responsabilidad.

 La tarea implica un número amplio de operaciones de bases de datos no relacionadas

con las ventas (Baja cohesión).

 Además tiene que acoplarse con el interfaz de la base de datos.



7

 Y por último la tarea de almacenar objetos puede ser necesaria para más objetos.
 Podríamos crear una clase AlmacenamientoPersistente.

Contraindicaciones:

Llevar el principio al extremo.

Patrones relacionados:

Bajo Acoplamiento, Alta Cohesión, los GoF (Adaptador, Command, Estrategia, etc) y
prácticamente el resto de patrones de diseño.

Indirección.

Problema:

¿Dónde asignar una responsabilidad para evitar el acoplamiento directo entre dos objetos?

Solución:

Asigne la responsabilidad a un objeto intermedio que medie entre otros componentes para
que no estén acoplados directamente, el intermediario crea un indirección.

Consecuencias:

 Disminuye el acoplamiento entre componentes.

Ejemplos:

 Muchos de los patrones existentes son especializaciones de Indirección.



 Está relacionado con Variaciones Protegidas, Bajo Acoplamiento, muchos GoF como

Adaptador, Puente, Fachada, Observador y Mediador.

Variaciones Protegidas.

Problema:

¿Cómo diseñar componentes de mane