patrones gof

Patrones de Diseño Ernesto Pimentel

IDEAS 2007. Isla de Margarita, Venezuela 1

Patrones de Diseño

Ernesto [email protected]

Universidad de Málaga

IDEAS 2007. Isla de Margarita, Venezuela

IDEAS 2007. Isla Margarita, Venezuela Patrones de Diseño 2

Contenido

• La noción de patrón de diseño.• Ventajas e inconvenientes.• Una clasificación de patrones de diseño.• Presentación de patrones de diseño.• Ejemplos de aplicación de patrones.




Patrones de Diseño

• Los L.O.O. facilitan la reutilización de código, pero un buen diseño es la clave para una reutilización efectiva.

• Un diseñador experimentado producirá diseños más simples, robustos y generales; fácilmente adaptables a cambios.

• Los patrones de diseño pretenden explotar soluciones efectivas a determinados problemas.


Patrones de Diseño

• Un patrón es una solución probada que se puede aplicar con éxito a un determinado tipo de problemas que aparecen repetidamente en el desarrollo de sistemas software.

• No son bibliotecas de clases, sino un “esqueleto” básico que cada desarrollador adapta a las peculiaridades de su aplicación.

• Los patrones se describen en forma textual, acompañados de diagramas (habitualmente de clases e interacción) y pseudocódigo.

• Se deben distinguir de los estilos arquitectónicos y, en particular, de los marcos de trabajo.




Patrones de diseño vs. Marcos de trabajo

• Ambos son complementarios.• Los patrones de diseño:

– Cubren el hueco entre las bibliotecas de clases y los marcos de trabajo.

– Presentan una granularidad más fina que los marcos de trabajo.

– Son más abstractos que los marcos de trabajo.

• Los marcos de trabajo:– Suele estar compuestos por una

colección de patrones de diseño.

Biblioteca de clases

Patrón de diseño

Marco de trabajo

Incr

emen

to d

e la

reut

ilizac

ión


Ventajas de los patrones de diseño (I)

• Son soluciones concretas:– Un catálogo de patrones es un conjunto de recetas de diseño. – Aunque se pueden clasificar, cada patrón es independiente del

resto.• Son soluciones técnicas:

– Dada una determinada situación, los patrones indican cómo resolverla mediante un D.O.O.

– Existen patrones específicos para un lenguaje determinado, y otros de carácter más general.

• Se aplican en situaciones muy comunes:– Proceden de la experiencia.– Han demostrado su utilidad para resolver problemas que

aparecen frecuentemente en el D.O.O.




Ventajas de los patrones de diseño (II)

• Son soluciones simples:– Indican cómo resolver un problema particular utilizando un

pequeño número de clases relacionadas de forma determinada.– No indican cómo diseñar un sistema completo, sino sólo aspectos

puntuales del mismo.• Facilitan la reutilización de las clases y del propio diseño:

– Los patrones favorecen la reutilización de clases ya existentes y la programación de clases reutilizables.

– La propia estructura del patrón es reutilizada cada vez que se aplica.


Inconvenientes

• El uso de un patrón no se refleja claramente en el código:– A partir de la implementación es difícil determinar qué patrón de diseño

se ha utilizado.– No es posible hacer ingeniería inversa.

• Referencias a “self”:– Muchos patrones utilizan la delegación de operaciones y esto provoca el

conocido problema del ámbito local de los objetos (self). • Es difícil reutilizar la implementación de un patrón:

– Las clases del patrón son roles genéricos, pero en la implementación aparecen clases concretas.

• Los patrones suponen cierta sobrecarga de trabajo a la hora de implementar:– Se usan más clases de las estrictamente necesarias.– A menudo un mensaje se resuelve mediante delegación de varios

mensajes a otros objetos.– ...




MVC: Un ejemplo de patrón

• En Smalltalk-80 se utiliza una relación entre clases denominada MVC (Modelo/Vista/Control), que se repite en otras muchas situaciones, y que se ha utilizado desde entonces para interfaces gráficas de usuario.

• MVC se puede considerar como un ejemplo típico de patrón de diseño.

• Se utiliza para construir interfaces de usuario distinguiendo tres tipos de objetos:– El modelo es el objeto que se desea evaluar.– La vista (o vistas) dan la información visual del objeto y permiten el

acceso al mismo mediante una interfaz de usuario.– El controlador se encarga de atender las peticiones que el usuario realiza

sobre la vista, invocando las acciones necesarias sobre el modelo.• El objetivo es independizar las distintas componentes del sistema.


MVC: Combinación de patrones

• En realidad, aunque MVC se puede presentarcomo un patrón de diseño en sí mismo, es el resultado de la combinación de varios patrones:– El patrón Observer: para desacoplar las vistas del

modelo; un cambio en el modelo repercute en las vistas (si hay varias) sin que éstas sean accesibles desdeaquél.

– El patrón Composite: las vistas habitualmente puedenestar anidadas, de forma que el tratamiento de los objetos complejos (paneles) coincide con el de cadacomponente (botones, menús, etc.)

– El patrón Strategy: El objeto controlador encapsula la forma en que el modelo responde a acciones sobre la vista; cambiando el controlador, la forma de responder puede cambiar.




Clasificación de los patrones de diseño

• Según su propósito:– Patrones de creación. Se refieren a la creación de instancias.– Patrones estructurales. Se refieren a las relaciones entre clases

y/u objetos.– Patrones de comportamiento. Caracterizan la forma en que las

clases u objetos interactúan y distribuyen sus responsabilidades (servicios).

• Según su ámbito:– Patrones de clases. Tratan con relaciones de herencia (estática)

entre clases.– Patrones de objetos. Se refieren a relaciones de composición

entre objetos, que pueden cambiar en tiempo de ejecución y son más dinámicas.


Catálogo de Gamma et al.

Cadena de mandoInstrucciónIteradorMediadorMemoriaObservadorEstadoEstrategiaVisitante

Adaptador (objetos)PuenteCompuestoDecoradorFachadaPeso ligeroRepresentante (proxy)

Fábrica abstractaConstructorPrototipoSingular

OBJETO

IntérpretePlantilla de métodos

Adaptador (clases)Fábrica de métodos

CLASE

ÁMBITO

COMPORTAMIENTOESTRUCTURALCREACIÓN

PROPÓSITO




El patrón Adaptador

• Adapta la interfaz de una clase a la interfaz esperada por sus clientes.

• Favorece la reutilización (de la clase adaptada) y permite la colaboración con interfaces incompatibles.

• También se conoce como Wrapper.

• Es un patrón estructural con una versión para clases y otra para objetos.

• Se puede aplicar cuando se desea reutilizar una clase existente, pero su interfaz no concuerda con lo que se necesita.


Adaptador: motivación

• Se está desarrollando un editor de dibujos que permite realizar diagramas a partir de elementos gráficos como líneas, círculos, texto, etc.

• Un elemento fundamental de dicho sistema es la clase ObjetoGráfico, que proporciona operaciones para modificar su forma (editar()) y para representarlo (dibujar()).

• Esta clase se especializa para cada tipo de objeto gráfico: Línea, Círculo, etc., clases donde se han implementado adecuadamente dichas operaciones.

• Sin embargo, la edición y representación de textos es una tarea complicada, por lo que se desea reutilizar la clase Text de la biblioteca de clases del entorno de programación.

• No obstante, la interfaz de Text (con operaciones como edit() y draw()) no se corresponde con la declarada por ObjetoGráfico.

• Por este motivo, se necesita desarrollar una clase Texto (adaptador) que adapte la clase Text (adaptada) a la interfaz declarada por ObjetoGráfico (objetivo).




Adaptador: motivación

Text

draw( )edit( )

ObjetoGráfico

dibujar( )editar( )

Círculo

dibujar( )editar( )

Línea

dibujar( )editar( )

EditorGráfico


Adaptador: versión para instancias

Text

draw( )edit( )

ObjetoGráfico

dibujar( )editar( )

Círculo

dibujar( )editar( )

Línea

dibujar( )editar( )

EditorGráfico

Texto

dibujar( )editar( )

dibujar( ){ text.draw( ); }

editar( ){ text.edit( ); }

text




Adaptador: versión para clases

Text

draw( )edit( )

ObjetoGráfico

dibujar( )editar( )

Círculo

dibujar( )editar( )

Línea

dibujar( )editar( )

EditorGráfico

Texto

dibujar( )editar( )

dibujar( ){ draw( ); }

editar( ){ edit( ); }


El patrón Adaptador

• Es un patrón de diseño estructural con dos versiones:

Objetivo

Adaptador

+método(…)

Adaptado

+métodoEspecifico(…)

… método(…) {métodoEspecífico(…);

}

+ método(…)

adapt

adapt.

Cliente




Adaptador: algunas consideraciones

• La versión con herencia (clases):– No funciona cuando se quiere adaptar una clase y sus subclases.– Introduce solo un objeto, y no se necesita ninguna referencia adicional

para acceder al objeto adaptado.– Permite redefinir parte del comportamiento de la clase adaptada, pues el

adaptador es una subclase suya.• La versión con delegación (objetos):

– Permite adaptar una clase y sus subclases. El adaptador puede añadir funcionalidad a todos los adaptados de una vez.

– Complica la redefinición del comportamiento de la clase adaptada, pues ello requeriría crear un descendiente de dicha clase, y adaptar esta otra clase en vez de la original.

• El tipo de adaptación puede ser muy variado:– Desde una simple conversión de interfaces (por ejemplo, cambiar los

nombres de las operaciones),– Hasta añadir un conjunto totalmente diferente de operaciones.

• Relacionado con otros patrones: Puente, Decorador, Representante


El patrón Singular

• Es un patrón de creación para objetos.• Asegura que una clase tiene una única instancia

– se puede generalizar a un número fijo de instancias.• Proporciona un mecanismo global de acceso a dicha

instancia.Ejemplos:

– contadores para asignar identificadores.– controladores de colas de impresión. – clases que representen tipos univaluados.– representación de clases como instancias de metaclases.




Singular: motivación

• En ocasiones es necesario utilizar clases – que posean una única instancia – que sea accesible desde el resto del sistema.

• Para ello se puede utilizar una variable global– pero esto no evita que se puedan crear varias instancias.

• Una solución mejor es que la propia clase – controle la creación de esa única instancia – proporcione un acceso global a la misma.


Singular: solución

• Para asegurar que se crea una sola instancia– el constructor de la clase no debe ser público.

• El almacenamiento de la instancia – se hará en una variable de clase (estática).

• El acceso a dicha variable – se hará a través de un método de clase (estático), – que devolverá una referencia a la instancia.

• La creación de la instancia– se hará la primera vez que se invoque este método.




El patrón Singular

Singular

-instanciaÚnica:Singular

+Instancia() : Singular- Singular()

El constructor debe ser privado.

Instancia (...) {if (instanciaÚnica == null)

instanciaÚnica = new Singular(...);return instanciaÚnica;

}


Singular: implementación en Java

class Singular {private static Singular instanciaÚnica;... // declaración de atributosprivate Singular(...) {... // inicialización de atributos

}public static Singular Instancia() {

if (instanciaÚnica == null)instanciaÚnica = new Singular(...);

return instanciaÚnica;}... // métodos de instancia

}




El patrón Singular y la genericidad

• Dificultades de aplicar el esquema en el caso de tener clases genéricas:– Imposibilidad de explicitar el tipo genérico en las

entidades estáticas, lo que implica situaciones de inseguridad del sistema de tipos.

– Solución basada en reflexión.– Solución basada en otro patrón: Prototipo.


El patrón Fábrica Abstracta

• Patrón de creación de objetos.• Proporciona una interfaz para crear familias de objetos

relacionados o dependientes sin especificar las clases concretas de las que son instancia.




Fábrica Abstracta: motivación

• Consideremos un juego de herramientas para construir interfaces de usuario que soporte múltiples estándares look-and-feel:– Diferentes look-and-feel definen diferentes aspectos (colores, figuras,

tipos de letra, etc.) y comportamientos (botones, menús, barras de scroll, ventanas, etc.)

– Por ejemplo: Motif, Presentation Manager, Open Windows, etc.• Una aplicación que use estas características no debería codificar

explícitamente la creación de objetos específicos del look-and-feelconcreto, pues ello complicaría la modificación posterior del mismo.

• Tampoco es razonable contemplar las distintas posibilidades de look-and-feel mediante sentencias condicionales que se repiten cada vez que se crea un panel o ventana; sería difícil extender la aplicación a nuevos look-and-feel.


Una solución “ingenua”…if (API.equals(“Motif”) {

MotifWindow mw = new MotifWindow(“Aceptar”);MotifButton mb1 = new MotifButton(“SI”);MotifButton mb2 = new MotifButton(“NO”);mw.add(mb1); mw.add(mb1);…

} else if (API.equals(“OW”) {OWWindow ow = new OWWindow(“Aceptar”);OWButton ob1 = new OWButton(“SI”);OWButton ob2 = new OWButton(“NO”);ow.add(ob1); mw.add(ob1);…

} else if (API.equals(“PM”) {…

}… • Repetición del mismo esquema a lo largo del código

• Dificultades de reutilización y extensión

String API;API = … // Valor inicial




¿Una solución algo menos “ingenua”?…Window w;Button b1,b2;if (API.equals(“Motif”) {

w = new MotifWindow(“Aceptar”);b1 = new MotifButton(“SI”);b2 = new MotifButton(“NO”);…

} else if (API.equals(“OW”) {w = new OWWindow(“Aceptar”);b1 = new OWButton(“SI”);b2 = new OWButton(“NO”);…

} else if (API.equals(“PM”) {…

}w.add(b1); w.add(b1);… • Aprovechamos la jerarquía de clases entre componentes

• Polimorfismo sobre los datos• Vinculación dinámica

String API;API = … // Valor inicial


Fábrica Abstracta: solución• Definición de una clase abstracta FábricaComponente que declara

una interfaz para crear cada tipo básico de componente:– crearVentana(…)– crearBotón(…)– crearMenú(…)– …

• Para cada tipo de componente se define también una clase abstracta:– Ventana– Botón– BarraScroll– …

• La clase FábricaComponente se desglosa en distintas factorías, una para cada tipo de look-and-feel:– FábricaMotif– FábricaPM– FábricaOW– …




Fábrica Abstracta: aplicación

FábricaComponente

crearVentana(…):VentanacrearBotón(…):BotóncrearScroll(…):BarraScrolll

Cliente

Ventana

VentanaOW VentanaPM VentanaMotif

Botón

BotónOW BotónPM BotónMotif

FábricaOW


FábricaPM


FábricaMotif



¿Una solución algo menos “ingenua”?

…Window w;Button b1,b2;

w = fábrica.crearVentana(“Aceptar”);b1 = fábrica.crearBotón(“SI”);b2 = fábrica.crearBotón(“NO”);…w.add(b1); w.add(b1);…

• La responsabilidad de la creación de objetos recae en la fábrica• Desacoplamiento total entre cliente y componentes• Fácil reutilización y extensión a nuevos requisitos

FábricaComponente API;API = new … // Valor inicial




El patrón Fábrica Abstracta

FábricaAbstracta


Cliente

ProdAbstA

ProductoA1 ProductoA2 ProductoA3

ProdAbstB

ProductoB1 ProductoB2 ProductoB3

FábricaConcreta1


FábricaConcreta2


FábricaConcreta3



Fábrica Abstracta: algunas consideraciones

• Normalmente, sólo se necesita una instancia de cada fábrica concreta:– las fábricas pueden definirse como “singulares” (aplicación del patrón

Singular).• Este patrón ayuda a controlar las clases de objetos que crea una

aplicación.• Dado que la responsabilidad de crear objetos se encapsula en las

factorías, los clientes se mantienen aislados de las clases de implementación.

• Facilita el intercambio de familias de productos. La clase de una fábricaconcreta aparece sólo una vez en cada aplicación.

• La extensión de fábricas abstractas para producir nuevos tipos de productos no es fácil. Esto se debe a que la interfaz de FábricaAbstracta fija el conjunto de productos que pueden crearse:– Cuando existe un ascendente común a todos los productos, este

inconveniente se puede resolver mediante casting;– Sin embargo, si la naturaleza de los nuevos objetos a crear es

sustancialmente distinta, la reutilización se ve comprometida.• Las clases fábricas concretas son implementadas habitualmente con

factorías de métodos (patrón Métodos Factoría), pero también con el patrón Prototipo.




El patrón Estado

• Es un patrón de comportamiento para objetos.• Se debe usar si:

– El comportamiento de un objeto depende de su estado, y se ve modificado en tiempo de ejecución.

– Las operaciones se definen mediante grandes instrucciones condicionales que dependen del estado del objeto (usualmente representado por una o más constantes enumeradas).

• Permite que un objeto cambie su comportamiento– cuando cambia su estado interno,– tal y como si el objeto cambiase de clase.

• Permite emular el método becomes: de Smalltalk– en aquellos lenguajes donde no está disponible.


Estado: motivación (I)

• Supongamos una clase Buffer1 que representa un buffer de tamaño 1, con métodos:• put y get para introducir y extraer elementos,• reset para vaciar el buffer.

vacío

lleno

putget,reset

put / exception

get / exception• Supongamos que la extracción de elementos de un buffer vacío y la inserción en un buffer lleno produce una excepción.




Estado: motivación (II)

class Buffer1<Elem> {enum Estado {vacío,lleno);private Estado est;...public void reset() {

if (est == Estado.lleno) get();}public void put(Elem e) {

if (est == Estado.vacío) {almacenar(e);est = Estado.lleno;

} else throw new RuntimeException(“Buffer lleno”);}... // De forma similar para get()

}


Estado: motivación (III)

• Supongamos una clase Buffer2con comportamiento similar a la anteriorcon capacidad de almacenar hasta dos elementos.

vacío

lleno

put

get

put / exception

get / exception

unoget, reset

put

reset




Estado: motivación (IV)

class Buffer2<Elem> extends Buffer1<Elem> {enum Estado {vacío,uno,lleno);private Estado est;...public void reset() {

if (est == Estado.uno) get();else if (est == Estado.lleno) { get(); get(); }

}public void put(Elem e) {

if (est == Estado.vacío) { almacenar(e);est = Estado.uno; }

else if (est == Estado.uno) { almacenar(e);est = Estado.lleno; }

else throw new RuntimeException(“Buffer lleno”);}... // De forma análoga para get()

}


Estado: motivación (y V)

• Problemas de reutilización:– Los métodos deben ser codificados de nuevo, sin posibilidad de reutilizar

las versiones de la superclase.– Obsérvese que incluso el método reset(), cuyo comportamiento no

varía, debe ser redefinido en su totalidad.• No se trata de un problema de implementación, sino de diseño.• El problema se produce al codificar el estado con un valor,

• Lo que da lugar a un análisis estático de casos.• La solución consiste en codificar el estado con una clase.:

• Lo que permite explotar el polimorfismo de datos, • Haciendo corresponder cada rama de comportamiento

condicional con una subclase.




Estado: ejemplo de aplicación

Estado

+get():void+put():void

contexto

1 estado

1

Vacío


Lleno


void put(...) {estado.put(…);

}

Buffer1


Buffer2

Vacío2 Lleno2 Uno


contexto

1 estado

1

void método(args) {estado.método(args,this);

}

EstadoContexto

+método(args)+cambiarEstado(Estado)

+método(…,Contexto)

Estado1


void cambiarEstado(Estado est) {estado = est;

}

EstadoN


…

void método(…, Contexto ctx) {…ctx.cambiarEstado(new EstadoM());…

}

El patrón Estado




Estado: algunas consideraciones

• Los métodos de las subclases de Estado deben acceder a los atributos del objeto Contexto:– en particular, será necesario ir cambiando de estado.– hay que añadir un argumento adicional (this) para hacer

referencia al objeto Contexto.• Toda la interfaz del Contexto debe delegarse al objeto

estado:void put(Elem e) {estado.put(e,this);}

• Los cambios de estado implican la continua creación de instancias de las subclases de Estado.– si dichas subclases no tienen atributos, se puede aplicar el patrón

Singular.– para aumentar la reutilización se puede utilizar el patrón Fábrica

Abstracta.


El patrón Estrategia

• Patrón de comportamiento a nivel de objetos• Define una familia de algoritmos, los encapsula en

clases distintas, y los hace intercambiables.• El patrón Estrategia permite variar los algoritmos

haciéndolos indendientes de los clientes que los utilizan.




Estrategia: motivación

• Existe una gran variedad de algoritmos para dividir un párrafo en líneas.

• Incluir todos estos algoritmos dentro de las clases que los pueden requerir no es deseable por varios motivos:– Los clientes que necesiten estos algoritmos se hacen más

complejos si incluyen el código de los mismos. Esto los hace másgrandes y difíciles de mantener, especialmente si soportan variosalgoritmos de guionación.

– Diferentes algoritmos pueden ser apropiados en momentosdistintos. No es necesario albergar varios algoritmos de guionaciónsi no se usan nunca.

– Es difícil añadir nuevos algoritmos o modificar alguno existentecuando el método de guionación es parte integral del cliente.

• Estos problemas se pueden evitar definiendo clases queencapsulen cada uno de los algoritmos (que podemosdenominar estrategia).


Estrategia: solución

PárrafoFormato

FormatoTeX FormatoWordFormatoTxt

formato.guionación(…)

formatear()guionación(…)

guionación(…) guionación(…) guionación(…)

formato




El patrón Estrategia

ContextoEstrategia

EstrategiaB EstrategiaCEstrategiaA

estrategia.algoritmo(…)

aplicarAlgoritmo()algoritmo(…)estrategia

algoritmo(…) algoritmo(…) algoritmo(…)


Estrategia: algunas consideraciones

• La jerarquía de las clases Estrategia define una familia de algoritmos o comportamientos para ser reutilizados por el contexto. La herencia puede ayudar a organizar la funcionalidadcomún de los algoritmos.

• Las estrategias eliminan la necesidad de utilizar construccionescondicionales para seleccionar el comportamiento deseado.

• Las estrategias pueden proporcionar diferentesimplementaciones a un mismo comportamiento.

• La interfaz de Estrategia es compartida por todas las clases quedeterminan estrategias concretas, ya sean estas simples o complejas. Por lo tanto, es probable que algunas estrategiasconcretas no utilicen toda la información pasada a través de esainterfaz (incluso, puede ocurrir que estrategias simples no utilicen nada de dicha información).

• Las estrategias incrementan el número de objetos en unaaplicación; a veces se puede reducir esta sobrecargaimplementando estrategias como objetos sin estado que los contextos pueden compartir (patrón Singular).




El patrón Observador

• Patrón de comportamiento para objetos.• Permite definir dependencias entre objetos de forma que si un

objeto cambia de estado todos los dependientes de él son notificados y actualizados automáticamente.

• Proporciona mecanismos para “registrar” objetos “observadores” en el objeto “observable” y “notificar” a aquellos cuando éste sufre alguna modificación.

• Se utiliza cuando se divide un sistema en clases que cooperan y se desea mantener la consistencia entre objetos relacionados, pero sin que estén altamente acoplados, pues ello comprometería su reutilización.


Observador: motivación

• Consideremos una interfaz gráfica de usuario en la que se poseen diversas representaciones de determinados datosde una aplicación.

• Las clases que determinan los datos (el modelo) y lasdistintas representaciones gráficas (las vistas) pueden ser reutilizadas independientemente.

• Por ejemplo, una hoja de cálculo, un diagrama de barras y un diagrama de sectores pueden mostrar diferentespresentaciones de los datos de una aplicación, pero cadauno de esos tres objetos pueden ser utilizadasindependientemente en otras aplicaciones.

• Las modificaciones sobre los datos deben repercutir en lastres presentaciones, e incluso podría ocurrir que alguno de los diagramas fuese editable, y modificaciones en éltambién repercutirían en el resto de diagramas y en los propios datos.




Observador: motivación

0

10

20

30

40

50

60

x

abc

a = 50%b = 30%c = 20%

bac

xa 50b 30c 20

notifcar notifc

ar

susc

ribir

suscribir


DiagramaSectoresestadoSectoresactualizar()

Observador: solución

Observable

suscribir(Observador)darBaja(Observador)notificar()

Observador

actualizar()obs

0..n

Datos

estadoDatosgetEstado()setEstado()

for each o in obs {o.actualizar();

}

DiagramaBarrasestadoBarrasactualizar()

dat

return estadoDatosreturn estadoBarras=

dat.getEstado();

HojaCálculoestadoHojaactualizar()




El patrón Observador

Observable

suscribir(Observador)darBaja(Observador)notificar()

Observador

actualizar()obs

0..n

ObservableConcreto

estadoObservablegetEstado()setEstado()

ObservadorConcreto

for each o in obs {o.actualizar();

}

estadoObservador

actualizar()observable

return estadoObservablereturn estadoObservador =

observable.getEstado();


El patrón Observador: interacción

unObservableConcreto unObservadorConcreto otroObservadorConcreto

setEstado()

notificar()

actualizar()

getEstado()

actualizar()

getEstado()




Observador:algunas consideraciones

• Se aplica cuando:– una abstracción tiene más de un aspecto, unos

dependientes de otros, – se desea reutilizar cada uno de ellos

independientemente de los otros.– el cambio de un objeto require cambiar los otros,

y no se sabe cuántos objetos debenactualizarse.

– un objeto debe notificar ciertos cambios a otros, pero sin saber quiénes son dichos objetos.



• El acoplamiento entre observables y observadores esabstracto y mínimo.

• La notificación se realiza mediante una difusión en la que el objeto observado no tiene que conocer la identidad de los observadores.

• A veces se puede producir un problema de actualizaciones“inesperadas” en cascada.

• Registro de observadores en los observables a través de estructuras asociativas (p.e. tablas hash) cuando hay muchos observables y pocos observadores.

• A veces puede interesar asociar a un mismo observadorvarios observables: en estos casos puede ser necesariopasar el objeto observado cuando éste notifica un cambio a los observadores.





• Mecanismo de notificación: – Cada cambio de estado puede disparar una notificación: política simple,

pero puede provocar cascadas de actualizaciones.– El propio objeto observado decide qué cambios son relevantes para ser

notificados. • Es conveniente evitar notificaciones específicas para observadores

concretos, y llegar a un compromiso entre:– Un protocolo de notificación que envía a cada observador la información

que necesita (a través de parámetros adicionales de la operación“actualizar”: alto acoplamiento entre observable y observadors, y ´bajareutilización.

– Un protocolo de notificación que sólo advierte a los observadores de la existencia de cambios; cada observador debe ser capaz de saber quéinformación relevante es la que ha cambiado: ineficiencia.

• Suscripción especializada de observadores:– Al suscribir un observador a un observable puede ser interesante

especificar qué tipo de aspectos pueden serle relevantes.– En algunas librerías de clases (java.swing) se organizan jerarquías de este

tipo de aspectos (XxxxListener)



• Encapsulamiento de actualizaciones complejas cuando lasrelaciones entre observados y observadores es compleja:– Varios objetos observados pueden estar estrechamente

relacionados entre sí.– Las notificaciones a los observadores deben realizarse sólo

después de que observables relacionados queden en un estadoconsistente.

• En estos casos, suele ser conveniente complementar el patrón con un gestor de cambios cuya responsabilidadincluye:– Mantenimiento de la asociación de cada observable con sus

observadores, liberando de ello a todos ellos.– Definición de una política de actualización.– Actualización de todos los observadores necesarios a petición de un

objeto observable. – El gestor puede especializarse con diferentes políticas,

construyendo una jerarquía.




El patrón Observador: gestor de cambios

Observable

suscribir(Observador o)darBaja(Observador)notificar()

Observador

actualizar(Observable)observadores0..n

for each o in observables for each p in s.observers

p.actualizar(o)

gestor.suscribir(this,o)

GestorCambios

Map<Observable,Observer>suscribir(Observable,Observer)darBaja(Observable,Observer)notificar()

gestor

observables

gestor.notificar()

GestorCambiosDAG

notificar()

GestorCambiosSimple

notificar()

for each o in observables for each p in s.observers

p.actualizar(o)


El patrón Prototipo

• Patrón para la creación de objetos.• Especifica el tipo de objetos que se deben

crear utilizando un prototipo de instancia, y creando nuevos objetos por medio de la copia de este prototipo.




Prototipo: motivación

• Consideremos la construcción de un editor de pentagramas, que pretende reutilizar un marco de trabajo que define editores gráficos mediante la incorporación de nuevos objetos que representannotas y otros elementos musicales.

• El marco de trabajo para este editor gráficodispondrá de una paleta de herramientas paraañadir estos objetos musicales al pentagrama.

• La paleta también incluirá herramientas paraseleccionar, mover y manipular estos objetos, y el usuario podrá seleccionar una u otra a su elección.



• Supongamos que el marco proporciona:– Una clase abstracta Graphic para las

componentes gráficas.– Una clase abstracta Tool para definir

herramientas como las mencionadas paraconstituir la paleta.

– Una subclase GraphicTool para herramientasque crean instancias de objetos gráficos y lasañaden al documento.





• La clase GraphicTool presenta un problema de diseño:– Las clases para notas y demás elementos musicales son específicas de

nuestra aplicación.– Pero la clase GraphicTool pertenece al marco genérico, y desconoce cómo

crear instancias de las clases musicales para ser añadidas al pentagrama.• Una solución sería subclasificar GraphicTool tantas veces como tipos

de objetos musicales tengamos, pero esto produciría una explosión de clases que sólo diferirían en el tipo de objeto musical a instanciar.

• Una alternativa es utilizar delegación en vez de herencia, pero ¿cómopodemos utilizar el marco de trabajo utilizar delegación paraparametrizar la clase GraphicTool con el tipo de Graphic que se supone que debe crear?

• La solución pasa por hacer que GraphicTool cree los objetos gráficoscopiando o clonando una instancia dada de la subclase adecuada de Graphic:– Para ello, es necesario que todas las sublcases de Graphic soporten la

operación clone(), o similar.


Prototipo: aplicación

Tool

manipular()

RotateTool

manipular()

GraphicTool

manipular()

p = prototipo.clone(); while (user arrastra ratón) {

p.dibujar(new posición);}insetar p en el gráfico

Graphic

dibujar(Posición)clone()

Nota

dibujar(Posición)clone():Nota

return copia de this

prototipo




El patrón Prototipo

Cliente

operación()

p = prototipo.clone();…


prototipo Prototipo

clone()

PrototipoConcreto2

clone()

PrototipoConcreto1

clone()



El patrón Prototipo:algunas consideraciones

• Se debe utilizar cuando un sistema debe ser independiente de cómo se crean, componeny representan sus productos:– Cuando las clases a instanciar se especifican en

tiempo de ejecución (p.ej. carga dinámica)– Para evitar construir jerarquías de clases

paralelas– Cuando las instancias de una clase pueden

contener una de un número limitado de combinaciones de estados.




El patrón Plantilla de Métodos

• Patrón de comportamiento para clases.• Define el esqueleto de un algoritmo en una

operación, retrasando la implementación de parte de los pasos a las subclases.

• El patrón hace que las subclases redefinanciertos pasos de un algoritmo sin cambiar la estructura global del mismo.


Plantilla de Métodos: motivación

• Supongamos que queremos extraer informaciónde una fuente externa (p.ej. un fichero), y los datosson tratados y almacenados en una estructurainterna.

• El problema surge en que la forma de tratamiento, puede variar de clases que aún no conocemos, o que pueden variar en el futuro.

• Codificar un tratamiento inicial directamente en el algoritmo de lectura puede comprometer el diseñoen el futuro.





… // Obtención Datostratamiento(Datos)…almacenamiento(DatosT)…

LectorDatos

lectura(Fichero)tratamiento()almacenamiento()

LectorFiltro

tratamiento(Datos)

Filtro

filtrado(Datos)

LectorCodificado

tratamiento(Datos)

Decodificador

decode(Datos)

…fil.filtrado(Datos)…

fil



…operaciónPrimitiva1()…operaciónPrimitiva2()…

ClaseAbstracta

métodoPlantilla()operaciónPrimitiva1()operaciónPrimitiva2()

ClaseConcreta

operaciónPrimitiva1()operaciónPrimitiva2()




Plantilla de Métodos: consideraciones

• Se puede aplicar:– Para implementar las partes invariantes de un

algoritmo, dejando a las subclases implementarel comportamiento que puede variar.

– Cuando el comportamiento común entresubclases debe ser factorizado y localizado en una clase común para evitar duplicación de código.


El patrón Cadena de Mando

• Patrón de comportamiento para objetos.• Disminuye el acoplamiento entre el emisor

de una petición y el receptor que finalmentela atiende.

• Se consigue dando a más de un objeto la oportunidad de responder a la petición.

• Los objetos receptores se encadenan y se van pasando la petición hasta que uno de ellos la atiende.




Cadena de Mando: motivación (I)

• Consideremos un sistema de ayudas sensible al contextoen una interfaz gráfica de usuario:– El usuario puede obtener información ayuda sobre cualquier parte

de la interfaz situándose sobre ella.– La ayuda que se obtiene depende de la parte de la interfaz sobre la

que se solicita y su contexto: p. ej., la ayuda que ofrece el botón de una ventana de diálogo puede no ser la misma que la que se asociaa un botón de la ventana principal de la aplicación.

– Si no existe ayuda específica sobre elemento del que se solicita (un botón, p.ej.), el sistema debería ofrecer un mensaje de ayuda másgeneral sobre el contexto inmediato (la ventana de diálogo, p.ej.)

• La información de ayuda se organiza atendiendo a suprofundidad en el contexto: de los elementos más internosa los más externos.

• El problema radica en que el objeto que finalmenteproporciona la ayuda no es conocido explícitamente por el objeto solicitante.


Cadena de Mando: motivación (II)

• La idea del patrón es desacoplar los emisores de los receptores dando a diferentes objetos la posibilidad de atender peticiones.

• La petición se va pasando de un objeto a otro a lo largo de una cadena “de mando” hasta que uno de ellos la atiende:

unBotónPrintayuda

unBotónOKayuda

unDiálogoPrintayuda

unDiálogoSaveayuda

unaAplicaciónayuda




Cadena de Mando: aplicación

Ayuda

pedirAyuda()

ayuda

if (this tiene ayuda) {mostrarAyuda();

} else {super.pedirAyuda();

}

ayuda.pedirAyuda();

Aplicación Componente

Diálogo Botón

pedirAyuda()mostrarAyuda()


El patrón Cadena de Mando

Gestor

petición()

superior

if (this atiende petición) {acciones

} else {super.petición();

}

superior.petición();

GestorConcreto2

petición()

GestorConcreto1

petición()




Cadena de Mando: consideraciones

• Este patrón libera a un objeto de conocer quién atiende suspeticiones: el objeto sólo tiene que confiar en que la petición se tratará adecuadamente.

• Sin embargo, nada lo garantiza: si la petición no se atiendeal final de la cadena, o ésta no está bien configurada.

• Ni el emisor ni el receptor tienen conocimiento explícito unode otro: en vez de mantener referencias a todos los receptores, el emisor sólo mantiene una referencia a susucesor.

• Habitualmente, en los casos susceptibles de aplicar estepatrón, los enlaces que establecen la cadena de mando yaexisten: patrón Compuesto o Decorador.


El patrón Mediador

• Patrón de comportamiento para objetos que define un objeto que encapsula cómo un conjunto de objetosinteractúa entre sí.

• El diseño orientado a objetos promueve la distribución del comportamiento entre objetos, pero esa distribución puedeimplicar estructuras con muchas conexiones entre los objetos: en el peor de los casos, cada objeto tieneconocimiento de todos los demás.

• Dividir un sistema en muchos objetos aumenta la reutilización, pero la proliferación de interconexiones tienede disminuirla: los objetos son difícilmente reutilizables sin la presencia de los otros con los que se comunica.




Mediador: motivación

• Consideremos la implementación de cajas de diálogo en una interfazgráfica de usuario: un diálogo utiliza una ventana para presentar unacolección de componentes como botones, menús y campos de texto.

• A menudo se producen dependencias entre los distintos componentesdel diálogo: por ejemplo, un botón puede estar desactivado mientras un campo de texto esté vacío, la selección de un elemento en una listadesplegable puede cambiar el contenido de un campo de texto, etc.

• Diferentes diálogos pueden presentar dependencias entrecomponentes distintas; así, aunque los diálogos incluyen los mismostipos de componentes, no pueden simplemente reutilizar clases de componentes existentes, sino que tienen que ser personalizadas parareflejar las depencias específicas del diálogo.

• Una personalización individualizada mediante subclasificación esexcesivamente tedioso, ya que muchas clases estarían implicadas.

• Una solución es definir un objeto mediador independiente, responsible de controlar y coordinar las interaccciones de un grupo de objetos. Éstos sólo conocen al mediador y no necesitan tener constancia unosde otros.


Mediador: solución

Componente

cambio() mediador.compCambio(this);

DirectorDiálogoFuente

crearComponentes()compCambio(Componente)

MenúDesplegable

getSelección()

CampoTexto

setTexto()

DirectorDiálogo

MostrarDiálogo()crearComponentes()compCambio(Componente)

mediador

menú campo




El patrón Mediador

Componentemediador

Mediador

MediadorConcreto

CompConcreto1 CompConcreto2


Mediador: consideraciones

• Un mediador reúne el comportamiento que, de otro modo, estaría distribuido entre varios objetos. Extender dichocomportamiento sólo requiere heredar de la claseMediador.

• Un mediador permite el desacoplamiento entrecomponentes, reemplazando interacciones muchos-a-muchos por uno-a-muchos.

• No es necesario definir una clase abstracta Mediadorcuando las componentes se organizan con un solo mediador.

• Las componentes han de comunicarse con su mediadorcuando ocurre algo de interés. Esto se puede implementarcon ayuda del patrón Observador.




El patrón Decorador

• Este patrón de diseño permite añadir responsabilidades adicionales a un objeto de forma dinámica.

• Los decoradores proporcionan una alternativa flexible a la subclasificación para añadir funcionalidad.


Decorador: solución

Componente

+operación():

ComponenteConcreta

+operación():

Decorador

+operación():

componente

DecoradorConcreto1

+operación():

DecoradorConcreto2

+operación():

DecoradorConcretoN

+operación():+comportamientoAdicional():

operación() {componente.operación();

}

operación(){super.operacióÿ();comportamientoAdicional();

}

…




Decorador: ejemplo de aplicación (I)

• El paquete java.io de Java constituye un excelente ejemplo del patrón Decorador.

• Las jerarquía de clases cuya raíz es la clase abstracta OutputStreampermite la combinación de filtros (FilterOutputStream) para combinar funciones diversas:

– salida sobre ficheros, – utilizando un buffer, – manipulando directamente datos básicos Java.

• De forma análoga se organiza la jerarquía InputStream.

DataOutputStream DataInputStream

Fichero binario

bytes bytesBufferedOutputStream

FileOutputStream

BufferedInputStream

FileInputStream


Decorador: ejemplo de aplicación (II)

OutputStream

+write(…)

FileOutputStream

+write(…)FilterOutputStream

+write(…)

out

DataOutputStream BufferedOutputStream

write(…) {out.write(…);

}

write(…){

// versión especialzada;

}

PrintStream

+write(…)

FileOutputStream

+write(…)

+write(…)+write(…)




El patrón Compuesto

• Compone objetos en tres estructuras para representar jerarquías que relacionan el todo con las partes.

• Este patrón deja a los clientes tratar objetos individuales y su composición de forma uniforme.


Compuesto: motivación

• Las herramientas de desarrollo de interfaces gráficas de usuario (GUI) proporcionan mecanismos para la creación y gestión de ventanas con diversos componentes: – gráficos, áreas de texto, botones, etiquetas, ventanas con barras de

desplazamiento, etc.– el usuario de la herramienta puede crear ventanas con cualquier

combinación de estos elementos.• En Java se utiliza la clase Component del paquete java.awt, y una

clase Container que puede estar compuesta de un número indeterminado de componentes, que pueden ser:– simples (como JButton, JLabel, JTextField, etec.), o – componentes complejos (como los proporcionados por el paquete

javax.swing – por ejemplo, JScrollPane, JTabbedPane o JSplitPane).




Compuesto: ejemplo de aplicación

Component

Container

JComboBox

JComponent

JLabel

JScrollPane

JSplitPane

JTabbedPane

*

1

2

paint()

paint() {// Dibuja componente derecha

// Dibuja componente izquierda}


Compuesto: solución

Componente

+operación():

ComponenteConcreta1

+operación():

Compuesto

+operación():

compoperación() {

for (Componente c : comp)c.operación();

}

ComponenteConcreta2

+operación():

ComponenteConcretaN

+operación():

*




El patrón Iterador

• Proporciona una forma de acceder secuencialmente a los elementos de una colección sin mostrar la representación interna de la misma.

• Permite definir diversos recorridos sobre una estructura, admitiendo el uso simultáneo de la misma por parte de varios clientes.


Iterador: solución

• Cada cliente tendrá acceso a la colección mediante una instancia de la clase Iterador.– Dicha instancia será proporcionada por la colección a la que se

quiere acceder.• La clase que implemente el iterador deberá tener acceso

a la implementación de la colección sobre la que itera.• Se podrán proporcionar tantos iteradores como se desee,

implementando diversos recorridos:– del principio al final (o al revés), – según el orden de los elementos almacenados,– de forma aleatoria, etc.




Iterador: ejemplo de aplicación

• En Java se utiliza este patrón para iterar sobre colecciones.Cliente

Iterator

+next():Object+hastNext():boolean+remove():void

Collection

+add(elem:Object):boolean+isEmpty():boolean+contains(elem:Object):boolean

List

BeanContextSupport

ListIterator

+previous():Object

BCSIterator

<< implementation>> << implementation>>


El patrón Representante

• Se trata de un patrón estructural de objetos que proporciona un representante (proxy) para controlar el acceso a un objeto.

Ejemplo: diferir la creación de objetos ‘pesados’hasta el momento que se necesite accederlos.

Considérese un editor de textos que permita incrustar imágenes en los documentos. La carga de imágenes grandes es una operación lenta, que no necesita realizarse al abrir el documento, sino sólo cuando una imagen se encuentra en el área de visualización. No obstante, será necesario tener en cuenta el tamaño de las imágenes para poder maquetar el documento.

¿Relación con?




Representante: primera aproximación

• Utilizamos un puntero nulo para hacer referencia a la imagen cuando no está aún cargada.

Inconvenientes:• Un puntero no es un objeto, no puede recibir mensajes.• No permite almacenar datos necesarios como el tamaño

de la imagen.• Se complica el editor, que debe conocer el uso del objeto

y distinguir si está cargado o no.

:Documento

imagen


Representante: solución

• Utilizamos un objeto como representante de la imagen. El representante hará las funciones de la imagen mientras esta no esté cargada.

• El mecanismo básico utilizado es la delegación.

:Documento

imagen:Representante

fichero :Imagen

datos

imagen




• Utilizamos un objeto como representante.

• El estado de la imagen (cargada o no) es transparente al editor.

Representante: funcionamiento

:Documento

imagen:Representante

tamañofichero

getTamaño()dibujar()

:Imagen

tamaño

Load(File)getTamaño()dibujar()

getTamaño() {if (imagen == null)

return tamañoelse return imagen.getTamaño();}

dibujar() {if (imagen == null)

imagen = Imagen.Load(fichero);imagen.dibujar();}

imagen


Representante:tipos de proxies

• Proxy remoto– Proporciona un representante local a un objeto remoto, ocultando

que cliente y representado residen en espacios de direcciones distintos.

• Proxy virtual– Permite crear objetos pesados bajo demanda

• Ej. copy-on-write

• Proxy de protección– Controla el acceso al objeto representado

• Ej. gestión de permisos de acceso (en Eiffel)

• Referencia inteligente– Reemplaza a un puntero para permitir funciones adicionales

• Ej. recolección de basura, bloqueo/desbloqueo, persistencia...




• El proxy debe apuntar al objeto representado.

Representante: estructura

Representante

imagen Imagen

tamaño



• Las interfaces de representante y representado son sustancialmente similares.


Representante

imagentamaño

Impl_Imagen

tamaño



I_Imagen





• Los objetos representados pueden ser de distintos tipos y el proxy ofrece un acceso transparente.


Representante

imagentamaño

Imagen_JPG

tamaño



I_Imagen


Imagen_BMP

tamaño


...

¿Relación con?


El patrón Visitante

• Patrón de comportamiento de objetos que representa una operación a aplicar sobre los objetos de una estructura.

• Permite definir nuevas operaciones sin cambiar las clases de los elementos sobre los que opera.

• Da prioridad a la descomposición funcional sobre la orientada a objetos.

A.Y.O.R




Visitante: motivación

Ejemplo: un compilador• representa programas mediante grafos sintácticos• varios tipos de nodos:

– variables– asignaciones– operaciones aritméticas, ...

• varias operaciones a realizar:– type checking– análisis de flujo– generación de código– pretty printing


Visitante: opciones de descomposición

ARITH.

ASSIGN

VAR

prettyprinting

generación de código

análisisde flujo

typechecking




• Agrupamos las métodos en las clases sobre las que actúan.

Visitante: descomposición de datos

Node

typecheck()flowanalysis()...

Variable


Assignment


Arithmetic


// métodos relativos a los nodos// de tipo Variable


Problemas:• Una nueva operación obliga a tocar todo.• Si la cohesión entre operaciones es baja, los

problemas de acoplamiento superan las ventajas.• Clases complejas y ‘contaminadas’ por

operaciones particulares.

Visitante: descomposición de datos

Node


Variable


Assignment


Arithmetic





• Clase visitante, con una subclase por cada nodo.

• Mayor cohesión del código.

Visitante: estructura

Visitor

visitVar(Node)visitAssign(Node)visitArith(Node)

TCVisitor


CGVisitor


FAVisitor


// funcionalidad específica // de type checking

...


• Las clases nodo aceptan la visita (callback ).

Visitante: estructura

Node

accept(Visitor)

Variable

accept(Visitor v)

Assignment Arithmetic

accept(Visitor v) accept(Visitor v)

accept(Visitor v) {v.visitVar(this);

}

accept(Visitor v) {v.visitAssign(this);

}

accept(Visitor v) {v.visitArith(this);

}




• La estructura puede contener objetos heterogéneos – Node es una interfaz.

• Las operaciones pueden ser heterogéneas – distintos modos de uso de una estructura compartida.

• Una nueva operación no afecta a la estructura– Localizada en una nueva subclase de Visitor.

Visitante: justificación y utilidad

Visitor


TCVisitor


CGVisitor


FAVisitor


...

Node

accept(Visitor)

Variable

accept(Visitor v)

Assignment Arithmetic

accept(Visitor v) accept(Visitor v)


¿Quién se encarga de recorrer la estructura?• La propia estructura

– recibe un visitante e invoca accept() sobre cada nodo• El visitante

– obliga a duplicar el código de recorrido• válido para recorridos dependientes de la operación concreta

• Un iterador– Interno a la estructura

• se evita el double dispatching: v.visit(node);– Externo

• fácil de implementar si la operación es simple (no recursiva)

Visitante: funcionamiento




• Visitante utiliza la técnica del double-dispatch– single dispatch (típico de L.O.O.)

• la operación invocada depende del nombre de la petición y el tipo del objeto receptor.

– double dispatch (lenguaje CLOS y otros)• la operación invocada depende del nombre de la petición y los

tipos tanto del receptor como de (los) argumento(s).

• Visitante simula el double dispatch en L.O.O.• permite añadir operaciones a una clase sin cambiarla.

– la interfaz se extiende mediante una nueva subclase de Visitor, en vez de muchas nuevas subclases de Node.

Visitante: temas relacionados


• Extensibilidad– sencilla para operaciones, más dificultosa para nodos

• Mayor cohesión funcional– cada visitante reúne operaciones relacionadas y

separa las que no lo están.– las estructuras específicas de un algoritmo se

encapsulan en el visitante correspondiente.– los visitantes pueden acumular estado fácilmente

• Se rompe el encapsulamiento de objetos– Las operaciones visitantes deben acceder a los

atributos de los nodos visitados.

Visitante: conclusiones

patrones gof

Documents