PDF de programación - Unidad II Diseño de Solución

Unidad II

Diseño de Solución

Diseño de Objetos con

Responsabilidad

Parte 5

1

Patrones GRASP

Son patrones de principios generales para asignar
responsabilidades

Los primeros cinco patrones son:

Experto en Información (Experto)
Creador
Alta Cohesión
Bajo Acoplamiento
Controlador

2

Patrón: Experto
(Experto en Información)

Problema: ¿Cuál es el principio general para
asignar responsabilidades a los objetos?

Solución: asignar una responsabilidad al experto
en la información, es decir, la clase que tiene la
información necesaria para realizar esa
responsabilidad

3

Patrón: Experto
Ejemplo de Aplicación

Responsabilidad: “Conocer el total de la venta”
1. Iniciar la asignación de responsabilidades

estableciendo claramente la responsabilidad
¿Quién debería ser el responsable de conocer el
total de una venta?

2. Determinar que información se necesita para

determinar el total
1. Conocer todas las instancias de “LineaDeVenta”
2. Sumar los subtotales de cada línea de venta

4

Patrón: Experto
Ejemplo de Aplicación

3. Siguiendo el patrón “Experto en información”
buscar las clases de objetos que contengan la
información necesaria para determinar el total

Observar el Modelo del Dominio o el Modelo de
Diseño

Si hay clases relevantes en el Modelo de Diseño,
observar primero ahí
Sino, observar el Modelo del Dominio

5

Patrón: Experto
Ejemplo de Aplicación

Al iniciar el trabajo de diseño, el Modelo de
Diseño (Diagrama de Clases) es mínimo,
por lo que se buscan los Expertos en
Información en el Modelo del Dominio

6

7

Patrón: Experto
Ejemplo de Aplicación

“Venta” contiene todas sus líneas de venta, por
lo tanto, la clase “Venta” es adecuada para esta
responsabilidad
“Venta” es un experto en información para el
trabajo

8

Patrón: Experto
Ejemplo de Aplicación

4. Agregar una clase de SW al modelo de diseño

con el mismo nombre “Venta”, y se le asigna la
responsabilidad de conocer su total (getTotal)

9

Patrón: Experto
Ejemplo de Aplicación

¿Qué información se necesita para obtener el
subtotal de cada línea de venta?

LineaDeVenta.cantidad
EspecificacionDelProducto.precio

“LineaDeVenta” conoce su cantidad y la
especificación del producto asociada
Siguiendo el patrón “Experto en Información”,
“LineaDeVenta” debería determinar el subtotal

10

Patrón: Experto
Ejemplo de Aplicación

*

En un diagrama de interacción,
“Venta” necesita enviar un
mensaje “getSubtotal” a cada
una de sus líneas de venta y
sumar el resultado

11

Patrón: Experto
Ejemplo de Aplicación

¿Qué información necesita conocer
“LineaDeVenta” para proporcionar el subtotal?

Su cantidad

El precio del producto

“EspecificacionDelProducto” es el Experto en
Información que proporciona su precio

Se le debe enviar un mensaje solicitando su precio

12

Patrón: Experto
Ejemplo de Aplicación

*

13

Patrón: Experto
Ejemplo de Aplicación

Responsabilidad: “Conocer el total de una venta”

Clases de diseño y responsabilidades asignadas al
elaborar el diagrama de interacción

Venta: conocer el total de la venta
LineaDeVenta: conocer el subtotal de la línea de
venta
EspecificacionDelProducto: conocer el precio del
artículo

Principio aplicado: “Experto en Información”

14

Patrón: Creador

Problema: ¿Quién debería ser el responsable de la
creación de una nueva instancia de alguna clase?

Solución: asignar a la clase B la responsabilidad
de crear instancias de la clase A si se cumple uno
o más de los casos siguientes:

B agrega objetos de A
B contiene objetos de A
B registra objetos de A
B utiliza más estrechamente objetos de A

15

Patrón: Creador
Ejemplo de Aplicación

B tiene los datos de inicialización que se pasarán a un
objeto A cuando sea creado (B es un Experto con
respecto a la creación de A)
B es creador de objetos de A

Ejemplo: ¿Quién debería crear una “LineaDeVenta”?

1. Siguiendo el patrón creador, buscar clases que

agregan, contienen, registran, etc.; objetos de la
“LineaDeVenta”

16

Patrón: Creador
Ejemplo de Aplicación

“Venta” contiene (agrega) muchos objetos de
“LineaDeVenta”

17

Patrón: Creador
Ejemplo de Aplicación

2. Diseñar interacciones

18

Patrón: Bajo Acoplamiento

Problema: ¿Cómo soportar bajas dependencias,
bajo impacto del cambio e incremento de la
reutilización?

Solución: Asignar una responsabilidad de manera
que el acoplamiento permanezca bajo

19

Acoplamiento

Concepto
Es una medida de la fuerza con que un elemento está
conectado a, tiene conocimiento de, confía en, otros
elementos
Tipos

Bajo (o débil) acoplamiento no depende de demasiados
otros elementos (clases, subsistemas, sistemas, etc.)
Alto (o fuerte) acoplamiento confía en muchas otras
clases. Problemas que surgen:

• Cambios a clases relacionadas fuerzan cambios locales
• Difíciles de entender de manera aislada
• Difíciles de reutilizar puesto que su uso requiere la

presencia adicional de las clases de las que depende

20

Patrón: Bajo Acoplamiento
Ejemplo de Aplicación

Responsabilidad: “crear una instancia de Pagoy
asociarla con la Venta”
¿Qué clase debería ser la responsable de esto?

Patrón Creador sugiere que sea Registro, ya que
Registroregistra un Pago.

1ª Opción: Registro acopla Pago

21

Patrón: Bajo Acoplamiento
Ejemplo de Aplicación

Asignar a Registrola responsabilidad anterior,
acopla la clase Registrocon el conocimiento de la
clase Pago.

Solución alternativa:

Ambos casos asumen que la Ventadebe acoplarse al
conocimiento del Pago

2ª. Opción, Registrono acopla el conocimiento del

Pago

22

2ª. Opción: Registro no acopla Pago

23

Patrón: Alta Cohesión

Problema: ¿Cómo mantener la complejidad
manejable?

Solución: Asignar una responsabilidad de manera
que la cohesión permanezca alta

Cohesión funcional: es una medida de la fuerza
con la que se relacionan y del grado de
focalización de las responsabilidades de un
elemento

24

Patrón: Alta Cohesión

Clase con Baja Cohesión: hace muchas cosas no
relacionadas, o demasiado trabajo

Clase con Alta Cohesión: tiene responsabilidades
altamente relacionadas, y no hace gran cantidad
de trabajo.

25

Alta Cohesión.
Ejemplo de Aplicación

Responsabilidad: “crear una instancia de
Pagoy asociarla con la Venta”

¿Qué clase debería ser la responsable de
esto?

Patrón Creador sugiere que sea Registro, ya
que Registroregistra un Pago.

26

Alta Cohesión.
Ejemplo de Aplicación

27

Alta Cohesión.
Ejemplo de Aplicación

La asignación de responsabilidad anterior sitúa la
responsabilidad de “realizar un pago” en el Registro

Si el sistema posee 50 operaciones, todas recibidas
por Registro,y hace todo el trabajo relacionada con
cada una, se convertirá en un objeto saturado y sin
cohesión.

Crear pago no hace el Registrocohesivo, pero se
sobrecargará incrementalmente con tareas y llegará
a perder cohesión

28

Alta Cohesión.
Ejemplo de Aplicación

Solución alternativa:

Responsabilidad asignada a la clase Venta
Soporta Alta Cohesión y Bajo Acoplamiento

29

Diferentes grados de
cohesión funcional

Muy baja cohesión:

Una clase es responsable de muchas cosas en áreas
funcionales muy diferentes
Ejemplo: Interfaz_BDR_RPC, responsable de acceso a
DB y administrar las llamadas de procedimiento
remotos

Baja cohesión:

Una clase tienen la responsabilidad de una tarea
compleja en un área funcional
Ejemplo: Interfaz_BDR, implementa muchas métodos
relacionados pero similares

30

Diferentes grados de
cohesión funcional

Alta cohesión:

Una clase tiene una responsabilidad moderada en un
área funcional y colabora con otras clases para llevar a
cabo las tareas
Ejemplo: Interfaz_BDRinteractúa con todas las clases
persistentes

Moderada cohesión:

Una clase tiene responsabilidades ligeras y únicas en
unas pocas áreas diferentes que están lógicamente
relacionadas con el concepto de la clase, pero no entre
ellas
Ejemplo: Compañía, responsable de conocer a sus
empleados y conocer su información financiera

31

Patrón: Controlador

Problema: ¿Quién debe ser el responsable de
gestionar un evento de entrada al sistema?

Nota: Los elementos de la interfaz de usuario,
como por ej. “Ventana”, “Applet”, “Vista”,
“Documento”; no abordan las tareas relacionadas
con los eventos del sistema, sólo reciben los
eventos y los delegan a un Controlador

32

Patrón: Controlador

Solución: Asignar la responsabilidad de recibir o
manejar un mensaje de evento del sistema a una
clase que representa una de las siguientes
opciones:

El sistema global, dispositivo o subsistema (Controlador
de Fachada)
Un escenario de caso de uso en el que tiene lugar el
evento del sistema, se denomina con el nombre del
caso de uso, por ej. “ProcesarVentaManejador”,
(Controlador de sesión o caso de uso)

33

Patrón: Controlador

Controlador: Objeto que no pertenece a la interfaz
de usuario, responsable de recibir o manejar un
evento del sistema.

¿Quién debería ser el responsable de los eventos
de este sistema?

34

Controlador.
Ejemplo de Aplicación

- representa el “sistema”
global, dispositivo o
subsistema

- representa un receptor
o manejador de todos
los eventos del sistema
de un escenario de caso
de uso

Registro, SistemaCDV

ProcesarVentaManejador,
ProcesarVentaSesion

35

Controlador.
Ejemplo de Aplicación

36

Controlador.
Ejemplo de Aplicación

Dos alternativas posibles son:

37

Puede existir
uno o más
controladores

38

Detalle de
métodos/operaciones

39

Controlador Saturado
(demasiadas responsabilidades)

Opciones para evitar un controlador saturado:
1. Agregar más controladores, por ej.:

1. RealizarReservaManejador
2. GestionarHorariosManejador
3. GestionarTarifasManejador

2. Diseñar un controlador que delegue la responsabilidad

de cumplir las tareas a otros objetos

40

Controlador.
Ejemplo de Aplicación

41