Programación III I.T.I Sistemas Patrones de diseæofelix/datos/priii/tema7.pdf · TambiØn hay patrones de AnÆlisis, de Arquitectura, de Interfaz de usuario, de diseæo Web,

Universidad de Valladolid

Departamento de Informática

Programación III I.T.I SistemasPatrones de diseño

Félix PrietoCurso 2004/05

Programación III I.T.I Sistemas Patrones 1

Motivación

Disponemos de las técnicas básicas de la Orientación aObjetos, sin embargo. . .

I Encontrar las clases es difícilI Estructurar bien las clases es más difícilI Hacerlo de forma reutilizable es más difícil aún

Necesitamos técnicas y estrategias que nos guien en laconstrucción de buenos sistemas Orientados a Objetos

I Ayudando a construir clasesI Ayudando a estructurar sistemas de clases

Universidad de Valladolid Departamento de Informática c©�FÉLiX


De�niciones

Cada patrón describe un problema que ocurre una y otravez en nuestro entorno y describe también el núcleo desu solución, de forma que puede utilizarse un millón deveces sin hacer dos veces lo mismo (ChristophAlexander, Arquitecto y urbanista)Un patrón de diseño es una descripción de clases yobjetos comunicándose entre si, adaptada para resolverun problema general de diseño en un contexto particular(GoF)Un patrón de diseño es una solución a un problema en uncontexto



Información sobre patrones de diseño

Jean-Marc Jézéquel, Michel Train, Christine MinginsDesign Patterns and contracts. Addison Wesley, 1999http://www.irisa.fr/prive/jezequel/DesignPatterns/

(GoF) Erich Gamma, Richard Helm, Ralph Johnson,John Vlissides Dessign Patterns. Elements of ReusableObject-Oriented Software Addison Wesley, 1995http://hillside.net/patterns/ (Patterns Home Page)http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html

(Introducción muy completa al tema.)



Qué no son los patrones de diseño

Patrones de diseño no es lo mismo queI Bibliotecas de clasesI FrameworksI Assets de grano gruesoI Técnicas y/o herramientas de refactorizaciónI Programación Extrema

También hay patrones de Análisis, de Arquitectura, deInterfaz de usuario, de diseño Web,... incluso hayAntiPatrones



Ventajas de los patrones de diseño

Facilitan la localización de los objetos que formarán elsistemaFacilitan la determinación de la granularidad adecuadaEspeci�can interfaces para las clasesEspeci�can implementaciones (al menos parciales)Facilitan el aprendizaje y la comunicación entreprogramadores



Clasi�cación

Respecto a su propósitoI Creacionales Resuelven problemas relativos a la creación

de objetosI Estructurales Resuelven problemas relativos a la

composición de objetosI de Comportamiento Resuelven problemas relativos a la

interacción entre objetosRespecto a su ámbito

I Clases Relaciones estáticas entre clasesI Objetos Relaciones dinámicas entre objetos



Los patrones del GoF

Clases Objetos

CreacionalMétodoFábrica

Fábrica Abstracta, Cons-tructor, Prototipo, Single-ton

Estructural AdaptadorAdaptador, Puente,Compuesto, Decorador,Fachada, Peso Mosca,Apoderado

Comportamiento

Intérprete,MétodoPlantilla

Cadena deResponsabilidad, Comando,Iterador, Mediador,Memento, Observador,Estado, Estrategia yVisitante



Plantilla general de descripción de un patrón

Nombre ¿Requiere explicación?Intención En dos líneas, qué hace, qué problema resuelve.Alias Otros nombres con que es conocidoMotivación Escenario de ejemploAplicabilidad Cuándo debe ser utilizado y cuándo no.Estructura Diagrama de clases de la solución propuesta.Participantes Diccionario de las clases que participan en la solu-

ción.Colaboraciones Relaciones que se establecen entre las clases an-

teriores.Consecuencias Ventajas e inconvenientes del uso de este patrón.Implementación Técnicas, trucos que se recomiendanPatr. relacionados Utilizados en éste, patrones que lo usan, alterna-

tivas,...



Adaptador (Adapter) (GoF p.131)

Intención: Convierte la interfaz de una clase en otrainterfaz esperada por los clientes. Permite lacooperación de clases que de otro modo seríanincompatiblesMotivación: Necesitamos reutilizar clases ajenas paranuestro sistema, pero, aunque la funcionalidad de estasclases es la que deseamos, la interfaz no es compatible.Si no podemos o no queremos modi�car las clases areutilizar, necesitamos hacerlas compatibles connuestro sistemaObservación: Este patrón tiene dos versiones, una conámbito en clases y otra con ámbito en objetos, peronosotros nos centraremos en la segunda versión




CLIENTE

OBJETIVO+peticion()

ADAPTADOR+peticion()

ADAPTABLE+peticion_incompatible()

mi_adaptado

mi_adaptado.peticion_incompatible()




ParticipantesI OBJETIVO: De�ne la interfaz que espera el clienteI ADAPTABLE: Implementa la interfaz incompatible que

necesitamos adaptarI ADAPTADOR: Implementa la interfaz de OBJETIVO

mediante llamadas al objeto adaptadoColaboraciones

I Los clientes utilizan la interfaz OBJETIVO. Suspeticiones son recogidas por un adaptador que lasredirige al objeto adaptado




ConsecuenciasI Un adaptador puede funcionar con varios adaptables de

forma simultanea, coordinando sus tareasI Si se necesita rede�nir el comportamiento deADAPTABLE basta construir un heredero y hacer que eladaptador lo adapte

I Introduce un nivel de indirección extra para satisfacerlas peticiones del cliente.



Compuesto (Composite) (GoF p.151)

Intención: Componer objetos en jerarquías todo-parte ypermitir a los clientes tratar objetos simples ycompuestos de manera uniformeMotivación: Necesitamos representar un conjunto deelementos de una interfaz grá�ca de usuario (GUI).Algunos de estos elementos son simples, mientras queotros están formados por varios elementos más simples.El comportamiento y/o la información que proporcionaun elemento complejo está determinada por loselementos que lo componen




CLIENTE COMPONENTE+operacion()

HOJA+operacion()

COMPUESTO+operacion()+add()+remove()+iterar(): COMPONENTE

Para todo h hijo hacer h.operacion()

hijo *

*



Compuesto (Composite) (GoF p.151)Participantes

I COMPONENTE: Declara la intefaz común para todos losobjetos de la composición e implementa acciones pordefecto cuando sea apropiado. También puedeproporcionar la interfaz de acceso a hijos y padres

I SIMPLE: Representa los objetos simples e implementa sucomportamiento común

I COMPUESTO: Representa los objetos con hijos,almacenando a éstos e implementando las operaciones deacceso y mantenimiento relacionadas con ellos.

ColaboracionesI Los clientes utilizan la interfaz de COMPONENTEI Los objetos simples contestan directamente, mientras

que los compuestos pueden reenviar la operación a suscomponentes

I Los objetos que construyen la estructura deben serclientes tanto de SIMPLE como de COMPUESTO




ConsecuenciasI Permite el tratamiento uniforme de objetos simples y

complejosI Simpli�ca el código de los clientes, que usan una sola

interfazI Permite añadir componentes nuevas sin afectar a los

clientesI Es difícil restringir los tipos de los hijosI De�nir las operaciones de gestión de los hijos enCOMPONENTE crea problemas de consistencia con loshijos



Comando (Command) (GoF p.215)

Intención: Encapsula una petición en un objeto. Permitecon ello parametrizar a los clientes con diferentespeticiones y almacenar peticiones para deshacerlas encaso necesarioMotivación: Parametrización de las acciones a realizarpor los objetos GUI de un framework (como hace eGTK)




CLIENTE

EMISOR

ORDEN+ejecutar()

RECEPTOR+accion()

ORDEN_CONCRETA+ejecutar()

*

mi_receptormi_receptor.accion()



Comando (Command) (GoF p.215)Participantes

I COMANDO: Declara la intefaz para ejecutar una operaciónI COMANDO_CONCRETO: De�ne una relación entre un

receptor y una acción, rede�niendo la operaciónejecutar para que se envíe una petición adecuada alreceptor

I CLIENTE: Crea un comando concreto indicándole cuál essu receptor

I EMISOR: Pide al comando que lleve a cabo una peticiónI RECEPTOR: Sabe cómo realizar la operación relacionada

con una peticiónColaboraciones

I El cliente crea un comando concreto indicándole cuál essu receptor

I El emisor almacena uno o varios comandos concretosI El emisor solicita al comando que se ejecuteI El comando pide al receptor que realice las operaciones

necesarias




:CLIENTE :COMANDO_CONCRETO :EMISOR :RECEPTOR

crea

almacena

ejecutar

accion




ConsecuenciasI La intermediación de comando desacopla emisor y

receptorI Permite manipular comandos tratados como objetosI Permite añadir nuevos comandos sin alterar las otras

clasesI Aplicando el patrón compuesto podemos obtener

comandos complejos (macros)I Los comandos pueden ser más o menos inteligentes

(solicitar un trabajo al receptor, o realizar tareas máscomplejas)

I Se puede adaptar la infraestructura para la opción«deshacer comando», ya sea de un nivel o de variosniveles (posiblemente eso requiera almacenar el estadoprevio del receptor)



Observador (Observer) (GoF p.269)

Intención: De�nir una dependencia entre un objeto y unconjunto de ellos, de modo que los cambios en el primerose vean re�ejados en los otrosMotivación: En un toolkit de GUI necesitamos separarlos objetos de presentación de los objetos que modelanlos datos interesantes para la aplicación, de forma quese puedan tener varias vistas sincronizadas de losmismos datos




SUJETO inserta() quita() notifica()

OBSERVADOR actualiza()

SUJETO_CONCRETO estado cambia()

OBSERVADOR_CONCRETO estado_observador actualiza()

observador *

sujeto *

Para todo o Observador o.actualiza()

consulta el estadode su sujeto




ParticipantesI SUJETO: Mantiene una lista de observadores y

proporciona una interfaz para su gestiónI OBSERVADOR: De�ne una interfaz para actualizar los

objetos que deben re�ejar los cambios en el sujetoI SUJETO_CONCRETO: Envía una noti�cación a sus

observadores cuando cambia su estadoI OBSERVADOR_CONCRETO: Mantiene una referencia a una

sujeto concreto, almacenando parte de su estado eimplementado la interfaz de OBSERVADOR

ColaboracionesI El SUJETO_CONCRETO noti�ca a sus observadores de los

cambios que sufreI Los observadores concretos solicitan a su sujeto los

datos necesarios para mantener la consistencia con sunuevo estado




:OBSERVADOR_CONCRETO:SUJETO CONCRETO

:OBSERVADOR_CONCRETO

notifica()

cambia()

actualiza()

estado

actualiza()

estado




ConsecuenciasI Permite reutilizar sujetos y observadores por separadoI Permite añadir nuevos observadores sin modi�car al

sujeto o a otros observadoresI Que el sujeto no informe a sus observadores de qué

cambio ha sufrido permite mantener el acoplamiento enun nivel bajo, puesto que el observador sólo pide losdatos del estado del sujeto que le interesan

I Aunque el observador no esté interesado en ciertoscambios del sujeto será noti�cado de ellos

I Se pueden realizar implementaciones con observadoresque coordinan información sobre varios sujetos



Iterador (Iterator) (GoF p.237)

Intención: Permite acceder secuencialmente a loselementos de un agregado sin exponer su estructurainternaMotivación: Necesitamos implementar una estructurade datos «compleja». Deseamos proteger a los clientesde la estructura frente a los detalles de implementaciónde la misma. permitiendo incluso que el cambio de suimplementación no afecte a los clientes.




AGREGADO+crear_iterador()

CLIENTE

ITERADOR+primero()+siguiente()+fin()+actual()

AGREGADO_CONCRETO+crear_iterador()

ITERADOR_CONCRETO+primero()+siguiente()+fin()+actual()




ParticipantesI ITERADOR: De�ne la interfaz común para recorrer todos

los agregados y acceder a ellosI AGREGADO: De�ne la interfaz de creación del iteradorI ITERADOR_CONCRETO: Implementa la interfaz deITERADOR y manteine la posición actual del iterador

I AGREGADO_CONCRETO: Implementa la interfaz decreación de los iteradores

ColaboracionesI El iterador concreto mantiene la información actualizada

sobre el recorrido que se está realizando sobre elagregado




ConsecuenciasI Podemos variar la forma de recorrer el agregado sin más

que cambiar el iterador. Varias formas diferentes derecorrido pueden ser encapsuladas en una jerarquía deiteradores

I La interfaz del agregado resulta más simple alimplementar menos operaciones de recorrido

I Permite el recorrido simultáneo con varios iteradores,utilizando varios algoritmos para el mismo.

I Hay muchas alternativas de implementación: Iteradorinterno o externo, cursor, iterador robusto,...

I La interfaz del iterador puede tener elementosadicionales (anterior, busca)


Documents

Programación III I.T.I Sistemas Patrones de diseæofelix/datos/priii/tema7.pdf · TambiØn hay patrones de AnÆlisis, de Arquitectura, de Interfaz de usuario, de diseæo Web,