Documentos de Académico
Documentos de Profesional
Documentos de Cultura
2 14pdoo PDF
2 14pdoo PDF
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
Patrones
Patrones
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
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
Ejemplos de patrones
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
LGI CA GUI
ESPECFICA
GUI
BASE DE
DE LA
DATOS MATH
APLICACIN LGI CA
ESPECFICA invoca
MATH BUCLE DE DE LA
invoca
EVENTOS APLICACIN ADTs
BUCLE DE
EVENTOS ADTs
BASE DE DATOS
Modelo-Vista-Controlador
Utilizado en Smalltalk [Krasner and Pope, 1988]
Distribucin de responsabilidades
Utilizado en JFC (componentes Swing)
Modelo aplicacin
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?
Patrones de creacin
Factoria
X new :X
creaX()
XY XZ
Selecciona la
implementacin de X
Patrones de creacin
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
Documento
Aplicacion
abrir()
cerrar() crearDocumento()
nuevoDocumento()
salvar()
abrirDocumento()
restaurar()
Documento doc = crearDocumento();
documentos.anadirDocumento(doc);
doc.abrir();
Documento MiProcesadorTextos
Documento
Grafico Textual
crearDocumento()
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
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
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
Factora Abstracta
Propsito:
Proporcionar una interfaz para crear familias de objetos
relaciones o dependientes, sin especificar sus clases
concretas
Otras denominaciones:
Abstract Factory
Kit
Motivacin
Definir una interfaz que soporte diferentes sistemas de
ventanes, p.ej. Motif, Windows, Openview, ...
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
Factora Abstracta
CreaProductoA() FactoriaConcreta2
CreaProductoB()
CreaProductoA()
CreaProductoB()
ProductoAbstractoB
ProductoB1 ProductoB2
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
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
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
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
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
Builder
Construye un Representa el
objeto usando la objeto complejo
interfaz de Builder Construye y junta que se est
las partes del construyendo
producto
Colaboraciones
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
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
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
Singleton
Singleton
Define un mtodo Instance( ) static ejemplarUnico
que permite a los clientes datosSingleton
acceder al ejemplar
static ejemplar()
Puede ser responsable de operacion()
return ejemplarUnico
crear su ejemplar nico getDatosSingleton()
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
Singleton
Implementacin
Definicin de la clase: asegurar que slo hay un ejemplar
class Singleton {
private static Singleton ejemplar = null;
public static Singleton getEjemplar() {
if ( ejemplar == null )
ejemplar = new Singleton();
return ejemplar;
}
protected Singleton() {
// lo que sea necesario
}
public void metodo() {...}
}
Implementacin
Utilizacin:
Singleton instance = Singleton.getEjemplar();
//
instance.metodo();
Discusin
Patrones estructurales
Adaptador
Propsito:
Convertir la interfaz de una clase en otra que esperan los
clientes
Otras denominaciones:
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()
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
Define una
interfaz existente
que necesita
adaptacin
Define la interfaz
especfica al
dominio que
utiliza el cliente
Adapta la
interfaz de
Adaptee a la
interfaz Target
Adaptador
Define una
interfaz existente
que necesita
Define la interfaz adaptacin
especfica al
dominio que
utiliza el cliente
Adapta la
interfaz de
Adaptee a la
interfaz Target
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
Bridge
Propsito:
Desacopla una abstraccin de su implementacin de manera que
las dos puedan evolucionar independientemente
Otras denominaciones:
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
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
Define la interfaz
de las clases de
implementacin,
que no se tiene
Define la interfaz que corresponder
de abstraccin y con la de
mantiene una Abstraction
referencia al objeto
Implementor
Extiende la interfaz
Abstraction
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
Proxy
Propsito:
Es un sustituto de otro objeto, para controlar el acceso a l
Otras denominaciones:
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
Facultad de Informtica UCM, 2004 Patrones de creacin 68
Proxy
Proxy
Define la intefaz
comn al Sujeto
Real y al Proxy
Define el objeto
real que
representa el
proxy
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
Proxy
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)
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
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
Composite
Propsito:
Asignar nuevas responsabilidades a un objeto
dinmicamente. Es una alternativa a la creacin de subclases
por herencia
Otras denominaciones:
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
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)
Decorador
Define la interfaz
de los objetos a los Mantiene una referencia al
que se les pueden objeto Componente y define
asignar nuevas una interfaz conforme
responsabilidades
Aade responsabilidades al
componente
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
Decorador
Propsito:
Simplifica el acceso a un conjunto de objetos proporcionando uno
que todos los clientes pueden usar para comunicarse con el conjunto
Otras denominaciones:
Faade
Motivacin
Minimizar las comunicaciones y dependencias entre subsistemas
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
Facultad de Informtica UCM, 2004 Patrones de creacin 89
Fachada
Implementan la
funcionalidad
del subsistema.
No tienen
conocimiento de
la 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
Fachada
Discusin
Patrones de comportamiento
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
Patrones de comportamiento
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
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
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)
Estrategia
Propsito:
Permite definir una familia de algoritmos, encapsulndolos de
manera que se pueda intercambiar uno por otro
Otras denominaciones:
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)
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
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
Discusin
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