2.14PDOO

7/28/2019 2.14PDOO

1/54

Patrones de diseo orientado a objetosProgramacin Orientada a Objetos

Facultad de Informtica

Juan Pavn Mestras

Dep. Ingeniera del Software e Inteligencia Artificial

Universidad Complutense Madrid

Juan Pavn MestrasFacultad de Informtica UCM, 2004 Patrones de creacin 2

Hacer software no es fcil

Disear software orientado a objetos es difcil, y disearsoftware orientado a objetos reutilizable es todava msdifcil

Chapter 1: Introduction. Design Patterns, The Gang of Four

...y un software capaz de evolucionar tiene queser reutilizable (al menos para las versionesfuturas)

7/28/2019 2.14PDOO

2/54


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


Patrones

Cmo llegar a ser un maestro de ajedrez Primero aprender las reglas del juego

nombres de las piezas, movimientos legales, geometra y orientacindel 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 laspartidas de otros maestros Estas partidas contienen patrones que deben ser entendidos,

memorizados y aplicados repetidamente

Hay cientos de estos patrones

7/28/2019 2.14PDOO

3/54


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, programacinOO, programacin genrica, etc.

Sin embargo, para llegar a ser un maestro, hay que estudiar losdiseos de otros maestros Estos diseos contienen patrones que deben ser entendidos,

memorizados y aplicados repetidamente

Hay cientos de estos patrones


Patrones

Christopher Alexander (1977):Cada patrn describe un problema que ocurre una y otra vez en nuestroentorno, y describe la esencia de la solucin a ese problema, de tal modo quepueda utilizarse esta solucin un milln de veces ms, sin siquiera hacerlo dela 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 arquitecturassoftware que han tenido xito

7/28/2019 2.14PDOO

4/54


Motivacin de los Patrones

Capturan la experiencia y la hacen accesible a los noexpertos

El conjunto de sus nombres forma un vocabulario queayuda a que los desarrolladores se comuniquen mejor Lenguajes de patrones

Ayudan a la gente a comprender un sistema msrpidamente cuando est documentado con los patronesque usa

Los patrones pueden ser la base de un manual deingeniera de software

Si el software se convierte en una ingeniera, las prcticasexitosas deben ser documentadas sistemticamente y

ampliamente difundidas


Motivacin de los Patrones

Facilitan la reestructuracin de un sistema tanto si fue ono 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

7/28/2019 2.14PDOO

5/54


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 mspequeas

Describen el esquema bsico para estructurar subsistemas ycomponentes

Patrones elementales (idioms) Especficos de un lenguaje de programacin

Describen cmo implementar componentes particulares deun patrn


Ejemplos de patrones

Patrones arquitecturales Jerarqua de capas Tuberas y filtros Cliente/Servidor

Maestro-Esclavo Control centralizado ydistribuido

Patrones de diseo Proxies Factoras Adaptadores Composicin Broker

Patrones elementales(idioms)

Modularidad Interfaces mnimas

Encapsulacin Objetos Acciones y Eventos Concurrencia

7/28/2019 2.14PDOO

6/54


Patrones y Armazones

Los patrones de diseo tienen descripciones ms abstractas quelos armazones Las descripciones de patrones suelen ser independientes de los

detalles de implementacin o del lenguaje de programacin (salvoejemplos 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 losarmazones Los armazones siempre se aplican a un dominio de aplicacin

particular


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 laaplicacin y el software sobre el que est basada

El armazn determina qu mtodos se invocan en respuesta aeventos (se reusa el cdigo del cuerpo principal y se escribe elcdigo al que llama)

Un armazn es una aplicacin medio-acabada Las aplicaciones completas se desarrollan mediante herencia, e

instanciando componentes parametrizados del armazn

7/28/2019 2.14PDOO

7/54


Armazones (Frameworks)

Diferencias con bibliotecas

LGI CAESPECFICA

DE LAAPLICACIN

BUCLE DEEVENTOS

GUI

ADTs

BASE DEDATOS

MATHinvoca

Arquitectura basada enbiblioteca de clases

BUCLE DEEVENTOS

GUI

BASE DE DATOS

ADTs

MATHinvoca

LGI CAESPECFICA

DE LAAPLICACIN

Arquitectura basada enarmazn

" reutilizacin de cdigo " reutilizacin de diseo y cdigo


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

visualizacinen pantalla

objetos de control,eventos

7/28/2019 2.14PDOO

8/54


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


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?

7/28/2019 2.14PDOO

9/54


Cmo seleccionar un patrn de diseo

Considerar cmo los patrones de diseo solucionanproblemas 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


Cmo usar un patrn de diseo

1. Leer el patrn una vez para tener una visin general2. Volver y estudiar la estructura, los participantes y las

colaboraciones3. Ver un ejemplo concreto codificado del patrn4. Elegir nombres para los participantes del patrn que

sean significativos en el contexto de la aplicacin5. Definir las clases6. Definir nombres especficos de la aplicacin para las

operaciones en el patrn7. Implementar las operaciones que realizarn las

responsabilidades y colaboraciones del patrn

7/28/2019 2.14PDOO

10/54

Patrones de creacin


Patrones de creacin

En Java para crear un objeto se utiliza el operador newunObjeto=newClaseObjetos();

Una clase Factora puede ocuparse de los detalles de quclase de implementacin utilizar para crear un objeto de

un tipo determinado

XY XZ

XFactoria

creaX()

:X

Selecciona laimplementacin de X

new

7/28/2019 2.14PDOO

11/54


Patrones de creacin

Permiten que el sistema sea independiente de cmo secrean, 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 comportamientosfundamentales que por la definicin mediante herencia de todoslos comportamientos posibles

Por tanto, la creacin de objetos es algo ms que instanciar unaclase


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

7/28/2019 2.14PDOO

12/54


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


Mtodo Factora

Propsito:Permite que una clase difiera la instanciacin a las subclases (sonstas 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

7/28/2019 2.14PDOO

13/54


Mtodo Factora

Documento

Grafico

Documento doc= crearDocumento();documentos.anadirDocumento(doc);doc.abrir();

returnnewDocumentoTextual();

MiProcesadorTextos

crearDocumento()

DocumentoTextual

Aplicacion

crearDocumento()

nuevoDocumento()abrirDocumento()

Documento

abrir()

cerrar()salvar()restaurar()


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 conocimientode qu subclase de ayuda es la delegada

7/28/2019 2.14PDOO

14/54


Mtodo Factora

Esquema, participantes y colaboracionesEl Creator deja que sus subclases definan el mtodo factora queconstruye y devuelve un objeto del ConcreteProduct apropiado

Interfaz de losobjetos que crea elmtodo factora

Una clase queimplementa la

interfaz Product

Redefine el mtodo factora

Declara el mtodo factora quedevuelve un objeto de tipo

Product.Puede definir una

implementacin por defectoque devuelva un objeto

ConcreteProduct


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 quepermita 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 CreatorEjemplo: manipuladores de figuras: un tipo de manipuladorcon varios mtodos factora para cada tipo de figura

7/28/2019 2.14PDOO

15/54


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 unaoperacin separada por si el usuario quiere cambiarla

Mtodos factora parametrizados Para crear distintos tipos de objetos

public classCreator {

public Product create(ProductId);

};


Factora Abstracta

Propsito:Proporcionar una interfaz para crear familias de objetosrelaciones o dependientes, sin especificar sus clasesconcretas

Otras denominaciones: Abstract Factory Kit

Motivacin Definir una interfaz que soporte diferentes sistemas de

ventanes, p.ej. Motif, Windows, Openview, ...

7/28/2019 2.14PDOO

16/54


Factora abstracta: motivacin

Varias apariencias (Look & Feel) para la interfaz grfica:

JAVA L&F Motif L&F Windows L&F


Factora Abstracta

7/28/2019 2.14PDOO

17/54


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

Esquema, participantes y colaboraciones

FactoriaConcreta1

CreaProductoA()CreaProductoB()

FactoriaConcreta2


ProductoA1 ProductoA2

ProductoB1 ProductoB2

FactoriaAbstracta


ProductoAbstractoA

Cliente

ProductoAbstractoB

7/28/2019 2.14PDOO

18/54


Factora Abstracta

Consecuencias Se oculta a los clientes las clases de implementacin

los clientes manipulan los objetos a travs de las interfaces oclases 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 vezsimplemente 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 deproductos

Creacin de productos:

Mtodo factora por cada producto:La factora abstracta slo define una interfaz para crear productos, y es lasubclase factora concreta la que los crea. sta especificar sus productosredefiniendo el mtodo factora para cada uno.

Prototipo para cada factora concretaSe crea la factora concreta inicializada con un objeto prototipo de cadaproducto. 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 unaoperacin de creacin que tendra este parmetro)

Esta solucin requiere tambin que el cliente haga narrowing odynamic-cast

7/28/2019 2.14PDOO

19/54


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 Swingprivatevoid seleccionarApariencia() {

// Fuerza al sistema a adoptar una apariencia concretaStringlaf =UIManager.getSystemLookAndFeelClassName();try{

UIManager.setLookAndFeel(laf);}catch(UnsupportedLookAndFeelExceptionexc)

{System.err.println("Unsupported: " +laf);}catch(Exceptionexc)

{System.err.println("Error loading" +laf);}}


Builder

Propsito:Permite a un cliente construir un objeto complejoespecificando slo su tipo y contenido, ocultndole todoslos detalles de la construccin del objeto

7/28/2019 2.14PDOO

20/54


Builder

Motivacin Supongamos un editor que quiere convertir un tipo de texto

(p.ej. RTF) a varios formatos de representacin diferentes, yque puede ser necesario en el futuro definir nuevos tipos derepresentacin

El lector de RTF(RTFReader) puede configurarse con una clase deConversor de texto (TextConverter) que convierta de RTF a otrarepresentacin

A medida que el RTFReader lee y analiza el documento, usa elconversor de texto para realizar la conversin: cada vez quereconoce un token RTF llama al conversor de texto paraconvertirlo

Hay subclases de TextConverter para cada tipo de representacin

El conversor (builder) est separado del lector (director): sesepara el algoritmo para interpretar un formato textual de cmose convierte y se representa


Builder

7/28/2019 2.14PDOO

21/54


Builder

Aplicacin Cuando el algoritmo para crear un objeto complejo debe ser

independiente de las partes que constituyen el objeto y cmose juntan

Cuando el proceso de construccin debe permitirrepresentaciones diferentes para el objeto que se estconstruyendo


Builder

Esquema y participantesInterfaz para crear

partes de unproducto

Construye unobjeto usando la

interfaz de Builder Construye y junta

las partes delproducto

Representa elobjeto complejo

que se est

construyendo

7/28/2019 2.14PDOO

22/54


Builder

Colaboraciones


Builder

Consecuencias Permite variar la representacin interna de un producto

El Builder ofrece una interfaz al Director para construir unproducto y encapsula la representacin interna del producto ycmo se juntan sus partes.

Si se cambia la representacin interna basta con crear otroBulider 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

7/28/2019 2.14PDOO

23/54


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 unComposite

El Mtodo Factora se puede utilizar por el Builder paradecidir qu clase concreta instanciar para construir el tipo deobjeto deseado

El patrn Visitor permite la creacin de un objeto complejo,

en vez de paso a paso, dando todo de golpe como objetovisitante


Singleton

Propsito:Asegurar que una clase slo tiene un ejemplar, yproporcionar un punto de acceso global a ste

Motivacin Algunas clases slo necesitan exactamente un ejemplar

Un spoolerde impresin en un sistema, aunque haya variasimpresoras

Un slo sistema de archivos Un slo gestor de ventanas ...

En vez de tener una variable global para acceder a eseejemplar nico, la clase se encarga de proporcionar unmtodo de acceso

7/28/2019 2.14PDOO

24/54


Singleton

Aplicacin Cuando slo puede haber un ejemplar de una clase, y debe

ser accesible a los clientes desde un punto de acceso bienconocido

Cuando el nico ejemplar pudiera ser extensible porherencia, y los clientes deberan usar el ejemplar de unasubclase sin modificar su cdigo


Singleton

Esquema, participantes y colaboraciones 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 decrear su ejemplar nico

Singleton

static ejemplarUnicodatosSingleton

static ejemplar()operacion()getDatosSingleton() return ejemplarUnico

7/28/2019 2.14PDOO

25/54


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


Singleton

Implementacin Definicin de la clase: asegurar que slo hay un ejemplar

classSingleton{

privatestatic Singletonejemplar =null;public static SingletongetEjemplar() {

if ( ejemplar ==null )ejemplar =newSingleton();

returnejemplar;}protected Singleton() {

// lo que sea necesario}public void metodo() {...}

}

7/28/2019 2.14PDOO

26/54


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


Discusin

Hay dos maneras de parametrizar un sistema por lasclases 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 elresponsable 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 deimplementar

7/28/2019 2.14PDOO

27/54

Patrones estructurales



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 entrelos objetos

Las relaciones de uso estn determinadas por lasinterfaces que soportan los objetos

7/28/2019 2.14PDOO

28/54



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


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 unaaplicacin concreta

En el ejemplo, la clase TextView

Para aadir funcionalidad que la clase reutilizada noproporciona

En el ejemplo, la operacin CreateManipulator()

7/28/2019 2.14PDOO

29/54


Adaptador

La clase TextShape adapta TextView a la interfaz Shape, demanera que el editor grfico DrawingEditor puede reutilizar laclase 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)


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 necesariamenteinterfaces compatibles) El adaptador de objeto slo: para utilizar varias subclases

existentes para las que sera poco prctico adaptar suinterfaz heredando de cada una. Un adaptador de objetopuede adaptar la interfaz de su clase padre

7/28/2019 2.14PDOO

30/54


Adaptador

Esquema, participantes y colaboraciones (Adaptador de claseAdaptador 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 unainterfaz existente

que necesitaadaptacin

Adapta lainterfaz de

Adapteea lainterfaz Target

Define la interfazespecfica aldominio que

utiliza el cliente


Adaptador

Esquema, participantes y colaboraciones (Adaptador de objetoAdaptador 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 unainterfaz existente

que necesitaadaptacin

Adapta la

interfaz deAdapteea la

interfaz Target

Define la interfazespecfica aldominio que

utiliza el cliente

7/28/2019 2.14PDOO

31/54


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 quieranadaptar 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 quelas dos puedan evolucionar independientemente

Otras denominaciones:

Handle/Body Motivacin

La herencia permite que una abstraccin tenga variasimplementaciones: esta relacin se define en tiempo decompilacin

Hay casos en los que puede haber una gran jerarqua de clases deuna abstraccin (p.ej. Window, IconWindow, TransientWindow) yvarias jerarquas de implementacin (en diferentes plataformas)

Es necesario desacoplar la abstraccin de la implementacin

7/28/2019 2.14PDOO

32/54


Bridge


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 yextenderlas independientemente

Permite adems reducir la proliferacin de clases (ver ejemplo demotivacin)

Para que cambios en la implementacin de una abstraccin no haganrecompilar el cdigo de los clientes

En C++ es ms crtico porque la representacin de una clase es visible ensu definicin

Para compartir una implementacin entre mltiples objetos, sin quelo noten los clientes

7/28/2019 2.14PDOO

33/54


Bridge

Esquema, participantes y colaboraciones La Abstraccin pasa las peticiones del cliente al objeto Implementor

Define la interfazde las clases deimplementacin,que no se tiene

que correspondercon la de

Abstraction

Extiende la interfazAbstraction

Define la interfazde abstraccin ymantiene una

referencia al objetoImplementor


Bridge

Consecuencias Se desacopla interfaz e implementacin

La implementacin no est vinculada permanentemente a lainterfaz, 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

7/28/2019 2.14PDOO

34/54


Bridge

Implementacin y patrones relacionados 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++ slohabra 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 asistemas que ya existen. El patrn Bridge suele aplicarse al

empezar un diseo, para permitir que las abstracciones eimplementaciones evolucionen independientemente


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 ofrecelas 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

7/28/2019 2.14PDOO

35/54


Proxy


Proxy

Aplicacin: cuando es necesario una referencia a un objetoms sofisticada que el simple puntero o referencia aobjeto 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 caroshasta 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 opuntero para realizar alguna accin adicional:

Contar el nmero de referencias a un objeto para liberarlocuando nadie lo usa

Cargar un objeto persistente en memoria cuando se referenciapor primera vez

Sincronizar el acceso a un objeto con un cerrojo

7/28/2019 2.14PDOO

36/54


Proxy

Esquema, participantes y colaboraciones El Proxy pasa las peticiones al RealSubject cuando sea apropiado,

dependiendo del tipo de proxy

Mantiene una referencia al sujetoreal y proporciona la misma interfazControla el acceso al sujeto real ypuede ser responsable de crearlo y

destruirlo

Define la intefazcomn al SujetoReal y al Proxy

Define el objetoreal que

representa elproxy


Proxy

Consecuencias Introduce un nivel de indireccin al acceder a un objeto

Este nivel de indireccin tiene usos distintos dependiendo del tipode proxy:

Un proxy remoto puede ocultar dnde est el objeto real Un proxy virtual puede mejorar la eficiencia por ejemplo al crearun objeto bajo demanda

Tanto los proxies de proteccin como las referencias inteligentesrealizan 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

7/28/2019 2.14PDOO

37/54


Proxy

Implementacin y patrones relacionados 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 paraimplementarlo:

En C++ se puede sobrecargar el operador de acceso a unmiembro (->). As cuando se accede a un miembro se puedenhacer acciones adicionales

Esto es vlido slo cuando no es necesario distinguir el tipo deoperacin que se accede en el objeto

El patrn Proxy se puede ver como un caso particular deBridge:

un Proxy slo tiene una implementacin, y un Bridge puede tenerms de una un Proxy se suele usar para controlar el acceso a su

implementacin, el Bridge permite cambiar una implementacindinmicamente


Proxy

Implementacin y patrones relacionados 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 aaderesponsabilidades a un objeto, el proxy slo controla suacceso

7/28/2019 2.14PDOO

38/54


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)


Composite

7/28/2019 2.14PDOO

39/54


Composite

Aplicacin Para representar jerarquas de objetos parte-todo

Para que los clientes puedan manejar indistintamente objetosindividuales o composiciones de objetos Los clientes tratan todos los objetos en la estructura composite

de manera uniforme


Composite

Esquema, participantes y colaboraciones Los clientes usan la clase Componente para interaccionar con los

objetos de la estructura composite. Si el recipiente es una Hoja lapeticin se maneja directamente. Si se trata de un Composite, sepasa a sus componentes hijos, pudindose realizar operacionesadicionales antes o despus

Guarda sus hijosImplementa operaciones

sobre los hijos de la interfazComponentLas hojas definen el

comportamiento de losobjetos primitivos

Manipula losobjetos de la

composicin atravs de la interfaz

Component

Interfaz de los objetos de lacomposicinImplementa el

comportamiento por defecto

7/28/2019 2.14PDOO

40/54


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

Implementacin y patrones relacionados 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 otramanera se distribuira entre las hojas y el composite

7/28/2019 2.14PDOO

41/54


Decorador

Propsito: Asignar nuevas responsabilidades a un objeto

dinmicamente. Es una alternativa a la creacin de subclasespor 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

7/28/2019 2.14PDOO

42/54


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 nose tiene la definicin de la clase)


Decorador

Esquema, participantes y colaboraciones El Decorador enva las peticiones a su objeto Componente, y puede

realizar alguna operacin adicional antes o despus

Aade responsabilidades alcomponente

Define la interfazde los objetos a losque se les puedenasignar nuevas

responsabilidades

Mantiene una referencia alobjeto Componente y define

una interfaz conforme

7/28/2019 2.14PDOO

43/54


Decorador

Consecuencias Ms flexibilidad que la herencia de clases (esttica)

Las responsabilidades se aaden y quitan dinmicamente (entiempo 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 nuevascaractersticas mediante decoradores, pudiendo as obtenergran 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


Decorador

Implementacin y patrones relacionados Conformidad de interfaces

La interfaz de un objeto decorador debe ser conforme con la delcomponente que decora, por tanto un objeto decorador concretodebe heredar de una clase comn

Omisin de la clase abstracta Decorador Si slo se va a definir una nueva responsabilidad no hace faltadefinir 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, paracambiar lo que se hace en medio de la llamada a un mtodose usa el patrn Strategy

Es distinto del Adaptador ya que slo aaderesponsabilidades a un objeto, no su interfaz

Puede verse como un caso degenerado de Composite con unsolo componente. Sin embargo, el decorador aaderesponsabilidades

7/28/2019 2.14PDOO

44/54


Fachada

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

El subsistema de compilacin ofrece scanner, parser, ... a travs de unainterfaz unificada (la fachada) de la funcionalidad del compilador, sinocultar completamente las clases que lo implementan

7/28/2019 2.14PDOO

45/54


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 lasclases de implementacin de una abstraccin

La fachada desacopla el subsistema de los clientes y de otrossubsistemas

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


Fachada

Esquema, participantes y colaboraciones 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 interfacesdel subsistema)

Los clientes que usan la fachada no tienen que acceder a losobjetos del subsistema directamenteConoce los objetos del subsistemaresponsables para cada peticin, ydelega en ellos las peticiones de

los clientes

Implementan lafuncionalidaddel subsistema.No tienenconocimiento de

la fachada

7/28/2019 2.14PDOO

46/54


Fachada

Consecuencias Oculta a los clientes los componentes del subsistema

Reduce el nmero de objetos con los que tienen que tratar losclientes

Disminuye el acoplamiento entre un subsistema y susclientes

Un menor acoplamiento facilita el cambio de los componentes delsubsistema 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 delsubsistema si lo necesitan

Se puede elegir entre facilidad de uso y generalidad


Fachada

Implementacin y patrones relacionados Reduccin del acoplamiento cliente-subsistema

Se puede reducir ms el acoplamiento haciendo la fachada unaclase abstracta con subclases concretas para las distintasimplementaciones 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 conreemplazar uno o varios de sus objetos del subsistema

La factora abstracta se puede utilizar junto a la fachada paracrear objetos del subsistema de manera independiente alsubsistema

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 soportanla ocultacin de clases

Normalmente slo hace falta un objeto Fachada, por lo cualsuele implementarse como Singleton

7/28/2019 2.14PDOO

47/54


Discusin

Muchos patrones estructurales tienen bastante similituden 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 losclientes, independiente de cmo evolucione la implementacin

Por tanto el Adaptador suele aparecer cuando ya hay clasesdesarrolladas, pero el Bridge es algo que el diseador avanza alprincipio del ciclo de vida del sistema


Discusin

Las diferencias estn principalmente en el propsito Composite y Decorator

Ambos se basan en la composicin recursiva para organizar unconjunto de objetos ilimitado

El Decorador pretende facilitar el aadir responsabilidades a losobjetos sin hacer subclases. Composite trata de que mltiplesobjetos se puedan tratar de manera uniforme, como uno (elnfasis est en la representacin y no en el embellecimiento)

Los propsitos son complementarios y por tanto se suelen usarlos dos patrones conjuntamente

Proxy Similar estructura que Decorator Especializacin de Bridge

7/28/2019 2.14PDOO

48/54

Patrones de comportamiento



Algoritmos y asignacin de responsabilidades entreobjetos 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 declases

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

7/28/2019 2.14PDOO

49/54



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



Observer Para notificar automticamente cambios de estado de un objeto a

todos los dependientes

State

Objeto cuyo comportamiento depende de un estado (el objeto puedeaparentar 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

7/28/2019 2.14PDOO

50/54


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


Mtodo Template

Esquema, participantes y colaboraciones La clase abstracta define las operaciones primitivas (pasos

del algoritmo) que deben implementar las subclasesconcretas

El mtodo template define el esqueleto del algoritmo

7/28/2019 2.14PDOO

51/54


Mtodo Template

Consecuencias Ayuda a la reutilizacin de cdigo

Por ejemplo, factorizando comportamiento en bibliotecas declases

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 degestionar la divisin de lneas de un texto y para ello delega enCompositor el algoritmo de divisin (por lneas, por prrafos, o porun nmero fijo de caracteres)

7/28/2019 2.14PDOO

52/54


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 estrategiaconcretas


Estrategia

Esquema, participantes y colaboraciones 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 todoslos datos necesarios en las operaciones

7/28/2019 2.14PDOO

53/54


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

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 losmtodos template

7/28/2019 2.14PDOO

54/54


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

Documents

Transcript of 2.14PDOO