Documentos de Académico
Documentos de Profesional
Documentos de Cultura
25
Patrn Experto
Solucin: Asignar una responsabilidad al experto en informacin: la clase que cuenta con la informacin
necesaria para cumplir con la responsabilidad.
Problema: Cul es el principio fundamental en virtud del cual se asignan las responsabilidades en el diseo
orientado a objetos?
Comience asignando las responsabilidades con una definicin clara de ellas.
Ejemplo: Sistema de Punto de Venta, quin debe conocer el total de una venta?
Diagrama de Comunicacin:
VG3DWUyQ([SHUWR
:Venta
t:=total()
1: *obtenerSiguiente()
:DetalleDeVenta
Actor
(from )
2: calcularSubtotal()
dVta :
DetalleDeVenta
:EspecificacionDeProducto
2.1: getPrecio()
Conclusin:
Venta: conoce el total de la venta
DetalleDeVenta: conoce el subtotal de la Lnea de Producto
EspecificacinDeProducto: conoce el precio del producto.
Explicacin:
Expresa la idea que los objetos hacen cosas relacionadas con la informacin que poseen.
Puede haber expertos parciales (ej. DetalleDeVenta), que ayudan para cumplir con una
responsabilidad.
Beneficios:
Se conserva bajo el acoplamiento lo que favorece a tener sistemas robustos y de fcil
mantenimiento.
El comportamiento se distribuye con las clases que cuentan con la informacin requerida
fomentando la creacin de clases sencillas y cohesivas.
Otras formas de designar este patrn: :>
>h
26
Patrn Creador
Solucin: Asignar a la clase B la responsabilidad de crear una instancia de la clase A en uno de los
siguientes casos:
B agrega los objetos de A.
B contiene los objetos de A.
B registra las instancias de los objetos de A.
B utiliza especficamente los objetos de A.
B tiene los datos de inicializacin que sern transmitidos a A cuando sea creado (as B es
un experto respecto de la creacin de A).
Problema: Quin debera ser el responsable de crear una nueva instancia de alguna clase?
Ejemplo: Sistema de Punto de Venta, quin debe crear el detalle de venta?
Diagrama de Comunicacin:
VG3DWUyQ&UHDGRU
1: crearDetalleVenta(cant :int)
:Venta
:DetalleDeVenta
:Actor
Venta
estaTerminada
fecha
hora
crearDetalleVenta(cant :int)
efectuarPago()
estaTerminada()
montoPago()
total()
Conclusin:
Venta: crea el DetalleDeVenta
Explicacin:
Gua la asignacin de responsabilidades relacionadas con la creacin de objetos. El propsito es
encontrar un creador que debemos conectar con el objeto producido, esto soporta el bajo
acoplamiento.
Beneficios:
Da soporte al bajo acoplamiento, lo cual supone menos dependencias respecto al mantenimiento y
mejores oportunidades de reutilizacin. como la clase creada tiende a ser visible al creador (razn
por la cual se la eligi), el acoplamiento no aumenta.
Patrones Conexos:
Bajo Acoplamiento.
Parte- Todo: define los objetos que soportan el encapsulamiento de sus componentes.
27
1.1: crear()
1: efectuarPago()
:Pago
:PuntoDeVenta
:Actor
PuntoDeVenta crea el
pago
1.2: agregarPago(p)
:Venta
VG3DWUyQ%DM R$FRSODPLHQW
1: efectuarPago()
1.1: efectuarPago()
:Pago
:PuntoDeVenta
:Actor
1.2: crear()
:Venta
Conclusin:
Venta: crea el Pago.
Explicacin:
al juzgar sus decisiones de diseo. Las formas comunes de acoplamiento de Tipos a Tipo Y son:
Tipo X posee un atributo que se refiere a una instancia Tipo Y o al propio Tipo Y.
Tipo X tiene un mtodo que referencia una instancia Tipo Y o al propio Tipo Y. Suele incluirse un
parmetro o variable local Tipo Y o el objeto devuelto de un mensaje es una instancia de Tipo Y.
Tipo Y es una interfaz y Tipo X la implementa.
Tipo X es una subclase directa o indirecta de Tipo Y.
El bajo acoplamiento estimula asignar una responsabilidad de modo tal que no incremente el
acoplamiento.
El patrn de Bajo Acoplamiento soporta el diseo de clases ms independientes, que reducen el
impacto de los cambios, y tambin ms reutilizables, que aumenta la oportunidad de mayor
productividad.
Un grado moderado de acoplamiento es normal y necesario si quiere crearse un sistema orientado a
objetos, donde los objetos colaboran entre s.
28
Beneficios:
No se afectan componentes por cambios de otros componentes.
Fciles de entender por separado.
Fciles de Reutilizar.
Patrn Alta Cohesin
Solucin: Asignar una responsabilidad de modo que la cohesin siga siendo alta.
Problema: Cmo mantener la complejidad dentro de lmites manejables?
La cohesin funcional es la medida de cuan enfocadas o relacionadas estn las responsabilidades de una
clase.
Una alta cohesin caracteriza a las clases con responsabilidades muy relacionadas que no realicen un
trabajo enorme. Las clases con baja cohesin presentan los siguientes problemas:
Son difciles de entender.
Son difciles de reutilizar.
Son difciles de conservar.
Son delicadas: las afectan constantemente los cambios.
Las clases con baja cohesin a menudo representan un grado de abstraccin alto o han asumido
responsabilidades que deberan haber delegado en otros objetos.
Ejemplo:
VG3DWUyQ$OWD&RKHVLyQ
:Pago
1.1: crear()
1: efectuarPago()
:PuntoDeVenta
:Actor
PuntoDeVenta crea el
pago
1.2: agregarPago(p)
:Venta
VG3DWUyQ$OWD&RKHVLyQ
1: efectuarPago()
1.1: efectuarPago()
:Pago
:PuntoDeVenta
:Actor
1.2: crear()
:Venta
Conclusin:
Venta: crea el Pago.
Explicacin:
Al igual que el Patrn de Bajo Acoplamiento es un patrn que debe tenerse en cuenta al tomar las
decisiones de diseo. Es un patrn evaluativo que el diseador aplica al valorar sus decisiones.
Una clase de alta cohesin posee un nmero relativamente pequeo de operaciones con una
importante funcionalidad relacionada y poco trabajo por hacer. Colabora con otros objetos para
compartir esfuerzo si la tarea es grande.
Se asemeja al mundo real, si alguien asume demasiada responsabilidad sobre todo la que se debe
29
30
Patrn Controlador
Solucin: Asignar la responsabilidad del manejo de un mensaje de los eventos de un sistema, a una clase
que represente una de las siguientes opciones:
La empresa u organizacin global (controlador de fachada).
Algo en el mundo real que es activo (por ejemplo el papel de una persona) ya que pueda participar
en la tarea (controlador de tareas).
Un manejador artificial de todos los eventos del sistema de un caso de uso, generalmente
DEh de use case).
Utilice la misma clase de controlador con todos los eventos del sistema en el mismo caso de uso.
No utilice clases como: ventana, vista, documento, generalmente las reciben y delegan al controlador.
Problema: Quin debera encargarse de atender un evento del sistema?
Un evento del sistema es un evento de alto nivel generado por el actor externo; se asocia a operaciones
del sistema: que emite en respuesta a los eventos.
Un controlador es un objeto de interfaz no destinada al usuario que se encarga de manejar un evento del
sistema. Define adems el mtodo de su operacin.
Ejemplo: Quin debera manejar los eventos del sistema : terminarVenta(); introducirProducto();
efectuarPago()?
De acuerdo al patrn controlador tenemos estas opciones:
Representa al sistema global o TPDV
Representa la empresa u organizacin o Tienda
Representa algo activo o Cajero
Representa al manejador del caso de Uso o ManejadorVenderProductos
Explicacin:
La mayor parte de los sistemas reciben eventos de entrada externa, que generalmente incluyen
una IGU (Interfaz Grfica de Usuario) operada por una persona, o seales de sensores.
En todos los casos en un diseo orientado a objetos, hay que elegir los controladores que manejen
esos eventos de entrada.
La misma clase debera usarse con todos los eventos de un caso de uso, de modo que podamos
conservar la informacin referente al estado del caso de uso, lo que servir para identificar eventos
fuera de secuencia (ejemplo: efectuar Pago entes de Terminar venta).
Pueden usarse varios controladores en un caso de uso).
Un defecto frecuente es asignar demasiada responsabilidad al controlador, quin debera delegar
la responsabilidad a otros objetos mientras coordina la actividad.
La primera categora de controlador es un Controlador de Fachada, representan al sistema global, son
adecuados cuando el sistema solo tiene unos cuantos eventos o cuando es imposible redirigir los mensajes
a otros controladores.
La categora de manejador artificial de caso de uso, plantea un controlador para cada caso de uso, que es
un concepto artificial no un objeto del dominio, cuyo objetivo es dar soporte al sistema. Cundo usarlo? Si
cualquiera de las otras opciones genera diseos de alto acoplamiento o baja cohesin. Esto ocurre
cuando un controlador empieza a saturarse con demasiadas responsabilidades.
Un controlador de caso de uso es una buena alternativa cuando hay muchos eventos del sistema entre
varios procesos: asigna su manejo a clases individuales controlables, adems que ofrece una base para
reflexionar sobre el estado del proceso actual.
Beneficios:
Mayor potencial de los componentes reusables: garantiza que la empresa o los procesos del dominio
sean manejados por la capa del dominio y no por la de interfaz.
31
Reflexionar sobre el estado de un caso de uso: a veces no es necesario asegurar que las operaciones
ocurran en una cierta secuencia legal o poder saber el estado actual de la actividad y las operaciones
del caso de uso.
Problemas y Soluciones:
Controladores Saturados: un controlador mal diseado presentar baja cohesin, dispersa y con demasiada
responsabilidad, se lo denomina controlador saturado. Entre los signos de saturacin podemos mencionar
los siguientes:
Hay una sola clase controlador que recibe todos los eventos del sistema y stos son excesivos. Tal
situacin suele ocurrir con un controlador de papeles o de fachada.
El controlador realiza l mismo muchas tareas necesarias para cumplir el evento del sistema, sin
delegar el trabajo, lo que suele ser una violacin de los patrones Experto y Alta Cohesin.
Un controlador posee muchos atributos y conserva informacin importante sobre el dominio,
informacin que debera haber sido distribuida entre otros objetos y tambin duplica informacin
en otra parte.
Hay varias formas de resolver el problema de un controlador saturado:
1- Agregar ms controladores: un sistema no necesariamente debe tener uno solamente. Adems del
controlador de fachada, se recomienda los de papeles o de casos de uso.
2- Disee el controlador de modo que delegue fundamentalmente o otros objetos el desempeo de
las responsabilidades de la operacin del sistema.
Advertencia: los controladores de papeles pueden conducir a la obtencin de diseos deficientes si se les
asignan demasiadas responsabilidades, en general no son muy aconsejados para usarlos.
VG3DWUyQ&RQWURODGRU
Capa de
Dominio
Registrar Venta
1: crearDetalleVenta(CUP, cant)
2SULPH%RWyQ
Introducir
Producto
Terminar Venta
Efectuar Pago
:Venta
:Caj ero
Capa de
Presentacin
enIntroducirProducto
PDVApplet
Acoplamiento
inadecuado de la
Capa de Presentacin
con la Capa de
Dominio
32
VG3DWUyQ&RQWURODGRU
Registrar Venta
2SULPH%RWyQ
Introducir Producto
Terminar Venta
Efectuar Pago
:Caj ero
Acoplamiento
adecuado de la
Capa de
Presentacin con la
Capa de Dominio
Capa de
Presentacin
enIntroducirProducto
PDVApplet
1: introducirProducto(cup, cant)
Capa de
Dominio
:PuntoDeVenta
:Venta
Patrn Polimorfismo
Solucin: cuando por el tipo varan las alternativas o comportamientos afines, las responsabilidades del
comportamiento se asignarn, mediante operaciones polimrficas, a los tipos en que el
comportamiento presenta variantes.
Corolario: no utilizar pruebas con el tipo de un objeto, ni utilizar lgica condicional para plantear diversas
alternativas
basadas en el tipo.
33
VG3DWUyQ3ROLPRUILVPR7DUM HWD
:Actor
:PuntoDeVenta
:Venta
1.4: autorizar()
:TarjetaCredito
por Polimorfismo
:PagoTarjeta
:Actor
1: efectuarPagoTarjeta(tcNum, fechaVto)
:PuntoDeVenta
:Venta
por Polimorfismo
1.5
:LicenciaConducir
1.3: crear(numLicConducir)
:Cheque
:PagoCheque
por Creador
1.1; 1.2; 1.3; 1.4
1.4: crear(total)
34
Explicacin:
>
Un diseo basado en asignacin de responsabilidades mediante el polimorfismo puede ser
extendido fcilmente para que realice nuevas variantes.
Cuando vemos los objetos en las relaciones cliente/servidor, los objetos cliente requieren poca o
nula modificacin el introducir un nuevo servidor a condicin de que este soporte las operaciones
polimrficas que espera el cliente.
Beneficios:
Es fcil agregar futuras extensiones que requieren las variaciones imprevistas.
Conocido como o semejante a:
>
E
35
Beneficios:
Alta cohesin
Aumenta el potencial de reuso.
Problemas Posibles:
Puede perderse el espritu de los buenos diseos orientados a objeto que se centran en objetos y no en
funciones pues las clases de fabricacin pura se dividen atendiendo a su funcionalidad. Si se abusa de esto,
terminar en un diseo centrado en procesos que se implementa en un lenguaje orientado a objetos.
Patrones Relacionados:
Bajo Acoplamiento
Alta cohesin
Una fabricacin pura normalmente asume las responsabilidades de la clase del dominio a la cual se
asignaran basndose en el patrn Experto.
Muchos patrones son ejemplo del patrn de Fabricacin Pura.
36
Patrn Indireccin
Solucin: Asignar responsabilidad a un objeto intermedio para que medie entre otros componentes o
servicios y stos no terminen directamente acoplados.
Problema: A quin se asignarn responsabilidades a fin de evitar el acoplamiento directo? De qu
manera desacoplar objetos de modo que se obtenga un bajo acoplamiento y se conserve un alto
potencial de reutilizacin?
Ejemplo:
El ejemplo de fabricacin pura para desacoplar la Venta y los servicios de la base de datos relacional
introduciendo la clase AgenteAlmacenamientoPersistente, es un ejemplo para apoyar la indireccin.
MODEM
Suponga que:
Una aplicacin de terminal situada en el Punto de Venta necesita usar un MODEM para transmitir
solicitudes de pago con tarjeta de crdito.
El sistema operativo tiene una llamada de funcin API de bajo nivel para hacer.
Una clase ServicioDeAutorizacionDeCrdito asume la responsabilidad de hablar con el MODEM.
Si el ServicioDeAutorizacionDeCrdito invoca a la funcin API directamente estar acoplado con la API del
sistema operativo en cuestin. se agrega una clase intermedia MODEM responsable de traducir los
requerimientos de la clase a la API y viceversa.
VG3DWUyQ,QGLUHFFLyQ
1: autorizar(pago)
:ServicioAutorizacionCredito
1.1: marcar(numTelefono)
:Modem
:Actor
Modem
Segn Indireccin
+
+
+
enviar()
marcar()
recibir()
37
38
Venta
PuntoDeVenta
+
+
+
+
efectuarPago()
introducirProducto()
montoPago()
terminarVenta()
1 +
+
+
+
+
estaTerminada
fecha
hora
crearDetalleVenta(int)
efectuarPago()
estaTerminada()
montoPago()
total()
Pago
-
monto
monto()
Una forma de ofrecer el monto de pago (violando el patrn de No hables con extraos)
39
VG3DWURQ1RKDEOHVFRQH[WUDxRVQRVHFXPSOH
1: montoPago(importe)
:PuntoDeVenta
:Venta
1.1: pago(pago)
:Actor
Viola el patrn
1.2: monto(importe)
pago :Pago
pago es un extrao
para PuntoDeVenta
La solucin consiste en agregar una responsabilidad al objeto directo Venta para que devuelva a TPDV el
monto de pago, de modo que la instancia no tenga que hablar con extraos.
VG3DWURQ1RKDEOHVFRQH[WUDxRV
1: montoPago(importe)
:PuntoDeVenta
:Venta
1.1: pago(pago)
:Actor
Soporta el principio
"No hables con
extraos"
1.2: monto(monto)
pago :Pago
Venta
-
estaTerminada
fecha
hora
+
+
+
+
+
crearDetalleVenta(cant)
efectuarPago()
estaTerminada()
montoPago()
total()
Explicacin:
El patrn se refiere a no obtener una visibilidad temporal frente a objetos indirectos que son de
conocimiento de otros objetos pero no del cliente.
La desventaja: la solucin se acopla entonces a la estructura interna de otros objetos. Ello origina
alto acoplamiento, diseo menos robusto y ms propenso a requerir cambios, si se alteran las
relaciones estructurales indirectas.
Violacin de la Ley:
Hay situaciones donde conviene prescindir de la ley, una situacin comn es cuando algn tipo de agente o
te Fabricacin Pura) encargado de devolver otros objetos, basndose en
una consulta mediante el valor de una clave. Se juzga aceptable obtener visibilidad ante un objeto X a
travs de un agente y luego enviarle directamente un mensaje a X aunque eso viole la Ley de Demeter.
40
Beneficios:
Bajo Acoplamiento.
Patrones Relacionados:
Bajo Acoplamiento
Indireccin
Cadena de responsabilidades (GAMMA)
:PuntoDeVenta
1.1: crear()
:Venta
:Actor
1.2: mostrarEspecificacion(cup)
:CatalogoProducto
TPDV
stm StateMachi...
EnEsperaDeVenta
EnIntroduccionv enta
introducirProducto
41
Ejemplo:
Diagrama de Clase
class Patron State
PuntoDeVenta
+
+
+
+
+
+
efectuarPagoCheque()
efectuarPagoEfectivo()
efectuarPagoTarjeta()
introducirProducto()
montoPago()
terminarVenta()
El objeto contexto
tiene un atributo que
designa su estado
PDVEstado
EnEsperaDeVenta
+
introducirProducto()
EnIntroduccionVenta
+
introducirProducto()
Registra el producto
vendido
sd Patron State 1
1.1: introducirProducto(pdv, cup, cant)
1: introducirProducto(cup, cant)
:PDVEstado
:PuntoDeVenta
:Actor
objeto contexto (pdv)
es transmitido para
lograr visibilidad de
parmetro hacia atrs
Para cada caso polimrfico de las concretas (subclases), se debe dibujar un diagrama de comunicacin
diferente, comenzando con el mensaje polimrfico.
En el diagrama de arriba se dibuja la clase abstracta PDVEstado, nicamente a los fines de acortar el
modelado.
El patrn estado comienza con el objeto contexto (TPDV en este caso), enviando un mensaje al objeto
estado asociado.
42
sd Patron State 2
El objeto contexto
puede asociarse con
varios estados
4: establecerEstado(e)
3: registrarVentaProducto(cup, cant)
:EnEsperaDeVenta
1: introducirProducto(cup, cant)
1.1: efectuarVenta()
p1 :PuntoDeVenta
:Actor
2: crear()
1.2: crear()
e :EnIntroduccionVenta
:Venta
1.3: crearDetalleVenta()
1.4: *crear()
:DetalleDeVenta
sd Patron State 3
:EnIntroduccionVenta
1: registrarVentaProducto(cup, cant)
p :PuntoDeVenta
:Actor
Polimorfismo del
Patrn Estado
:Venta
p :PuntoDeVenta
:Actor
1: bucarEspecificacion(cup)
:CatalogoProducto
dv :DetalleDeVenta
:DetalleDeVenta
1.1: *mostrarEspecificacion(cup)
:EspecificacionDeProducto
43
Conclusin:
Este patrn es muy til cuando el comportamiento de un objeto depende de su estado.
Con l se elimina la lgica condicional en los mtodos del objeto contexto y se obtiene un
mecanismo elegante para extender el comportamiento de dicho objeto sin modificarlo.
Si un sistema presenta muchos estados, este patrn puede ser idneo por la proliferacin de
clases. Otra alternativa consiste en definir un intrprete de la mquina de estado que funcione
contra un grupo de reglas de transicin de estados.
Patrn Singleton
Problema: se permite exactamente una instancia de una clase: se trata de un singleton (solitario). Los
objetos necesitan un solo punto de acceso.
Solucin: Definir un mtodo de clase (smalltalk) o una funcin que no sea miembro (en C++) y que
devuelve el singleton.
Ejemplo:
Cuando PagoTarjeta recibe el mensaje autorizar(), necesita enviar un mensaje al objeto TIENDA,
que conoce cual servicio de autorizacin llamar, en funcin de la marca de tarjeta, puesto que
TIENDA es el experto natural.
Pero surge un problema de visibilidad: la instancia recin creada de PagoTarjeta no tiene acceso a
la instancia TIENDA.
Una solucin consiste en transmitirla hacia abajo (como parmetro) desde TPDV (que posee
visibilidad de atributo ante ella) y asignarla a un atributo de PagoTarjeta, para que tambin tenga
visibilidad de atributo frente a ella. Lo anterior es aceptable, pero la opcin es el SINGLETON.
A veces conviene soportar la visibilidad global o un solo punto de acceso a una instancia individual
de una clase y no a alguna forma de visibilidad. Y esto ocurre con la instancia TIENDA
class Analysis Model
Tienda
-
instancia
+ direccin()
+ instancia()
+ nombre()
Mtodo de Clase
Tienda Tienda
instancia()
{
if (instancia == nill)
instancia:= new Tienda
return instancia
}
44
sd Patron Singleton
Por Singleton
Este es un obejto
Clase.
:Actor
autorizar()
:PagoTarjeta
1: tien:= instancia()
Tienda
tien :Tienda
La visibilidad del
objeto Tienda se
consigui mediante el
mtodo instancia()
45
Bibliografa de Referencia
Coad, Peter: OBJECT MODELS, STRATEGIES, PATTERNS & APLICATIONS (Editorial Yourdon Press - Ao 1995).
Historia de Cambios
Fecha
05/08/2004
Versin
1.0
1.1
01/02/2010
02/02/2010
1.2
1.3
Descripcin
Versin Inicial
Se cambian algunos grficos de patrones GRASP
por que tena el actor y no corresponde
Se cambian los grficos a UML 2.0
Se cambia el nombre del diagrama de colaboracin
por el de Diagrama de Comunicacin
Autor
Judith Meles
Judith Meles
Judith Meles
Judith Meles
46