2 14pdoo

Patrones de diseo orientado a objetos
Programacin Orientada a Objetos

Facultad de Informtica
Juan Pavn Mestras
Dep. Ingeniera del Software e Inteligencia Artificial
Universidad Complutense Madrid
Juan Pavn Mestras
Facultad de Informtica UCM, 2004
Patrones de creacin 2
Hacer software no es fcil
Disear software orientado a objetos es difcil, y disear
software orientado a objetos reutilizable es todava ms
difcil
Chapter 1: Introduction. Design Patterns, The Gang of Four
...y un software capaz de evolucionar tiene que
ser reutilizable (al menos para las versiones
futuras)
Juan Pavn Mestras
Disear para el cambio
El software cambia
Para anticiparse a los cambios en los requisitos hay que
disear pensando en qu aspectos pueden cambiar
Los patrones de diseo estn orientados al cambio
Juan Pavn Mestras
Patrones
Cmo llegar a ser un maestro de ajedrez
Primero aprender las reglas del juego
nombres de las piezas, movimientos legales, geometra y orientacin
del tablero, etc.
A continuacin aprender los principios
relativo valor de las piezas, valor estratgico de las casillas
centrales, jaque cruzado, etc.
Sin embargo, para llegar a ser un maestro, hay que estudiar las
partidas de otros maestros
Estas partidas contienen patrones que deben ser entendidos,
memorizados y aplicados repetidamente
Hay cientos de estos patrones
Juan Pavn Mestras
Patrones
Cmo llegar a ser un maestro del software
Primero aprender las reglas
algoritmos, estructuras de datos, lenguajes de programacin, etc.
A continuacin aprender los principios
programacin estructurada, programacin modular, programacin
OO, programacin genrica, etc.
Sin embargo, para llegar a ser un maestro, hay que estudiar los
diseos de otros maestros
Estos diseos contienen patrones que deben ser entendidos,
memorizados y aplicados repetidamente
Hay cientos de estos patrones
Juan Pavn Mestras
Patrones
Christopher Alexander (1977):
Cada patrn describe un problema que ocurre una y otra vez en nuestro
entorno, y describe la esencia de la solucin a ese problema, de tal modo que
pueda utilizarse esta solucin un milln de veces ms, sin siquiera hacerlo de
la misma manera dos veces
Un patrn es:
una solucin a un problema en un contexto particular
recurrente (lo que hace la solucin relevante a otras situaciones)
ensea (permite entender cmo adaptarlo a la variante particular del
problema donde se quiere aplicar)
tiene un nombre para referirse al patrn
Los patrones facilitan la reutilizacin de diseos y arquitecturas
software que han tenido xito
Juan Pavn Mestras
Motivacin de los Patrones
Capturan la experiencia y la hacen accesible a los no
expertos
El conjunto de sus nombres forma un vocabulario que
ayuda a que los desarrolladores se comuniquen mejor
Lenguajes de patrones
Ayudan a la gente a comprender un sistema ms
rpidamente cuando est documentado con los patrones
que usa
Los patrones pueden ser la base de un manual de
ingeniera de software
Si el software se convierte en una ingeniera, las prcticas
exitosas deben ser documentadas sistemticamente y
ampliamente difundidas
Juan Pavn Mestras
Motivacin de los Patrones
Facilitan la reestructuracin de un sistema tanto si fue o
no concebido con patrones en mente
Reutilizacin:
Los patrones de diseo soportan la reutilizacin de
arquitecturas software
Los armazones soportan la reutilizacin del diseo y del
cdigo
El software cambia
Para anticiparse a los cambios en los requisitos hay que
disear pensando en qu aspectos pueden cambiar
Los patrones de diseo estn orientados al cambio
Juan Pavn Mestras
Clasificacin de patrones
Patrones arquitecturales
Expresan un paradigma fundamental para estructurar un
sistema software
Proporcionan un conjunto de subsistemas predefinidos, con
reglas y guas para organizar las relaciones entre ellos
Patrones de diseo
Compuestos de varias unidades arquitecturales ms
pequeas
Describen el esquema bsico para estructurar subsistemas y
componentes
Patrones elementales (idioms)
Especficos de un lenguaje de programacin
Describen cmo implementar componentes particulares de
un patrn
Juan Pavn Mestras
Ejemplos de patrones
Patrones arquitecturales
Jerarqua de capas
Tuberas y filtros
Cliente/Servidor
Maestro-Esclavo
Control centralizado y
distribuido
Patrones de diseo
Proxies
Factoras
Adaptadores
Composicin
Broker
Patrones elementales
(idioms)
Modularidad
Interfaces mnimas
Encapsulacin
Objetos
Acciones y Eventos
Concurrencia
Juan Pavn Mestras
Patrones y Armazones
Los patrones de diseo tienen descripciones ms abstractas que
los armazones
Las descripciones de patrones suelen ser independientes de los
detalles de implementacin o del lenguaje de programacin (salvo
ejemplos usados en su descripcin)
Los armazones estn implementados en un lenguaje de
programacin, y pueden ser ejecutados y reutilizados directamente
Los patrones de diseo son elementos arquitecturales ms
pequeos que los armazones
Un armazn incorpora varios patrones
Los patrones se pueden usar para documentar armazones
Los patrones de diseo estn menos especializados que los
armazones
Los armazones siempre se aplican a un dominio de aplicacin
particular
Juan Pavn Mestras
Armazones (Frameworks)
Caractersticas
Un armazn ofrece un conjunto integrado de funcionalidad
especfica de un dominio
P.ej.: aplicaciones financieras, servicios de telecomunicacin,
sistemas de ventanas, bases de datos, aplicaciones distribuidas,
ncleos de SO
Los armazones invierten el control en ejecucin entre la
aplicacin y el software sobre el que est basada
El armazn determina qu mtodos se invocan en respuesta a
eventos (se reusa el cdigo del cuerpo principal y se escribe el
cdigo al que llama)
Un armazn es una aplicacin medio-acabada
Las aplicaciones completas se desarrollan mediante herencia, e
instanciando componentes parametrizados del armazn
Juan Pavn Mestras
Armazones (Frameworks)
Diferencias con bibliotecas
LGI CA
ESPECFICA
DE LA
APLICACIN
BUCLE DE
EVENTOS
GUI
ADTs
BASE DE
DATOS
MATH
invoca
Arquitectura basada en
biblioteca de clases
BUCLE DE
EVENTOS
GUI
BASE DE DATOS
ADTs
MATH
invoca
LGI CA
ESPECFICA
DE LA
APLICACIN
Arquitectura basada en
armazn
reutilizacin de cdigo reutilizacin de diseo y cdigo
Juan Pavn Mestras
Ejemplo de patrn de diseo
Modelo-Vista-Controlador
Utilizado en Smalltalk [Krasner and Pope, 1988]
Distribucin de responsabilidades
Utilizado en JFC (componentes Swing)
Controlador
Modelo
Vista
aplicacin
visualizacin
en pantalla
objetos de control,
eventos
Juan Pavn Mestras
Descripcin de patrones de diseo
Nombre e intencin del patrn
Referencia al patrn
Incrementa el vocabulario de diseo
Problema y contexto
Cundo aplicar el patrn
Solucin
Estructura: elementos que conforman el diseo, sus relaciones,
responsabilidades y colaboraciones
es una descripcin abstracta de cmo una disposicin de elementos
(clases y objetos) solucionan el problema
Se ilustra con un ejemplo de cdigo
Consecuencias (positivas y negativas)
Necesidades (tiempo, memoria), aspectos de implementacin y
lenguaje de programacin, flexibilidad, extensibilidad, portabilidad
Patrones relacionados
Juan Pavn Mestras
Categoras de patrones de diseo
Patrones de creacin
Tratan de la inicializacin y configuracin de clases y objetos
Patrones estructurales
Tratan de desacoplar interfaz e implementacin de clases y
objetos:
Cmo se componen clases y objetos?
Patrones de comportamiento
Tratan de las interacciones dinmicas entre sociedades de
clases y objetos:
Cmo interaccionan y se distribuyen responsabilidades los
objetos?
Juan Pavn Mestras
Cmo seleccionar un patrn de diseo
Considerar cmo los patrones de diseo solucionan
problemas de diseo
Buscar las intenciones de cada patrn
Estudiar cmo se interrelacionan los patrones
Estudiar patrones de propsito similar
Examinar la causa de un rediseo
Considerar qu debera ser variable en un diseo
Juan Pavn Mestras
Cmo usar un patrn de diseo
1. Leer el patrn una vez para tener una visin general
2. Volver y estudiar la estructura, los participantes y las
colaboraciones
3. Ver un ejemplo concreto codificado del patrn
4. Elegir nombres para los participantes del patrn que
sean significativos en el contexto de la aplicacin
5. Definir las clases
6. Definir nombres especficos de la aplicacin para las
operaciones en el patrn
7. Implementar las operaciones que realizarn las
responsabilidades y colaboraciones del patrn
Patrones de creacin
Juan Pavn Mestras
Patrones de creacin
En Java para crear un objeto se utiliza el operador new
unObjeto=newClaseObjetos();
Una clase Factora puede ocuparse de los detalles de qu
clase de implementacin utilizar para crear un objeto de
un tipo determinado
XY XZ
X
Factoria
creaX()
:X
Selecciona la
implementacin de X
new
Juan Pavn Mestras
Patrones de creacin
Permiten que el sistema sea independiente de cmo se
crean, componen o representan sus objetos
Sistemas ms dependientes de la composicin de objetos
que de la herencia de clases
Se trata de que el comportamiento se defina ms por la
composicin de un conjunto pequeo de comportamientos
fundamentales que por la definicin mediante herencia de todos
los comportamientos posibles
Por tanto, la creacin de objetos es algo ms que instanciar una
clase
Juan Pavn Mestras
Patrones de creacin
Temas recurrentes en los patrones de creacin:
Encapsulan el conocimiento sobre las clases concretas que se
van a utilizar
Ocultan la manera de crear objetos de estas clases y cmo se
juntan
La visin global de los objetos del sistema son sus interfaces
(que pueden definirse como clases abstractas o interfaces)
Se da independencia de
qu se crea
quin lo crea
cmo se crea
cundo se crea
Juan Pavn Mestras
Patrones de creacin
Tipos de patrones de creacin
De clase: usa herencia para variar la clase del objeto creado
Factora abstracta
Factora para construir familias de objetos
Builder
Factora para construir objetos complejos de forma incremental
De objeto: delega la creacin en otro objeto
Mtodo Factora
Interfaz que permite que sean las subclases las que determinen qu clase instanciar
Prototype
Factora para clonar nuevos ejemplares copiando de un prototipo
Singleton
Object Pool
Factora que asegura que slo hay un miembro (singleton) o un conjunto determinado
(object pool) de una clase, y proporciona un punto global de acceso a l
Juan Pavn Mestras
Mtodo Factora
Propsito:
Permite que una clase difiera la instanciacin a las subclases (son
stas las que deciden qu clase instanciar)
Otras denominaciones:
Factory Method
Virtual Constructor
Motivacin
Un armazn utiliza clases abstractas para definir y mantener
relaciones entre objetos
El armazn tambin es responsable de crear esos objetos
En principio el armazn no conoce las clases concretas que se van a definir
en una aplicacin concreta
El mtodo factora es un mtodo abstracto que encapsula el conocimiento
de qu subclase se va a crear y pone este conocimiento fuera del armazn
Juan Pavn Mestras
Mtodo Factora
Documento
Grafico
Documento doc =crearDocumento();
documentos.anadirDocumento(doc);
doc.abrir();
return newDocumentoTextual();
MiProcesadorTextos
crearDocumento()
Documento
Textual
Aplicacion
crearDocumento()
nuevoDocumento()
abrirDocumento()
Documento
abrir()
cerrar()
salvar()
restaurar()
Juan Pavn Mestras
Mtodo Factora
Aplicacin
Cuando una clase no puede anticipar el tipo de objetos que
debe crear
Cuando una clase quiere que sus clases especifiquen los
objetos que deben crear
Cuando una clase delega la responsabilidad a una subclase
de ayuda (entre varias), y se quiere localizar el conocimiento
de qu subclase de ayuda es la delegada
Juan Pavn Mestras
Mtodo Factora
Esquema, participantes y colaboraciones
El Creator deja que sus subclases definan el mtodo factora que
construye y devuelve un objeto del ConcreteProduct apropiado
Interfaz de los
objetos que crea el
mtodo factora
Una clase que
implementa la
interfaz Product
Redefine el mtodo factora
Declara el mtodo factora que
devuelve un objeto de tipo
Product.
Puede definir una
implementacin por defecto
que devuelva un objeto
ConcreteProduct
Juan Pavn Mestras
Mtodo Factora
Consecuencias
Elimina la necesidad de enlazar clases especficas de la
aplicacin en el cdigo
Es ms flexible crear un objeto con un mtodo factora que
directamente
Un mtodo factora puede dar una implementacin por defecto,
por ejemplo, para crear un archivo, mostrar un dilogo que
permita abrir uno ya existente
En este ejemplo el mtodo factora no es abstracto
Conectar jerarquas de clases paralelas
Los mtodos factora pueden ser llamados por los clientes, no
slo por los Creator
Ejemplo: manipuladores de figuras: un tipo de manipulador
con varios mtodos factora para cada tipo de figura
Juan Pavn Mestras
Mtodo Factora
Implementacin
Implementacin de la clase Creator
El mtodo factora es abstracto
El mtodo factora proporciona una implementacin por defecto:
Permite extensibilidad: se pone la creacin de objetos en una
operacin separada por si el usuario quiere cambiarla
Mtodos factora parametrizados
Para crear distintos tipos de objetos
public class Creator {
public Product create(ProductId);
};
Juan Pavn Mestras
Factora Abstracta
Propsito:
Proporcionar una interfaz para crear familias de objetos
relaciones o dependientes, sin especificar sus clases
concretas
Abstract Factory
Kit
Motivacin
Definir una interfaz que soporte diferentes sistemas de
ventanes, p.ej. Motif, Windows, Openview, ...
Juan Pavn Mestras
Factora abstracta: motivacin
Varias apariencias (Look & Feel) para la interfaz grfica:
JAVA L&F Motif L&F Windows L&F
Juan Pavn Mestras
Factora Abstracta
Juan Pavn Mestras
Factora Abstracta
Aplicacin
Para sistemas independientes de cmo se crean, componen y
representan sus productos
Para sistemas que pueden configurarse con una de varias
familias de productos
Para obligar a utilizar juntos objetos de una familia de
productos
Para ofrecer una librera de clases, mostrando slo sus
interfaces y no sus implementaciones
Juan Pavn Mestras
Factora Abstracta
FactoriaConcreta1
CreaProductoA()
CreaProductoB()
FactoriaConcreta2
CreaProductoA()
CreaProductoB()
ProductoA1 ProductoA2
ProductoB1
ProductoB2
FactoriaAbstracta
CreaProductoA()
CreaProductoB()
ProductoAbstractoA
Cliente
ProductoAbstractoB
Juan Pavn Mestras
Factora Abstracta
Consecuencias
Se oculta a los clientes las clases de implementacin
los clientes manipulan los objetos a travs de las interfaces o
clases abstractas
Facilita el intercambio de familias de productos
Al crear una familia completa de objetos con una factora
abstracta, es fcil cambiar toda la familia de una vez
simplemente cambiando la factora concreta
Mejora la consistencia entre productos
El uso de la factora abstracta permite forzar a utilizar un
conjunto de objetos de una misma familia
No es fcil soportar nuevos tipos de productos
Si se tiene que extender la interfaz de la Factora abstracta
Juan Pavn Mestras
Factora Abstracta
Implementacin
Factoras como singletons
En muchas ocasiones basta con una factora concreta por cada familia de
productos
Creacin de productos:
Mtodo factora por cada producto:
La factora abstracta slo define una interfaz para crear productos, y es la
subclase factora concreta la que los crea. sta especificar sus productos
redefiniendo el mtodo factora para cada uno.
Prototipo para cada factora concreta
Se crea la factora concreta inicializada con un objeto prototipo de cada
producto. Los nuevos se crean haciendo clones del prototipo
Definicin de factoras extensibles
Qu ocurre cuando se quiere aadir un nuevo tipo de producto?
Una solucin es aadir un parmetro a las operaciones que crean objetos
para especificar el tipo de objeto que se va a crear. (Slo hara falta una
operacin de creacin que tendra este parmetro)
Esta solucin requiere tambin que el cliente haga narrowing o
dynamic-cast
Juan Pavn Mestras
Aplicacin en Swing
Abstract factory : LookAndFeel
Eleccin de la fbrica concreta : UIManager
Producto abstracto : ComponentUI y sus clases derivadas
(UIDelegate)
Producto concreto : BasicListUI, MetalListUI
Seleccin de apariencia en Swing
private void seleccionarApariencia() {
// Fuerza al sistema a adoptar una apariencia concreta
String laf = UIManager.getSystemLookAndFeelClassName();
try {
UIManager.setLookAndFeel(laf);
}
catch (UnsupportedLookAndFeelException exc)
{System.err.println("Unsupported: " + laf);}
catch (Exception exc)
{System.err.println("Error loading " + laf);}
}
Juan Pavn Mestras
Builder
Propsito:
Permite a un cliente construir un objeto complejo
especificando slo su tipo y contenido, ocultndole todos
los detalles de la construccin del objeto
Juan Pavn Mestras
Builder
Motivacin
Supongamos un editor que quiere convertir un tipo de texto
(p.ej. RTF) a varios formatos de representacin diferentes, y
que puede ser necesario en el futuro definir nuevos tipos de
representacin
El lector de RTF(RTFReader) puede configurarse con una clase de
Conversor de texto (TextConverter) que convierta de RTF a otra
representacin
A medida que el RTFReader lee y analiza el documento, usa el
conversor de texto para realizar la conversin: cada vez que
reconoce un token RTF llama al conversor de texto para
convertirlo
Hay subclases de TextConverter para cada tipo de representacin
El conversor (builder) est separado del lector (director): se
separa el algoritmo para interpretar un formato textual de cmo
se convierte y se representa
Juan Pavn Mestras
Builder
Juan Pavn Mestras
Builder
Aplicacin
Cuando el algoritmo para crear un objeto complejo debe ser
independiente de las partes que constituyen el objeto y cmo
se juntan
Cuando el proceso de construccin debe permitir
representaciones diferentes para el objeto que se est
construyendo
Juan Pavn Mestras
Builder
Esquema y participantes
Interfaz para crear
partes de un
producto
Construye un
obj eto usando la
interfaz de Builder
Construye y j unta
las partes del
producto
Representa el
obj eto complej o
que se est
construyendo
Juan Pavn Mestras
Builder
Colaboraciones
Juan Pavn Mestras
Builder
Consecuencias
Permite variar la representacin interna de un producto
El Builder ofrece una interfaz al Director para construir un
producto y encapsula la representacin interna del producto y
cmo se juntan sus partes.
Si se cambia la representacin interna basta con crear otro
Bulider que respete la interfaz
Separa el cdigo de construccin del de representacin
Las clases que definen la representacin interna del producto no
aparecen en la interfaz del Bulider
Cada ConcreteBuilder contiene el cdigo para crear y juntar una
clase especfica de producto
Distintos Directors pueden usar un mismo ConcreteBuilder
Da mayor control en el proceso de construccin
Permite que el Director controle la construccin de un producto
paso a paso
Slo cuando el producto est acabado lo recupera el director del
builder
Juan Pavn Mestras
Builder
Implementacin y patrones relacionados
El Builder define las operaciones para construir cada parte
El ConcreteBuilder implementa estas operaciones
Con la Factora Abstracta tambin se pueden construir
objetos complejos
Pero el objetivo del patrn Builder es construir paso a paso
El nfasis de la Factora Abstracta es tratar familias de objetos
El objeto construido con el patrn Builder suele ser un
Composite
El Mtodo Factora se puede utilizar por el Builder para
decidir qu clase concreta instanciar para construir el tipo de
objeto deseado
El patrn Visitor permite la creacin de un objeto complejo,
en vez de paso a paso, dando todo de golpe como objeto
visitante
Juan Pavn Mestras
Singleton
Propsito:
Asegurar que una clase slo tiene un ejemplar, y
proporcionar un punto de acceso global a ste
Motivacin
Algunas clases slo necesitan exactamente un ejemplar
Un spooler de impresin en un sistema, aunque haya varias
impresoras
Un slo sistema de archivos
Un slo gestor de ventanas
...
En vez de tener una variable global para acceder a ese
ejemplar nico, la clase se encarga de proporcionar un
mtodo de acceso
Juan Pavn Mestras
Singleton
Aplicacin
Cuando slo puede haber un ejemplar de una clase, y debe
ser accesible a los clientes desde un punto de acceso bien
conocido
Cuando el nico ejemplar pudiera ser extensible por
herencia, y los clientes deberan usar el ejemplar de una
subclase sin modificar su cdigo
Juan Pavn Mestras
Singleton
Los clientes acceden al ejemplar de Singleton nicamente a
travs del mtodo Instance de la clase Singleton
Define un mtodo Instance( )
que permite a los clientes
acceder al ejemplar
Puede ser responsable de
crear su ejemplar nico
Singleton
static ejemplarUnico
datosSingleton
static ejemplar()
operacion()
getDatosSingleton()
return ejemplarUnico
Juan Pavn Mestras
Singleton
Consecuencias
Acceso controlado a un ejemplar nico
Cmo y cuando los clientes pueden acceder al ejemplar
Espacio de nombres reducido
Evita la necesidad de utilizar variables globales
Permite refinar las operaciones y la representacin
Se puede heredar de la clase Singleton para configurar el
ejemplar para una aplicacin concreta
Permite un nmero de ejemplares variable
Es posible tener un conjunto de ejemplares en vez de uno slo:
Object Pool
Ms flexible que las operaciones de clase (static)
Con static no es posible considerar que hubiera ms de un solo
ejemplar
En C++ las funciones static no pueden ser virtuales, y por tanto
las subclases no pueden redefinirlas polimrficamente
Juan Pavn Mestras
Singleton
Implementacin
Definicin de la clase: asegurar que slo hay un ejemplar
classSingleton{
private static Singletonejemplar =null;
public static SingletongetEjemplar() {
if ( ejemplar ==null )
ejemplar =newSingleton();
returnejemplar;
}
protected Singleton() {
// lo que sea necesario
}
public voidmetodo() {...}
}
Juan Pavn Mestras
Singleton
Implementacin
Utilizacin:
Singleton instance = Singleton.getEjemplar();
//
instance.metodo();
Herencia de la clase Singleton
Cmo determinar en instance() qu subclase utilizar?
Usando variables de entorno
Poner la implementacin de instance() en las subclases
Usando un registro de singletons
Juan Pavn Mestras
Discusin
Hay dos maneras de parametrizar un sistema por las
clases de objetos que crea:
Usando una subclase de la clase que crea los objetos:
Mtodo Factora
Requiere una nueva subclase por cada nuevo tipo de producto
Mediante composicin de objetos: un objeto es el
responsable de conocer la clase de los objetos de producto:
Factora Abstracta, que puede producir objetos de varias clases
Builder, que puede construir un producto complejo paso a paso
Prototipo, construye un producto copia de otro prototipo
Son ms flexibles que el Mtodo Factora pero ms complejos de
implementar
Juan Pavn Mestras
Lo fundamental son las relaciones de uso entre objetos
Se trata de conseguir que cambios en los requisitos de la
aplicacin no ocasionen cambios en las relaciones entre
los objetos
Las relaciones de uso estn determinadas por las
interfaces que soportan los objetos
Juan Pavn Mestras
Tipos de patrones estructurales
De clase: usa herencia para componer interfaces o
implementaciones
Herencia mltiple: una clase que hereda de otras combina sus
propiedades
Class Adapter
De objeto: composicin de objetos en tiempo de ejecucin
Object Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Proxy
Juan Pavn Mestras
Adaptador
Propsito:
Convertir la interfaz de una clase en otra que esperan los
clientes
Class Adapter y Object Adapter
Wrapper (Envolvente)
Motivacin
Para reutilizar una clase de una biblioteca aunque su interfaz
no correspondiera exactamente con el que requiere una
aplicacin concreta
En el ejemplo, la clase TextView
Para aadir funcionalidad que la clase reutilizada no
proporciona
En el ejemplo, la operacin CreateManipulator()
Juan Pavn Mestras
Adaptador
La clase TextShape adapta TextView a la interfaz Shape, de
manera que el editor grfico DrawingEditor puede reutilizar la
clase TextView, que de otra manera sera incompatible.
TextShape se puede hacer de dos maneras:
1) Heredando la interfaz Shape y la clase TextView (Adaptador de
clases)
2) Componiendo un objeto TextView en un TextShape, que se
implementa utilizando el objeto TextView (Adaptador de objeto)
Juan Pavn Mestras
Adaptador
Aplicacin
Para usar una clase existente cuya interfaz no se
corresponde con el que se necesita
Para crear una clase reutilizable que coopera con clases
imprevistas (esto es, que no tienen necesariamente
interfaces compatibles)
El adaptador de objeto slo: para utilizar varias subclases
existentes para las que sera poco prctico adaptar su
interfaz heredando de cada una. Un adaptador de objeto
puede adaptar la interfaz de su clase padre
Juan Pavn Mestras
Adaptador
Esquema, participantes y colaboraciones (Adaptador de clase Adaptador de clase)
Los clientes llaman a las operaciones de un objeto Adaptador.
A su vez, el Adaptador llama a las operaciones heredadas de la clase
Adaptada que tratan la peticin
Define una
interfaz existente
que necesita
adaptacin
Adapta la
interfaz de
Adapteea la
interfaz Target
Define la interfaz
especfica al
dominio que
utiliza el cliente
Juan Pavn Mestras
Adaptador
Esquema, participantes y colaboraciones (Adaptador de objeto Adaptador de objeto)
Los clientes llaman a las operaciones de un objeto Adaptador.
A su vez, el Adaptador llama a las operaciones del Adaptado que
tratan la peticin
Define una
interfaz existente
que necesita
adaptacin
Adapta la
interfaz de
Adapteea la
interfaz Target
Define la interfaz
especfica al
dominio que
utiliza el cliente
Juan Pavn Mestras
Adaptador
Consecuencias
Un adaptador de clase:
Adapta una clase Adaptada a una interfaz Objetivo reutilizando los
mtodos de la clase Adaptada. Por tanto, no funcionar cuando se quieran
adaptar la clase adaptada y todas sus subclases
La clase adaptadora puede redefinir algunos de los mtodos de la clase
adaptada
Slo se introduce un objeto, y no hace falta delegar en otro adaptado
Un adaptador de objeto:
Permite trabajar un slo adaptador con muchos adaptados (esto es, de la
clase adaptada y sus subclases)
Se puede aadir funcionalidad a todos los adaptados de una vez
Es ms difcil si se necesita redefinir el comportamiento del adaptado
Cuanta adaptacin hace un adaptador?
Desde cambiar el nombre de los mtodos hasta aadir nuevas operaciones
Juan Pavn Mestras
Bridge
Propsito:
Desacopla una abstraccin de su implementacin de manera que
las dos puedan evolucionar independientemente
Handle/Body
Motivacin
La herencia permite que una abstraccin tenga varias
implementaciones: esta relacin se define en tiempo de
compilacin
Hay casos en los que puede haber una gran jerarqua de clases de
una abstraccin (p.ej. Window, IconWindow, TransientWindow) y
varias jerarquas de implementacin (en diferentes plataformas)
Es necesario desacoplar la abstraccin de la implementacin
Juan Pavn Mestras
Bridge
Juan Pavn Mestras
Bridge
Aplicacin
Para evitar una vinculacin permanente entre una abstraccin y su
implementacin
Permite cambiar la implementacin en tiempo de ejecucin
Cuando tanto las abstracciones como las implementaciones podran
ser susceptibles de extensin mediante subclases
El patrn Bridge permite combinar las abstracciones e implementaciones y
extenderlas independientemente
Permite adems reducir la proliferacin de clases (ver ejemplo de
motivacin)
Para que cambios en la implementacin de una abstraccin no hagan
recompilar el cdigo de los clientes
En C++ es ms crtico porque la representacin de una clase es visible en
su definicin
Para compartir una implementacin entre mltiples objetos, sin que
lo noten los clientes
Juan Pavn Mestras
Bridge
La Abstraccin pasa las peticiones del cliente al objeto Implementor
Define la interfaz
de las clases de
implementacin,
que no se tiene
que corresponder
con la de
Abstraction
Extiende la interfaz
Abstraction
Define la interfaz
de abstraccin y
mantiene una
referencia al objeto
Implementor
Juan Pavn Mestras
Bridge
Consecuencias
Se desacopla interfaz e implementacin
La implementacin no est vinculada permanentemente a la
interfaz, y se puede determinar en tiempo de ejecucin (incluso
cambiar)
Se eliminan dependencias de compilacin
Se consigue una arquitectura ms estructurada en niveles
Se mejora la extensibilidad
Las jerarquas de abstraccin y de implementacin pueden
evolucionar independientemente
Se esconden detalles de implementacin a los clientes
Juan Pavn Mestras
Bridge
Una sola clase de implementacin
En este caso no es necesario salvo casos donde no se quiere tener que
recompilar el cliente ante cambios de la implementacin (en C++ slo
habra que volver a linkar)
Creacin del objeto de implementacin apropiado
Cmo, cundo y dnde se decide qu clase de implementacin
instanciar?
La Factora Abstracta permite crear y configurar un Bridge particular (y
esta factora puede ser un Singleton): ver ejemplo de cdigo en el GoF
Compartir objetos de implementacin
El patrn Adaptador tiene tambin el objetivo de hacer trabajar
juntas clases con distinta interfaz, pero en general se aplica a
sistemas que ya existen. El patrn Bridge suele aplicarse al
empezar un diseo, para permitir que las abstracciones e
implementaciones evolucionen independientemente
Juan Pavn Mestras
Proxy
Propsito:
Es un sustituto de otro objeto, para controlar el acceso a l
Surrogate
Virtual proxy
Motivacin
Puede haber ocasiones en que se desee posponer el coste de
la creacin de un objeto hasta que sea necesario usarlo
Al abrir un documento, postergar el crear una imagen hasta que
se tenga que visualizar
En programas de comunicaciones, para un objeto remoto
El objeto proxy acta en lugar del verdadero objeto, y ofrece
las misma interfaz, y las solicita en el objeto cuando es
necesario
Por ejemplo cuando el editor del documento invoca la operacin
Draw en la imagen para visualizarla
Juan Pavn Mestras
Proxy
Juan Pavn Mestras
Proxy
Aplicacin: cuando es necesario una referencia a un objeto
ms sofisticada que el simple puntero o referencia a
objeto
Proxy remoto, cuando el objeto est en otro espacio de
memoria (proceso)
Stubs en RPC y CORBA
Proxy virtual, para postergar la creacin de objetos caros
hasta el momento en que se necesitan
Imgenes en documentos
Proxy de proteccin, para controlar el acceso al objeto
original
Controla derechos de acceso diferentes
Referencias inteligentes, remplazan a una referencia o
puntero para realizar alguna accin adicional:
Contar el nmero de referencias a un objeto para liberarlo
cuando nadie lo usa
Cargar un objeto persistente en memoria cuando se referencia
por primera vez
Sincronizar el acceso a un objeto con un cerrojo
Juan Pavn Mestras
Proxy
El Proxy pasa las peticiones al RealSubject cuando sea apropiado,
dependiendo del tipo de proxy
Mantiene una referencia al sujeto
real y proporciona la misma interfaz
Controla el acceso al sujeto real y
puede ser responsable de crearlo y
destruirlo
Define la intefaz
comn al Sujeto
Real y al Proxy
Define el objeto
real que
representa el
proxy
Juan Pavn Mestras
Proxy
Consecuencias
Introduce un nivel de indireccin al acceder a un objeto
Este nivel de indireccin tiene usos distintos dependiendo del tipo
de proxy:
Un proxy remoto puede ocultar dnde est el objeto real
Un proxy virtual puede mejorar la eficiencia por ejemplo al crear
un objeto bajo demanda
Tanto los proxies de proteccin como las referencias inteligentes
realizan tareas de gestin interna cuando se accede al objeto
Permite implementar de manera eficiente copy-on-write
Un objeto costoso slo se copia si se ha modificado
Juan Pavn Mestras
Proxy
Un Proxy no tiene que conocer el tipo de un sujeto real
Puede acceder a l a travs de la interfaz abstracta
Se pueden utilizar facilidades de los lenguajes para
implementarlo:
En C++ se puede sobrecargar el operador de acceso a un
miembro (->). As cuando se accede a un miembro se pueden
hacer acciones adicionales
Esto es vlido slo cuando no es necesario distinguir el tipo de
operacin que se accede en el objeto
El patrn Proxy se puede ver como un caso particular de
Bridge:
un Proxy slo tiene una implementacin, y un Bridge puede tener
ms de una
un Proxy se suele usar para controlar el acceso a su
implementacin, el Bridge permite cambiar una implementacin
dinmicamente
Juan Pavn Mestras
Proxy
El Adaptador proporciona una interfaz diferente al objeto que
adapta, pero el proxy tiene la misma interfaz
Aunque el proxy puede rehusar realizar una operacin (as su
interfaz puede verse como un subconjunto)
El Decorador se puede implementar de manera similar al
Proxy pero el propsito es diferente: el decorador aade
responsabilidades a un objeto, el proxy slo controla su
acceso
Juan Pavn Mestras
Composite
Propsito:
Construir objetos complejos mediante la composicin
recursiva de objetos similares de manera similar a un rbol
Motivacin
Las aplicaciones grficas tienen componentes que pueden
agruparse para formar componentes mayores (contenedores)
Juan Pavn Mestras
Composite
Juan Pavn Mestras
Composite
Aplicacin
Para representar jerarquas de objetos parte-todo
Para que los clientes puedan manejar indistintamente objetos
individuales o composiciones de objetos
Los clientes tratan todos los objetos en la estructura composite
de manera uniforme
Juan Pavn Mestras
Composite
Los clientes usan la clase Componente para interaccionar con los
objetos de la estructura composite. Si el recipiente es una Hoja la
peticin se maneja directamente. Si se trata de un Composite, se
pasa a sus componentes hijos, pudindose realizar operaciones
adicionales antes o despus
Guarda sus hijos
Implementa operaciones
sobre los hijos de la interfaz
Component
Las hojas definen el
comportamiento de los
objetos primitivos
Manipula los
objetos de la
composicin a
travs de la interfaz
Component
Interfaz de los objetos de la
composicin
Implementa el
comportamiento por defecto
Juan Pavn Mestras
Composite
Consecuencias
Define jerarquas de clases que tienen objetos primitivos y
objetos compuestos (composite)
La composicin puede ser recursiva
Hace el cliente simple
Puede tratar la estructura y los objetos individuales
uniformemente
Facilita la adicin de nuevas clases de componentes
Puede hacer que el diseo sea demasiado general
Hace ms difcil restringir los componentes de un composite
Si se quiere hacer que un composite slo tenga ciertos
componentes hay que codificar las comprobaciones para que se
realicen en tiempo de ejecucin
Juan Pavn Mestras
Composite
Referencias explcitas al padre
Comparticin de componentes
Maximizar la interfaz Component
Operaciones de gestin de hijos
Debe implementar Component una lista de Components?
Orden de los hijos
Mejora de la eficiencia con caching
Quin debe eliminar los componentes?
Cul es la mejor estructura de datos para almacenar los
componentes?
Los Iteradores se pueden usar para recorrer composites
El Visitor localiza operaciones y comportamiento que de otra
manera se distribuira entre las hojas y el composite
Juan Pavn Mestras
Decorador
Propsito:
Asignar nuevas responsabilidades a un objeto
dinmicamente. Es una alternativa a la creacin de subclases
por herencia
Decorator
Wrapper
Motivacin
Para aadir nuevas responsabilidades a objetos individuales y
no a toda la clase
Por ejemplo, una ventana de una interfaz grfica puede tener
bordes, scrolling, u otros artifactos
Esto se puede hacer dinmicamente
Juan Pavn Mestras
Decorador
Juan Pavn Mestras
Decorador
Aplicacin
Para asignar responsabilidades a objetos individuales de
forma dinmica y transparente, sin afectar a otros objetos
Para responsabilidades que pueden ser suprimidas
Cuando no es prctico utilizar herencia de clases (porque se
producira una explosin del nmero de clases, o porque no
se tiene la definicin de la clase)
Juan Pavn Mestras
Decorador
El Decorador enva las peticiones a su objeto Componente, y puede
realizar alguna operacin adicional antes o despus
Aade responsabilidades al
componente
Define la interfaz
de los objetos a los
que se les pueden
asignar nuevas
responsabilidades
Mantiene una referencia al
objeto Componente y define
una interfaz conforme
Juan Pavn Mestras
Decorador
Consecuencias
Ms flexibilidad que la herencia de clases (esttica)
Las responsabilidades se aaden y quitan dinmicamente (en
tiempo de ejecucin)
Evita la explosin de clases
Permiten aadir una propiedad ms de una vez
Por ejemplo, aadir doble borde a una ventana
Se puede definir una clase sencilla y aadirle nuevas
caractersticas mediante decoradores, pudiendo as obtener
gran funcionalidad combinando piezas sencillas
Slo se incorpora lo que se usa
Muchos componentes pequeos
Al usar Decoradores, el sistema tiene muchos objetos pequeos
Puede ser difcil de entender y depurar
Juan Pavn Mestras
Decorador
Conformidad de interfaces
La interfaz de un objeto decorador debe ser conforme con la del
componente que decora, por tanto un objeto decorador concreto
debe heredar de una clase comn
Omisin de la clase abstracta Decorador
Si slo se va a definir una nueva responsabilidad no hace falta
definir la clase abstracta Decorador
Las clases Componente deben ser ligeras
La definicin de los datos internos de la clase se debe dejar a las
implementaciones
Decorador vs. Strategy: el Decorador puede actuar antes o
despus de llamar a los mtodos de otro objeto, para
cambiar lo que se hace en medio de la llamada a un mtodo
se usa el patrn Strategy
Es distinto del Adaptador ya que slo aade
responsabilidades a un objeto, no su interfaz
Puede verse como un caso degenerado de Composite con un
solo componente. Sin embargo, el decorador aade
responsabilidades
Juan Pavn Mestras
Fachada
Propsito:
Simplifica el acceso a un conjunto de objetos proporcionando uno
que todos los clientes pueden usar para comunicarse con el conjunto
Faade
Motivacin
Minimizar las comunicaciones y dependencias entre subsistemas
Juan Pavn Mestras
Fachada
El subsistema de compilacin ofrece scanner, parser, ... a travs de una
interfaz unificada (la fachada) de la funcionalidad del compilador, sin
ocultar completamente las clases que lo implementan
Juan Pavn Mestras
Fachada
Aplicacin
Para proporcionar una interfaz sencilla a un subsistema
complejo
A medida que un subsistema evoluciona va teniendo ms clases,
ms pequeas, ms flexibles y configurables
Hay clientes que no necesitan tanta flexibilidad y que quieren
una visin ms simple del subsistema
Slo los clientes que necesiten detalles de ms bajo nivel
accedern a las clases detrs de la fachada
Cuando hay muchas dependencias entre los clientes y las
clases de implementacin de una abstraccin
La fachada desacopla el subsistema de los clientes y de otros
subsistemas
Esto mejora la independencia de subsistemas y la portabilidad
Para estructurar un sistema en capas
La fachada define el punto de entrada de cada nivel
Se pueden simplificar las dependencias obligando a los
subsistemas a comunicarse nicamente a travs de sus fachadas
Juan Pavn Mestras
Fachada
Los clientes se comunican con el subsistema haciendo peticiones a
la Fachada, que las enva a los objetos del subsistema apropiados
(la fachada podra tambin traducir su interfaz a la de las interfaces
del subsistema)
Los clientes que usan la fachada no tienen que acceder a los
objetos del subsistema directamente
Conoce los objetos del subsistema
responsables para cada peticin, y
delega en ellos las peticiones de
los clientes
Implementan la
funcionalidad
del subsistema.
No tienen
conocimiento de
la fachada
Juan Pavn Mestras
Fachada
Consecuencias
Oculta a los clientes los componentes del subsistema
Reduce el nmero de objetos con los que tienen que tratar los
clientes
Disminuye el acoplamiento entre un subsistema y sus
clientes
Un menor acoplamiento facilita el cambio de los componentes del
subsistema sin afectar a sus clientes
Las fachadas permiten estructurar el sistema en capas
Reduce las dependencias de compilacin
No evita que las aplicaciones puedan usar las clases del
subsistema si lo necesitan
Se puede elegir entre facilidad de uso y generalidad
Juan Pavn Mestras
Fachada
Reduccin del acoplamiento cliente-subsistema
Se puede reducir ms el acoplamiento haciendo la fachada una
clase abstracta con subclases concretas para las distintas
implementaciones del subsistema. Los clientes se comunican con
el subsistema usando la interfaz de la clase fachada abstracta
Otra posibilidad es configurar el objeto fachada con diferentes
objetos del subsistema. Para personalizar la fachada basta con
reemplazar uno o varios de sus objetos del subsistema
La factora abstracta se puede utilizar junto a la fachada para
crear objetos del subsistema de manera independiente al
subsistema
Clases del subsistema privadas y pblicas
En Java se puede utilizar los paquetes para determinar las clases
que son visibles fuera o no. En C++ los namespaces no soportan
la ocultacin de clases
Normalmente slo hace falta un objeto Fachada, por lo cual
suele implementarse como Singleton
Juan Pavn Mestras
Discusin
Muchos patrones estructurales tienen bastante similitud
en el esquema, los participantes y las colaboraciones
Las diferencias estn principalmente en el propsito
Adaptador y Bridge
Ambos envan peticiones a un objeto cuya interfaz es distinta
El adaptador trata de resolver incompatibilidades entre interfaces
existentes, bridge trata de proporcionar una interfaz estable a los
clientes, independiente de cmo evolucione la implementacin
Por tanto el Adaptador suele aparecer cuando ya hay clases
desarrolladas, pero el Bridge es algo que el diseador avanza al
principio del ciclo de vida del sistema
Juan Pavn Mestras
Discusin
Las diferencias estn principalmente en el propsito
Composite y Decorator
Ambos se basan en la composicin recursiva para organizar un
conjunto de objetos ilimitado
El Decorador pretende facilitar el aadir responsabilidades a los
objetos sin hacer subclases. Composite trata de que mltiples
objetos se puedan tratar de manera uniforme, como uno (el
nfasis est en la representacin y no en el embellecimiento)
Los propsitos son complementarios y por tanto se suelen usar
los dos patrones conjuntamente
Proxy
Similar estructura que Decorator
Especializacin de Bridge
Juan Pavn Mestras
Algoritmos y asignacin de responsabilidades entre
objetos y patrones de comunicacin entre objetos
Distribucin del comportamiento entre varias clases
Mediante herencia
Mtodo Template: definicin abstracta de un algoritmo
Intrprete: representa una gramtica como una jerarqua de
clases
Mediante composicin de clases
Mediador: entre varios objetos para desacoplarlos
Cadena de responsabilidad
Observador (MVC)
Encapsulado de comportamientos
Estrategia: encapsula un algoritmo en un objeto
Comando: encapsula una peticin a un objeto
Estado: encapsula el estado de un objeto
Visitor: encapsula un comportamiento
Iterador: el mtodo de recorrer una coleccin de clases
Juan Pavn Mestras
Chain of responsability
Peticin delegada al proveedor de servicio responsable
Command
Encapsula una peticin como un objeto
Interpreter
Intrprete de lenguaje para una gramtica sencilla
Iterator
Para acceder secuencialmente a elementos de una agregacin
Mediator
El mediador coordina las interacciones entre sus asociados
Memento
Captura el estado de un objeto y lo restaura posteriormente
Juan Pavn Mestras
Observer
Para notificar automticamente cambios de estado de un objeto a
todos los dependientes
State
Objeto cuyo comportamiento depende de un estado (el objeto puede
aparentar cambiar de clase segn un estado)
Strategy
Abstraccin para seleccionar uno o varios algoritmos
Template method
Algoritmo con varios pasos suministrados por una clase derivada
Visitor
Operaciones aplicadas a elementos de una estructura de objetos
heterognea
Juan Pavn Mestras
Mtodo Template
Propsito:
Permite construir el esqueleto de un algoritmo dejando los
detalles a las subclases
Aplicacin
Permite escribir las partes fijas de un algoritmo una sola vez
y definir las partes que varan en las subclases
Refactorizacin de cdigo
Identificar las diferencias en el cdigo existente
Separar las diferencias en nuevas operaciones
Reemplazar el cdigo diferente con un mtodo template que
llama a esas operaciones nuevas
Define los puntos de extensin de las subclases
til en frameworks: indica en qu puntos se puede extender
Juan Pavn Mestras
Mtodo Template
La clase abstracta define las operaciones primitivas (pasos
del algoritmo) que deben implementar las subclases
concretas
El mtodo template define el esqueleto del algoritmo
Juan Pavn Mestras
Mtodo Template
Consecuencias
Ayuda a la reutilizacin de cdigo
Por ejemplo, factorizando comportamiento en bibliotecas de
clases
Soporte de frameworks: invierte el flujo de control
Los mtodos que nos deja implementar son llamados por el
framework
El mtodo template puede llamar a:
Operaciones concretas (de la clase concreta o de las clientes)
Operaciones concretas de la clase abstracta (operaciones tiles
para las subclases)
Operaciones primitivas (pasos del algoritmo)
Mtodos factora
Operaciones Hook, que proporcionan el comportamiento por
defecto que las subclases pueden extender si fuera necesario
(por defecto no suelen hacer nada)
Juan Pavn Mestras
Estrategia
Propsito:
Permite definir una familia de algoritmos, encapsulndolos de
manera que se pueda intercambiar uno por otro
Policy (polticas)
Motivacin
En un procesador de textos, una clase Composition se encarga de
gestionar la divisin de lneas de un texto y para ello delega en
Compositor el algoritmo de divisin (por lneas, por prrafos, o por
un nmero fijo de caracteres)
Juan Pavn Mestras
Estrategia
Aplicacin
Cuando hay muchas clases similares que slo difieren en
algn comportamiento
Se puede configurar una clase con varios comportamientos
Se necesitan variantes de un algoritmo
Para ocultar estructuras de datos complejas que usa el
algoritmo
En vez de utilizar muchas instrucciones condicionales poner
los comportamientos alternativos en clases estrategia
concretas
Juan Pavn Mestras
Estrategia
La estrategia y el contexto colaboran para implementar un algoritmo
concreto:
La clase Strategy declara la interfaz comn a todos los algoritmos
El contexto se configura con una estrategia concreta y mantiene la
referencia correspondiente
El contexto puede definir una interfaz para que la clase estrategia acceda
a sus datos (y le pasar a la estrategia su referencia) o bien le pasa todos
los datos necesarios en las operaciones
Juan Pavn Mestras
Estrategia
Consecuencias
Permite gestionar familias de algoritmos
Se puede definir una jerarqua de clases de algoritmos
Sacar factor comn del cdigo
Se comprende mejor la relacin entre los algoritmos de la familia
Elimina instrucciones condicionales
Permite definir varias implementaciones del mismo
comportamiento
Como inconveniente, los clientes tienen que conocer las
distintas estrategias para elegir la ms apropiada
Juan Pavn Mestras
Discusin
Template Method vs. Strategy
El patrn mtodo template utiliza herencia para variar parte
de un algoritmo
El patrn estrategia utiliza delegacin para variar todo el
algoritmo
Los mtodos factora se llaman frecuentemente por los
mtodos template
Juan Pavn Mestras
Bibliografa
Gamma E., Helm R., Johnson R., Vlissides J., ; Design Patterns.
Elements of Reusable Object-Oriented Software; Addison-
Wesley, 1995. Traduccin al castellano (2002): Diseo de
patrones. Pearson Educacin
James W. Cooper, The Design Patterns Java Companion. Addison
Wesley, 1998
Steven J. Metsker, Design Patterns Java Workbook, Addison
Wesley, 2002

2 14pdoo

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

2 14pdoo

Cargado por

Copyright:

Formatos disponibles

Patrones de diseo orientado a objetos

Programacin Orientada a Objetos

También podría gustarte