Professional Documents
Culture Documents
Curso 2010-2011
Diseño de responsabilidades
con patrones (GRASP)
ATENCIÓN
ESTE DOCUMENTO ES UN MATERIAL DE APOYO PARA LAS
CLASES DE TEORÍA, NO ESTÁ DISEÑADO COMO MATERIAL DE
ESTUDIO. SI QUIERES USARLO PARA ESTUDIAR DEBES
COMPLEMENTARLO CON LAS EXPLICACIONES DEL PROFESOR
Y/O LA BIBLIOGRAFÍA RECOMENDADA
Índice
Introducción
Bajo Acoplamiento
Controlador
Alta Cohesión
Fabricación Pura
Indirección
Protección de Variaciones
Objetivos del tema
y sus asociaciones.
Cómo los objetos deberían interactuar para dar respuesta a los casos de uso
Register Sale
Design Model ... time
1
isComplete : Boolean
DCD; software endSale() currentSale /total
perspective enterItem(...)
makePayment(...) makeLineItem(...)
Register Sale
UP Domain Model 1 Captures-current-sale 1
conceptual perspective id : Int time : DateTime
GENERALIZACIÓN VS HERENCIA
(p.ej. STL)
Introducción: Del DC de Análisis al DC de Diseño
obligación de un clasificador”.
Obligaciones de un objeto en términos de su comportamiento.
diseño de objetos
Introducción: Tipos de responsabilidades
Hacer:
Hacer algo él mismo (e.g. crear un objeto, realizar un cálculo)
Saber o Conocer:
Conocer sus datos privados (encapsulados).
Software Patterns.
BÁSICOS AVANZADOS
Creador Polimorfismo
Experto (en Información) Fabricación Pura
Bajo Acoplamiento Indirección
Controlador Protección de Variaciones
Alta Cohesión
GRASP: Introducción
Para ilustrar los patrones vamos a suponer que queremos modelar un
monopoly
Dibujad su modelo de dominio (perspectiva conceptual)
Nota: asume dos dados
Nota: comienza modelando el tablero, las casillas, y el acto de hacer una
tirada y mover las piezas por parte de un jugador
Patrones GRASP básicos
Creador
Experto (en información)
Bajo acoplamiento
Controlador
Alta cohesión
GRASP: Creador
crear Casillas?
GRASP: Creador
responsabilidades a objetos?
¡ATENCIÓN!
A veces hay que aplicar el
Information Expert en cascada.
Ejemplo: Casa de apuestas
Dibujad el diagrama de
secuencia e indicad los cambios
en el diagrama de clases.
GRASP: Experto (en información)
Tipos de acoplamiento
instancia Y.
Definición de Interfaces de Métodos: p.ej. un parámetro o una
¿CUÁL ES MEJOR?
GRASP: Bajo acoplamiento
MonopolyGame
playGame() :MonopolyGame
playGame()
:ProcessPlayGameHandler
GRASP: Controlador
GRASP: Controlador
DELEGAN al tipo de
. . .
allocation of system
operations during design,
using several use case
controlador del que
controllers
hablamos aquí.
GRASP: Controlador
Mal diseño
presses button
Player
actionPerformed( actionEvent )
1: playGame()
Domain Layer :Board
Buen diseño
presses button
: Jugador
actionPerformed( actionEvent )
Es el run()
system event message
Interface Layer :MonopolyJFrame de las
prácticas
de POO
1: playGame()
controller
de empezar.
Difíciles de entender.
Difíciles de usar.
Difíciles de mantener.
áreas distintas.
ej.: una clase responsable de hacer de interfaz con una base de datos y con un
servicio web.
funcional.
ej.: una clase responsable de interactuar con una base de datos completa
Regla general:
Discusión Una clase con alta cohesión tiene un número relativamente bajo
de operaciones, con funcionalidad altamente relacionada, y no
hace demasiado trabajo, sino que colabora y delega.
Existen pocos casos que contraindiquen la “Alta cohesión”.
Algunos ejemplos podrían ser:
Agrupar responsabilidades o código en una sola clase o
componente para simplificar el mantenimiento por una sola
persona (cuando el mapeo objeto relacional lo hace un
experto en SQL, pero novato en OO).
Contraindicaciones
Servidor de objetos distribuidos, debido a las impliciaciones
de “overhead” o “performance” asociadas a objetos
remotos y a la comunicación remota. A veces es deseable
crear pocos objetos servidores, menos cohesivos que
ofrezcan una interfaz para muchas operaciones. Esto es
relativo al patrón Interface Remota de Grano grueso.
Clases más fáciles de entender, de usar, de mantener, y menos
Beneficios sensibles al cambio
GRASP: Cohesión vs. acoplamiento
Cohesión y acoplamiento
…
Problemas:
Solución:
PersistentStorage
By Pure Fabrication
insert( Object )
update( Object )
...
GRASP: Fabricación pura
Problemas resueltos:
acoplamiento.
Ejemplo: Cubilete
Problema:
Solución:
Las partes del sistema comunes colaboran con una interfaz estable;
Problema:
Solución:
Encapsulación
Diseñar operaciones de manera que consultan o
modifican, pero no hacen ambas cosas a la vez
Separación Modelo-Vista: objetos del modelo no deberían
conocer objetos de presentación, para promocionar bajo
acoplamiento de otras capas hacia la capa de interfaz
(que es la que más cambia)
Principio de Sustitución de Liskov: Una instancia de una
clase derivada debe ser capaz de tomar el lugar de una
instancia de una clase base. Por ejemplo, si un método
tiene un objeto de una clase como argumento, el mismo
método debe ser capaz de trabajar con una instancia de
una clase derivada.
Principios de diseño motivados por PV
Larman
EJERCICIO