Asignar responsabilidades

Importancia de las responsabilidades

Comprender las responsabilidades

es clave para un buen diseño
orientado a objetos

– Martin Fowler
Diseño Dirigido por Responsabilidades – RDD
 Una forma de diseñar software, que enfatiza el
modelado de roles, responsabilidades y
colaboraciones de los objetos
 Considera los objetos como entes que
desempeñan roles y tienen responsabilidades
específicas, y colaboran en forma fluida para
implementar alguna funcionalidad
 Principios en RDD
 Maximizar la abstracción
 Ocultar inicialmente distinción entre datos y comportamiento
 Pensar en responsabilidades de objetos, relativas a “saber”,
“hacer” y “decidir”
 Distribuir el comportamiento
 Promover arquitectura basada en delegación de control
 Hacer que objetos sean “inteligentes”, que tengan
comportamiento, que no sean sólo estructuras de datos
 Mantener la flexibilidad
 Diseñar los objetos de tal manera que sus detalles internos
puedan ser cambiados fácilmente cuando se requiera
 Derivar responsabilidades
a partir de casos de uso
 Identificar cosas que nuestro software debe hacer y la
información que se requiere para ello
 Expresarlas como responsabilidades
 Las responsabilidades pueden ser enunciados de alto
nivel, que necesitan descomponerse
 Descomponer enunciados de alto nivel en partes más
pequeñas
 Diseñar mecanismos de control y coordinación
 Contemplar excepciones y su manejo
 Cada responsabilidad del software debe transformarse
en responsabilidades de objetos
 Conceptos en RDD
 Aplicación
 Un conjunto de objetos que interactúan
 Objeto
 La implementación de uno o más roles
 Rol
 Un conjunto de responsabilidades relacionadas
 Responsabilidad
 La obligación de realizar una tarea o conocer alguna
información
 Colaboración
 La interacción entre objetos o roles (o ambos)
 Tipos de responsabilidad
 Saber o conocer, por ejemplo:
 El valor de los datos privados encapsulados
 El estado de los objetos relacionados
 Valores de datos que puede derivar o calcular
 Hacer, por ejemplo:
 Crear un objeto
 Iniciar una acción sobre otro objeto
 Realizar un cálculo
 Realizar una validación
 Decidir, por ejemplo
 Controlar y coordinar actividades de otros objetos
 Sobre las responsabilidades
 Las responsabilidades pueden evaluarse a nivel
de sistema, subsistema, paquete u objeto
 Cada responsabilidad se puede implementar a
través de:
 Un solo objeto que trabaja independientemente
 Una comunidad de objetos que colaboran
 Una responsabilidad es más que una operación
Opciones para cubrir responsabilidades
 El objeto hace el trabajo por sí mismo
 Se puede implementar una responsabilidad a través de uno o
más métodos
 Dividir comportamiento complejo en dos partes (“divide y
vencerás”)
 Una parte donde se definen los pasos principales
 Una o más partes “ayudantes” (“helpers”) que implementan los
pasos
 Delegar parte de la responsabilidad a uno o más objetos
“ayudantes” (“helpers”)
 Solicitarles que hagan parte del trabajo: tomar una decisión o
realizar un servicio
 Solicitarles información relevante (“hacerles preguntas”)
Pautas para asignar responsabilidades
 Mantener el comportamiento con la información
relacionada
 Esto hace que los objetos sean eficientes
 Ningún rol debe ser demasiado grande
 Esto hace que se puedan entender los objetos
 Distribuir el comportamiento
 Esto hace que los objetos sean “inteligentes”
 Mantener la información acerca de una cosa en
un solo lugar
 Esto reduce la complejidad
 Encadenar responsabilidades
 Asignar una responsabilidad lleva a
pensar
 ¿Qué responsabilidades en otros objetos
(clientes) la usarán?
 Cómo se realizará esta responsabilidad
 Sub-responsabilidades asignadas a otros objetos
en la vecindad
Estereotipos para roles de objetos en RDD …
 Poseedor de información
 “Sabe cosas”
 Conoce y proporciona información
 Estructurador
 Mantiene relaciones entre objetos e información
acerca de ellas
 Organiza múltiples objetos similares
 Proveedor de servicios
 “Hace cosas”
 Realiza trabajo por demanda
… Estereotipos para roles de objetos en RDD
 Coordinador
 “Delega el trabajo”
 Reacciona mecánicamente ante los eventos
 Controlador
 “Dirige actividades”
 Toma decisiones y dirige de cerca las acciones de
otros objetos
 Interfaz
 Transforma comandos e información entre distintas
partes del sistema
 Convierte un nivel de abstracción en otro
 Estilos de colaboración …
 Control centralizado
 El controlador toma la mayoría de las
decisiones importantes
 La lógica de control puede tornarse
muy compleja
 El controlador puede hacerse
dependiente de la información
contenida en otros objetos
 Los objetos se pueden acoplar
indirectamente a través de las
acciones del controlador, los cambios
pueden fluir a varios objetos a través
del controlador
 Todo el trabajo “interesante” se realiza
en el controlador, los demás objetos
sólo realizan funciones triviales
 … Estilos de colaboración …
 Control por delegación
 Parte de las decisiones y mucho de
la acción se delega a otros objetos
 El coordinador tiende a trabajar con
menos objetos que en un esquema
de control centralizado
 Los diálogos son de mayor nivel, la
comunicación es más abstracta y
potente
 Los cambios tienden a afectar
menos objetos
 Es más fácil dividir el trabajo de
diseño y construcción entre varias
personas
 Es el estilo preferido
 … Estilos de colaboración
 Control disperso
 Se extiende la toma de decisiones
y la acción en varios objetos que
hacen poco individualmente pero
logran hacer el trabajo
colectivamente
 Puede ocasionar largas cadenas
de mensajes para obtener
información de los objetos que la
poseen
 Dependencias “en duro” entre los
objetos de la cadena de control
puede quebrar la encapsulación
GRASP – General Responsibility
Assignment Software Principles
 GRASP
 Herramienta de aprendizaje dirigida a comprender los
aspectos básicos del diseño orientado a objetos
 Consta de nueve principios a seguir para asignar
responsabilidades a los objetos
 Creador (Creator)
 Experto (Information Expert o Expert)
 Bajo acoplamiento (Low coupling)
 Controlador (Controller)
 Alta cohesión (High cohesion)
 Polimorfismo (Polimorphism)
 Fabricación pura (Pure fabrication)
 Indirecto (Indirection)
 Variaciones protegidas (Protected variations)
 Creador
 Problema
 ¿Quién debe ser responsable de crear a nueva instancia de una
clase?
 Solución
 Asignar a la clase B la responsabilidad de crear una instancia de
la clase A si:
 B contiene a o es una composición de A
 B registra A
 B utiliza cercanamente A
 B tiene los datos de inicialización que serán utilizados para crear A
(B es un Experto en cuanto a crear A)
 Si se tienen varias opciones, usualmente se prefiere la clase que
contiene o es una composición de A
 Experto
 Problema
 ¿Cuál es un principio general para asignar responsabilidades
a los objetos?
 Solución
 Asignar la responsabilidad al experto, el objeto que tiene la
información necesaria para cumplir con la responsabilidad
 Consideraciones
 Este principio produce diseños en los que un objeto de
software se realiza a sí mismo las operaciones que en la
realidad se realizan sobre el elemento al que representa; los
objetos “cobran vida”
 Por ejemplo: calcular el total de una venta
 Bajo acoplamiento
 Problema
 ¿Cómo reducir el impacto del cambio?
 Solución
 Asignar responsabilidades de manera que el acoplamiento
innecesario se mantenga bajo
 Consideraciones
 Utilizar este principio para evaluar diseños existentes o elegir
entre varias alternativas
 Cuando aplicando otros criterios o principios no tenemos una
opción claramente superior, debemos preferir el diseño que
ofrece menor acoplamiento que los demás
 Acoplamiento …
 Acoplamiento es una medida de cuán fuertemente un
elemento (sistemas, subsistemas, paquetes, módulos,
clases, etc.) está conectado a, tiene conocimiento de o
depende de otros
 Un elemento con acoplamiento bajo (o débil) no
depende de muchos otros (“muchos” depende del
contexto)
 El acoplamiento no es un problema en sí mismo; el
problema es el acoplamiento a elementos que presentan
inestabilidad en alguna dimensión (por ejemplo, su
interfaz o su implementación)
 … Acoplamiento …
 Dos módulos o componentes están acoplados si el cambio
en uno de ellos genera cambios en el otro
 Las dependencias cíclicas son las que causan más
problemas
 Puede haber acoplamiento explícito o implícito
 Orígenes de acoplamiento
 Código duplicado en dos objetos (se puede y debe evitar)
 Un objeto accede a un atributo o invoca un método que pertenece a
otro
 Un objeto que está acoplado con otros dos, puede producir
acoplamiento indirecto entre estos últimos
 Se pasa como parámetro para un método de un objeto, una
instancia de otra clase
 Un módulo implementa la interfaz de otro
 … Acoplamiento
 El esfuerzo para disminuir el acoplamiento
incrementando la complejidad del diseño debe
enfocarse en los puntos que realmente
presentan alta inestabilidad o evolución
 Ventajas de bajo acoplamiento
 El impacto de los cambios es menor, su propagación
está controlada
 Es más fácil comprender las responsabilidades de
una clase estudiándola en forma aislada
 Facilita la reutilización
Alto acoplamiento vs. Bajo acoplamiento

Módulo 1 Módulo 3 Módulo 1 Módulo 3

Módulo 2 Módulo 4 Módulo 2 Módulo 4

Comunicación
o dependencia
 Controlador …
 Problema
 ¿Cuál es el primer objeto bajo la capa de
presentación que recibe y coordina o controla una
operación del sistema?
 Solución
 Asignar la responsabilidad a una clase que
represente una de las siguientes opciones:
 Representa a todo el sistema, uno de los subsistemas
principales, un objeto raíz o un dispositivo dentro del cual
está ejecutándose el sistema
 Representa un escenario del caso de uso dentro del cual
ocurre el evento, llamado con frecuencia
<NombreCasodeUso>Controlador
 … Controlador
 Consideraciones
 Usar el mismo Controlador para todos los eventos del
sistema en el mismo escenario de caso de uso
 Los elementos de la capa de presentación no deben
cumplir las tareas asociadas con estos eventos; sólo
deberían recibir los eventos y delegarlos a un
Controlador
 Por lo general un Controlador delega a otros objetos
el trabajo que hay que hacer; sólo coordina o controla
la actividad, no hace mucho trabajo por sí mismo
 Alta cohesión
 Problema
 ¿Cómo mantener los objetos enfocados,
fáciles de comprender y manejables, además
de mostrar Bajo acoplamiento como efecto
colateral?
 Solución
 Asignar las responsabilidades de manera que
la cohesión se mantenga alta
 Utilizar este principio para evaluar alternativas
 Cohesión (funcional)
 Es una medida de cuán fuertemente relacionadas y
enfocadas están las responsabilidades de un elemento
 Un elemento que atiende una sola responsabilidad (lo
hace completamente, lo hace bien y es lo único que
hace), tiene alta cohesión
 Los objetos con baja cohesión hacen muchas cosas no
relacionadas o realizan demasiado trabajo, lo que lleva a
los siguientes problemas:
 Son difíciles de entender
 Son difíciles de reutilizar
 Son difíciles de mantener
 Son frágiles, afectados constantemente por los cambios
 Diseño modular
 Modularidad es la propiedad de un
sistema que se descompone en un
conjunto de módulos cohesivos y
débilmente acoplados
 La cohesión es una propiedad o
característica de un módulo individual
 El acoplamiento es una propiedad de un
conjunto de módulos
 Diseñar contemplando el cambio
 Encapsular lo que varía
 Separar la interfaz de su implementación
 Programar para la interfaz en lugar de la
implementación
 Una interfaz es un conjunto de prototipos (o firmas)
de métodos
 La interfaz de un módulo define sus usos
 Cada clase debe tener sólo una razón (interna)
para cambiar
 Interfaz

La interfaz de un elemento debe ser como la punta de

un iceberg, la mayor parte de éste se mantiene oculta