POO PARTE 2

7/21/2019 POO PARTE 2

1/78

Materia: Paradigma OO, Introduccin a java y Software Patterns

Profesor: Lic. Adriana Prez | 2

2- Programacin Orientada a Objetos y

Patrones

2.1- Java BeansConcepto

Frases introductorias

Un JavaBean o bean es un componente hecho en softwareque se puede reutilizar y que puede ser manipuladovisualmente por una herramienta de programacin enlenguaje Java.

Para ello, se define un interfaz para el momento del diseo (design time)que permite a la herramienta de programacin o IDE, interrogar (query) alcomponente y conocer las propiedades (properties) que define y los tipos desucesos (events) que puede generar en respuesta a diversas acciones.

Aunque los beans individuales pueden variar ampliamente en funcionalidaddesde los ms simples a los ms complejos, todos ellos comparten lassiguientes caractersticas:

Introspection: Permite analizar a la herramienta de programacin oIDE como trabaja el vean.

Customization: El programador puede alterar la apariencia y laconducta del bean.

Eventos: Informa al IDE de los sucesos que puede generar enrespuesta a las acciones del usuario o del sistema, y tambin lossucesos que puede manejar.

Propiedades: Permite cambiar los valores de las propiedades del

bean para personalizarlo (customization).

Persistencia: Se puede guardar el estado de los beans que han sidopersonalizados por el programador, cambiando los valores de suspropiedades.

En general, un bean es una clase que obedece ciertas reglas:

Un bean tiene que tener un constructor por defecto (sinargumentos).

Un bean tiene que tener persistencia, es decir, implementar elinterfaceSerializable.

7/21/2019 POO PARTE 2

2/78



Un bean tiene que tener introspeccin (instrospection). Los IDEreconocen ciertas pautas de diseo, nombres de las funcionesmiembros o mtodos y definiciones de las clases, que permiten a laherramienta de programacin mirar dentro del bean y conocer suspropiedades y su conducta.

O Sea:

Una clase de beans no deber tener variables de instanciapblicas (campos).

Los valores persistentes debern accederse a travs demtodos llamados getXXX y setXXX.

Propiedades

Una propiedad es un atributo del JavaBean que afecta a su apariencia o a suconducta. Por ejemplo, un botn puede tener las siguientes propiedades: eltamao, la posicin, el ttulo, el color de fondo, el color del texto, si est ono habilitado, entre otras. Las propiedades de un bean pueden examinarsey modificarse mediante mtodos o funciones miembro, que acceden a dichapropiedad, y pueden ser de dos tipos:

getter method: lee el valor de la propiedad

setter method: cambia el valor de la propiedad

Un IDE que cumpla con las especificaciones de los JavaBeans sabe cmoanalizar un bean y conocer sus propiedades. Adems, crea unarepresentacin visual para cada uno de los tipos de propiedades,denominada editor de propiedades, para que el programador puedamodificarlas fcilmente en el momento del diseo.

Cuando un programador, arrastra un bean de la paleta de componentes y lodeposita en un panel, el IDE muestra el bean sobre el panel. Cuandoseleccionamos el bean aparece una hoja de propiedades, que es una lista delas propiedades del bean, con sus editores asociados para cada una de ellas.

El IDE llama a los mtodos o funciones miembro que empiezan por get,para mostrar en los editores los valores de las propiedades. Si elprogramador cambia el valor de una propiedad se llama a un mtodo cuyonombre empieza por set, para actualizar el valor de dicha propiedad y quepuede o no afectar al aspecto visual del bean en el momento del diseo.

Las especificaciones JavaBeans definen un conjunto de convenciones que elIDE usa para inferir qu mtodos corresponden a propiedades.

public void setNombrePropiedad(TipoPropiedad valor)

public TipoPropiedad getNombrePropiedad( )

7/21/2019 POO PARTE 2

3/78



Cuando el IDE carga un bean, usa el mecanismo denominado reflectionpara examinar todos los mtodos, fijndose en aquellos que empiezan porset y get.

El IDE aade las propiedades que encuentra a la hoja de propiedades paraque el programador personalice el bean.

Propiedades Simples

Una propiedad simple representa un nico valor.

Ejemplo

//miembro de la clase que se usa para guardar el valor de la

propiedad

private String nombre;

//mtodos set y get de la propiedad denominada Nombre

public void setNombre(String nuevoNombre){

nombre=nuevoNombre;

}

public String getNombre(){

return nombre;

}

En el caso de que dicha propiedad sea booleana se escribe


propiedadprivate boolean conectado=false;

//mtodos set y get de la propiedad denominada Conectado

public void setConectado(boolean nuevoValor){

conectado=nuevoValor;

}

public boolean isConectado(){

return conectado;

}

Propiedades indexadas

Una propiedad indexada representa un array de valores.


propiedad

private int[] numeros={1,2,3,4};

//mtodos set y get de la propiedad denominada Numeros, para

el array completo

public void setNumeros(int[] nuevoValor){

numeros=nuevoValor;

}

public int[] getNumeros(){

return numeros;

}

7/21/2019 POO PARTE 2

4/78



//mtodos get y set para un elemento de array

public void setNumeros(int indice, int nuevoValor){

numeros[indice]=nuevoValor;

}

public int getNumeros(int indice){

return numeros[indice];

}

Propiedades ligadas (bound)

Los objetos de una clase que tiene una propiedad ligada notifican a otrosobjetos (listeners) interesados, cuando el valor de dicha propiedad cambia,permitiendo a estos objetos realizar alguna accin. Cuando la propiedadcambia, se crea un objeto (event) que contiene informacin acerca de lapropiedad (su nombre, el valor previo y el nuevo valor), y lo pasa a los otrosobjetos (listeners) interesados en el cambio.

Propiedades restringidas (constrained)

Una propiedad restringida es similar a una propiedad ligada salvo que losobjetos (listeners) a los que se les notifica el cambio del valor de lapropiedad tienen la opcin de frenar cualquier cambio en el valor de dichapropiedad.

Anlisis de caso

Supongamos que:

Cuando a un empleado (objeto de la clase Asalariado) le aumentan elsueldo, ha de notificar este hecho a otros: la familia, la Hacienda pblica,entre otros. Vamos a estudiar con detalle los pasos necesarios para crearuna clase Asalariado con una propiedad ligada (el sueldo) y otra claseHacienda cuyos objetos (funcionarios) estn interesados en el cambio en elvalor de dicha propiedad.

Este ejemplo, nos permitir profundizar an ms en el mecanismo queemplea Java para responder a las acciones del usuario sobre los distintoscontroles y grupos de controles.

Una clase con una propiedad ligada (bound)

Creamos una clase denominada Asalariado con una propiedad ligada(bound) denominada sueldo de tipo int.

public class Asalariado{

private int sueldo;

7/21/2019 POO PARTE 2

5/78

7/21/2019 POO PARTE 2

6/78



miembros dato, que se pueden declarar private o protected, segnconvenga.

La clase define dos funciones miembro, getNuevoSueldo y getAnteSueldo,que permiten conocer los valores que guardan los dos miembros dato.

import java.util.*;

public class SalarioEvent extends EventObject {

protected int anteSueldo, nuevoSueldo;

public SalarioEvent(Object fuente, int anterior, int

nuevo){

super(fuente);

nuevoSueldo=nuevo;

anteSueldo=anterior;

}

public int getNuevoSueldo(){ return nuevoSueldo;}

public int getAnteSueldo(){ return anteSueldo;}

}

La interfase Listener

Una interfase es un grupo de mtodos que implementan varias clasesindependientemente de su relacin jerrquica, es decir, de que estn o noen una jerarqua.

La clase cuyos objetos (listeners) estn interesados en el cambio en el valorde la propiedad ligada, ha de implementar una interfase que se ha

denominado SalarioListener. Dicha interfase declara un nico metodoenteradoCambioSueldo que ha de ser definida por la clase que implementela interfase.

import java.util.*;

public interface SalarioListener extends EventListener {

public void enteradoCambioSueldo(EventObject e);

}

La fuente de los sucesos (events)

Un objeto que est interesado en recibir sucesos (events) se denomina eventlistener. Un objeto que produce los sucesos se llama event source, el cualmantiene una lista salarioListeners (objeto de la clase Vector) de objetosque estn interesados en recibir sucesos y proporciona dos mtodos paraaadir addSalarioListener o eliminar removeSalarioListener dichos objetosde la lista

public class Asalariado{

private Vector salarioListeners=new Vector();

public synchronized void

addSalarioListener(SalarioListener listener){

salarioListeners.addElement(listener);

7/21/2019 POO PARTE 2

7/78



}

public synchronized void

removeSalarioListener(SalarioListener

listener){

salarioListeners.removeElement(listener);

}

//...}

Cada vez que se produce un cambio en el valor de la propiedadSueldo, se ha de notificar dicho cambio a los objetos interesados quese guardan en el vector salarioListeners.

La funcin miembro o mtodo que cambia la propiedad sedenomina setSueldo.

La tarea de dicha funcin como hemos visto anteriormente es la deactualizar el miembro dato sueldo, pero tambin tiene otras tareascomo son las de crear un objeto de la clase SalarioEvent y notificar alos objetos interesados (listeners) de dicho cambio llamando a lafuncin miembro notificarCambio y pasndole en su nicoargumento el objeto event creado.

Para crear un objeto event de la clase SalarioEvent, se precisa pasaral constructor tres datos: el objeto fuente de los sucesos, this, elsueldo que cobraba antes, anteSueldo y el sueldo que cobra ahora,nuevoSueldo.

public void setSueldo(int nuevoSueldo){

int anteSueldo=sueldo;

sueldo=nuevoSueldo;

if(anteSueldo!=nuevoSueldo){

SalarioEvent event=new SalarioEvent(this,

anteSueldo,

nuevoSueldo);

notificarCambio(event);

}

}

Se define la funcin notificarCambio, para notificar el cambio en lapropiedad Sueldo a los objetos (listeners) que estn interesados en cambiode dicha propiedad y que se guardan en el vector salarioListeners. En dichafuncin, se crea una copia del vector salarioListeners y se guarda en lavariable local lista de la clase Vector. La palabra clave synchronized evitaque varios procesos ligeros o threads puedan acceder simultneamente a lamisma lista mientras se efecta el proceso de copia.

Ayuda: La palabra reservada synchronized se usa para indicar que ciertaspartes del cdigo, (habitualmente, una funcin miembro) estnsincronizadas, es decir, que solamente un subproceso puede acceder a dicho

mtodo a la vez.

7/21/2019 POO PARTE 2

8/78



Cada mtodo sincronizado posee una especie de llave que puede cerrar oabrir la puerta de acceso. Cuando un subproceso intenta acceder al mtodosincronizado mirar a ver si la llave est echada, en cuyo caso no podraccederlo. Si mtodo no tiene puesta la llave entonces el subproceso puedeacceder a dicho cdigo sincronizado.

Vector lista;

synchronized(this){

lista=(Vector)salarioListeners.clone();

}

Finalmente, todos los objetos (listeners) interesados y que se guardan en elobjeto lista, llaman a la funcin miembro enteradoCambioSueldo, ya que laclase que describe a dichos objetos, como veremos ms adelante,implementa la interfase SalarioListener. En el estudio de la clase Vectorvimos cmo se acceda a cada uno de sus elementos.

for(int i=0; i

7/21/2019 POO PARTE 2

9/78



removeSalarioListener(SalarioListener listener){

salarioListeners.removeElement(listener);

}

private void notificarCambio(SalarioEvent event){

Vector lista;

synchronized(this){lista=(Vector)salarioListeners.clone();

}

for(int i=0; i

7/21/2019 POO PARTE 2

10/78



Para probar las clases Asalariado y Hacienda y comprobar como un objetode la primera clase notifica el cambio en el valor de una de sus propiedadesa un objeto de la segunda clase, creamos una aplicacin.

En dicha aplicacin, se crean dos objetos uno de cada una de las clases,

llamando a su constructor por defecto o explcito segn se requiera.Hacienda funcionario1=new Hacienda();

Asalariado empleado=new Asalariado();

La vinculacin entre el objeto fuente, empleado, y el objeto interesado enconocer el cambio en el valor de una de sus propiedades, funcionario1 serealiza mediante la siguiente sentencia.

empleado.addSalarioListener(funcionario1);

El objeto funcionario1 se aade a la lista (vector) de objetos interesados enconocer el nuevo sueldo del empleado. Podemos poner ms sentenciassimilares, para que ms funcionarios de Hacienda sean notificados de dichocambio.

Tambin podemos crear otra clase que se llame por ejemplo Familia, queimplemente la interfase SalarioListener y defina la funcinenteradoCambioSueldo.

Creamos objetos de esta clase, la mujer, los hijos, entre otros y los aadimos

mediante addSalarioListener a la lista de personas (listeners) interesadosen conocer la noticia.

Cuando escribimos la sentencia

empleado.setSueldo(50);

El objeto empleado llama a la funcin setSueldo que cambiala propiedad.

En el cuerpo de setSueldo, se comprueba que hay un cambio

en el valor del miembro dato sueldo. Se llama a la funcin miembro notificarCambio para dar a

conocer a los objetos interesados que se guardan en el vectorsalarioListeners el cambio en el valor de dicha propiedad.

En el cuerpo de notificarCambio, los objetos (listeners)interesados llaman a la funcin enteradoCambioSueldo.

Los objetos interesados que pueden ser de la misma clase ode distinta clase, siempre que implementen el intefaceSalarioListener, realizan en el cuerpo de la funcinenteradoCambioSueldo las tareas, no siempre oportunas,

con la informacin que se le proporciona a travs del objetoev de la clase SalarioEvent.

7/21/2019 POO PARTE 2

11/78



El cdigo completo de la aplicacin es el siguiente:

public class EjemploApp {

public static void main(String[] args) {

Hacienda funcionario1=new Hacienda();Asalariado empleado=new Asalariado();

System.out.println("----------------------------

");

empleado.addSalarioListener(funcionario1);

empleado.setSueldo(50);

}

}

2.2- Patrones

Concepto

Frases introductorias

Un patrn es una arquitectura reutilizable que la experiencia hamostrado que resuelve un problema comn en un contextoespecfico.

La idea de patrones existe desde dcadas anteriores, y su origen esaplicable a personas como el arquitecto Christopher Alexander quelos aplic a la arquitectura en los aos 70, se volvieron famosos afines de la dcada del 80, y en los 90, gracias a Coad, comienza eltrabajo del Gang of Four(GoF) sobre Patrones Orientados aObjetos.

El concepto de patrn, generalmente, lo aplicamos en la vida

cotidiana en diversos mbitos sin darnos cuenta, al menos de formaexplcita, de que los estamos utilizando.

Aplicamos patrones cuando se nos presentan situaciones enlas que conocemos el problema, la solucin el mtodo parapasar del problema sin resolver al resuelto.

Seguramente, la aplicacin del mtodo de resolucin vienemarcado por un patrn de comportamiento que se suelerepetir cuando se nos presenta el mismo problema.

7/21/2019 POO PARTE 2

12/78



Y es esta la esencia de los patrones: dado un determinado problema,aplicamos un mtodo conocido y comprobado que nos lleva al xitoen la resolucin de dicho problema, de una forma eficiente.

Cada patrn conlleva una descripcin de un problema que ocurre yde cmo solucionarlo, o sea que son estereotipos que utilizamos unay otra vez para solucionar problemas parecidos. Se pueden utilizartodas las veces que sea necesario, y adems, perfeccionarlos.

Por qu surgen los patrones?

En el paradigma Orientado a Objetos, uno de los pilares de la filosofa es laposibilidad de REUTILIZAR, es decir, hacer una sola vez los cdigos,experiencias, soluciones de anlisis y diseo y usarlos cada vez que hagafalta y que hemos aplicado anteriormente en otros proyectos o programas.

Generalmente, podemos identificar la necesidad del uso o descubrimientode patrones cuando se presenta alguna o varias de las siguientessituaciones:

Cuando un experto trabaja en un problema particular es inusual queproceda inventando una solucin completamente a alguna existente.(En caso de que suceda estamos posiblemente ante un cambio deparadigma de resolucin)

Suele recordar un problema similar ya resuelto y reutiliza la esenciade la solucin para resolver el problema nuevo.

Se puede llegar a pensar en pares problema/solucin, situacincomn en muchos dominios.

Abstraer elementos comunes de estos pares conduce a laidentificacin de patrones.

Caractersticas de los patrones de software

Un buen patrn:

Plantea una solucin un problema Provee conceptos (captura soluciones) Permite derivar soluciones desde primeros principios Describe relaciones Debe tener en cuenta al componente humano Atacan problemas de diseo que surgen recurrentemente en

situaciones especficas y presentan una solucin a ellos Documentan la experiencia existente en el diseo Identifican y especifican abstracciones que estn a un nivel mayor

de clases simples Proveen un vocabulario y entendimiento comn de principios de

diseo Soportan la construccin de software con propiedades definidas Ayudan a manejar la complejidad

7/21/2019 POO PARTE 2

13/78



En la orientacin a objetos, el patrn enfoca un solo aspecto de unproblema, y debe enfocarlo identificando:

Clases participantes Instancias Roles Colaboraciones

Adems, debe especificar:

Cuando aplicarlo Si debe o no debe ser aplicado. Es decir, debe especificar las

restricciones de uso Consecuencias de la aplicacin Que debe tenerse en cuenta cuando se lo est aplicando

Debe formularse estableciendo la relacin entre un contexto, unsistema y una configuracin que permita resolver el problema.

Beneficios

Mejora la comunicacin

Cmo podran varios arquitectos discutir el diseo deun edificio si solo conocieran la palabra LADRILLO?

Cmo podran los electrnicos disear fuentes si noexistiera la palabra RECTIFICADOR, solo resistencia,transistor, entre otros?

Productividad y calidad inmediatas cuando los equipos puedensostener discusiones de diseo desde un alto nivel

Se pueden aplicar los patrones inmediatamente aproblemas sin redescubrirlos

Pueden mejorar la documentacin por disponer de lasespecificaciones explcitas de clases e interacciones de

objetos.

Reutilizacin de los diseos

Ayudan a elegir un diseo alternativo que forma unsistema ms reutilizable.

Facilitan el mantenimiento del software.

En conclusin, los patrones ayudan a los diseadores a lograr un programacorrecto con:

7/21/2019 POO PARTE 2

14/78



Menos tiempo Ms flexibilidad Ms elegancia Mayor reutilizacin

Componentes de un patrn

Nombre Propsito Sinnimo Colaboraciones Contexto Explicacin Fuerzas Motivacin Ejemplos Patrones relacionados Aplicabilidad Estructura Participantes Consecuencias

Veamos algunos de estos elementos:

Nombre: Se debe poder describir con una o dos palabras un problema, sussoluciones y consecuencias. Generalmente es una analoga.Nominar un patrn incrementa el vocabulario de diseo y nos permitemodelar con un nivel de abstraccin ms alto.

Propsito:Describe cuando se puede aplicar el patrn. Explica elproblema y su contexto

Pueden ser problemas especficos tales como representar losalgoritmos con objetos.

Puede describir clases o estructuras de objetos que son sintomticosde un diseo flexible.

Puede incluir una lista de condiciones que se tienen que satisfacerantes de aplicar el patrn.

Explicacin:Describe los elementos que forman el diseo, sus relaciones,responsabilidades y cooperaciones que llevan a cabo la solucin

No se describe un diseo concreto de lenguaje

Es una plantilla para muchas situaciones diferentes

Es una descripcin abstracta de un problema de diseo y como seresuelve con elementos (clases y objetos) generales

7/21/2019 POO PARTE 2

15/78



Consecuencias: Son los buenos resultados e inconveniencias de suaplicacin; son crticas para evaluar el patrn y entender los costos ybeneficios de aplicarlo.

Suele relacionarse con el equilibrio entre el espacio y el tiempo. Puede

tratar asuntos del lenguaje e implementaciones.Para el diseo orientado a objetos describe, particularmente, la flexibilidad,extensibilidad y portabilidad.

2.2.1Clasificacin y especificaciones

Categora de los patrones

Los patrones se pueden agrupar de acuerdo a los distintos niveles deabstraccin utilizados en las diferentes etapas del proceso de desarrollo delsoftware.

En este captulo se har hincapi particularmente en los Patrones deDiseo. Luego, en captulos siguientes, se relacionarn los patrones dediseo con los de lenguaje para lograr su implementacin especfica.

Patrones de Arquitectura

Expresan esquemas fundamentales de organizacin estructural de sistemasde software donde la organizacin refiere a aspectos lgicos. Una de lasprimeras actividades en la definicin de una arquitectura es la subdivisingeneral del sistema en las partes que lo constituirn.

Proveen:

Un conjunto de subsistemas. Una especificacin de sus responsabilidades. Reglas y guas para organizar las relaciones entre ellos.

Los tipos de divisiones que podemos encontrar son:

Cliente/Servidor. Peer-to-Peer. MVC.

Se pueden presentar subdivisiones como:

Layers. Pipes & Filtres. Backbones.

Modelo o patrn MVC (Model View Controller)

Actualmente hay quienes discuten sobre el modelo MVC tratando deubicarlo por fin entre los patrones de arquitectura, de anlisis o de diseo, ya veces hasta se habla de implementacin. Lo cierto es que en cada una de

estas instancias, el modelo MVC parece tener un componente:

7/21/2019 POO PARTE 2

16/78

7/21/2019 POO PARTE 2

17/78



Durante el desarrollo del presente curso, se har utilizacin de esteconcepto y se intentar su implementacin mediante los trabajos prcticosde los talleres.

Patrones de Anlisis

Ayudan a identificar clases del modelo de dominio, sus atributos,comportamientos y las interacciones con otras clases. Una de las cosas ms

complicadas en Orientacin a Objetos consiste en elegir las clasesadecuadas y decidir cmo estas deben interactuar lograr el objetivo central

Modelo

HTML

JavaScript

javax.servlet /

System.Web

Clases

propietarias

ADO.NET /

JDBC

WebServices

EJB /

Hibernate /

NHibernate

Vista Controlador

ASP.NET /

JSP / PHP

AWT-SWING /

WINDOWS.FORMPaquete3

Capa Web

ModeloVista Controlador

Capa de modelo

Capa de datos

Capa de modeloCapa Web

Capa de modelo

Capa de cliente

7/21/2019 POO PARTE 2

18/78



del sistema. Esto ha llevado a distintos estudios, los que han dado comoresultado a los denominados patrones GRASP (General ResponsabilityAssignment Software Patterns o Patrones de Software Generales deAsignacin de Responsabilidades). Entre los que encontramos:

Bajo Acoplamiento:Debe haber pocas dependencias entre las clases. Sitodas las clases dependen de todas cunto software podemos extraer de unmodo independiente y reutilizarlo en otro proyecto? Para determinar elnivel de acoplamiento de clases, son muy buenos los diagramas decolaboracin de UML. Uno de los principales sntomas de un mal diseo yalto acoplamiento es una herencia muy profunda. Siempre hay queconsiderar las ventajas de la delegacin respecto de la herencia.

Alta Cohesin: Cada elemento de nuestro diseo debe realizar una labornica dentro del sistema, no desempeada por el resto de los elementos yauto-identificable. Ejemplos de una baja cohesin son clases que hacendemasiadas cosas. En todas las metodologas se considera larefactorizacin. Uno de los elemento a refactorizar son las clases saturadasde mtodos. Ejemplos de buen diseo se producen cuando se crean losdenominados paquetes de servicio o clases agrupadas por funcionalidadesque son fcilmente reutilizables (bien por uso directo o por herencia).

Experto:La responsabilidad de realizar una labor es de la clase que tiene opuede tener los datos involucrados (atributos). Una clase, contiene toda lainformacin necesaria para realizar la labor que tiene encomendada. Hayque tener en cuenta que esto es aplicable mientras estemos considerandolos mismos aspectos del sistema:Lgica de negocioPersistencia a la base de datosInterfaz de usuario

Creador:Se asigna la responsabilidad de que una clase B cree un Objetode la clase A solamente cuandoB contiene a AB es una agregacin (o composicin) de AB almacena a AB tiene los datos de inicializacin de A (datos que requiere su constructor)B usa a A.La creacin de instancias es una de las actividades ms comunes en unsistema orientado a objetos. En consecuencia es til contar con un principiogeneral para la asignacin de las responsabilidades de creacin. Si se

asignan bien el diseo puede soportar un bajo acoplamiento, mayorclaridad, encapsulamiento y reutilizacin.

Controlador:Asignar la responsabilidad de controlar el flujo de eventosdel sistema, a clases especficas. Esto facilita la centralizacin de actividades(validaciones, seguridad, entre otros). El controlador no realiza estasactividades, las delega en otras clases con las que mantiene un modelo dealta cohesin. Un error muy comn es asignarle demasiada responsabilidady alto nivel de acoplamiento con el resto de los componentes del sistema.

7/21/2019 POO PARTE 2

19/78



Patrones de Lenguaje

Ayudan a implementar aspectos de diseo particulares en un lenguaje deprogramacin especfico. Los define la propia plataforma de desarrollocomo en el caso de .NET, Java, C++, entre otros.

Patrones de Diseo

Ayudan a refinar los subsistemas o componentes de un sistema software.Describen una estructura a la cual muchas veces recurrimos para resolverproblemas de diseo. Se caracterizan por:

Colaborar con la arquitectura del sistema Son independientes del lenguaje de implementacin, Permiten resolver problemas complejos Dirigen la cooperacin efectiva entre componentes

2.2.2. Especificaciones de los patrones

de diseo

Patrones de Creacin

Abstraen el procesos de instanciacin haciendo al sistema independiente decmo los objetos son creados, compuestos o representadosEncapsulan el mecanismo de creacinIndependencia de los tipos de objetos producto que manejamos

Los patrones que pertenecen a este grupo son: Abstract Factory Factory Method Builder Prototype Singleton

Abstract Factory

Propsito: Proporciona una interfaz para crear las familias de objetos

relacionados o subordinados sin especificar sus clases concretas

Motivo: Considere una paquete o mdulo de interfaces que soportamltiples Look & Feel predeterminados, tales como Motif yPresentation Manager. Diferentes Look & Feel definen diversos aspectos ycomportamientos para los distintos controles como barras dedesplazamiento, ventanas, y botones. Para ser portables a travs de estospaquetes de interfaces, una aplicacin no debera utilizar controlesespecficos de un Look & Feel en particular, ya que esto complicaimplementar un estilo distinto en el futuro.

Podemos resolver este problema definiendo una clase abstracta

UIControlFactory que declare una interfaz para crear cada uno de los tiposde controles. Tambin existir una clase abstracta por cada tipo de control

7/21/2019 POO PARTE 2

20/78



Un sistema debe permanecer independiente de cmo sus productosson creados, compuestos y representados.

Un sistema debe configurarse con una de mltiples familias deproductos.

Una familia de productos relacionados est diseada para ser usada enconjunto, y se necesita hacer cumplir esta regla.

Se pretende proveer una librera de productos, y solo se quierenexponer sus interfaces, no sus implementaciones

Estructura:

Figura 2 Estructura del patrn Abstract Factory

+CreateProductA()

+CreateProductB()

AbstractFactory

+CreateProductA()

+CreateProductB()

ConcreteFactory1

AbstractProductA

ProductA1 ProductA2

ProductB1 ProductB2

AbstractProductB

Cliente

+CreateProductA()

+CreateProductB()

ConcreteFactory2

*

*

**

*

*

diferente, y las clases concretas de los tipos de controles dependern decada L&F. La interfaz expuesta de UIControlFactory tiene un mtodo queretorna un control nuevo por cada una de las clases abstractas de controles.El cliente llama a estos mtodos para obtener instancias de los controles,pero no conoce cul es la clase concreta que se est instanciando. De estamanera, el cliente se mantiene independiente del L&F seleccionado.

Aplicacin: El patrn Abstract Factory se puede usar cuando:

7/21/2019 POO PARTE 2

21/78



Factory Method

Propsito: Proporciona una interfaz para crear objetos, pero le deja a lassubclases decidir qu clase instanciar.

Motivo: Los Frameworks utilizan clases abstractas para definir y mantener

relaciones entre objetos, adems de ser el responsable de crear estosobjetos.

Consideremos entonces un framework para aplicaciones que es capaz depresentar mltiples tipos de documentos a los usuarios. Dos abstraccionesclaves en este framework son las clases Aplicacin y Documento. Ambasclases son abstractas y los clientes deben heredarlas para llevar a cabo laimplementacin especfica. Para crear una aplicacin de dibujo, porejemplo, definimos las clases AplicacionDibujo y DocumentoDibujo. Laclase Aplicacion es la responsable de manejar los objetos del tipoDocumento, y los crear cuando que se necesario (opcin Nuevo, Abrir,entre otros).

Debido a que la subclase DocumentoDibujo de Documento tiene unaimplementacin especfica, la clase Aplicacion no puede predecir quesubclase de Documento instanciar (la clase Aplicacion solo sabe cuandocrear un Documento, pero no sabe que tipo de Documento). Esto presentaun dilema: El framework debe crear objetos, pero solo conoce clasesabstractas, que no se pueden instanciar.

Figura 3 Ejemplo de aplicacin de documentos

El patrn Factory Method ofrece una solucin. Encapsula el conocimientode que subclase de Documento crear, y lo saca fuera del framework.

Las subclases de Aplicacion redefinen un mtodo abstractoCrearDocumento para retornar la subclase apropiada de Documento. Unavez que una subclase de Aplicacion es instanciada, puede crear objetos deltipo.

Documento especficos para la aplicacin en cuestin. Llamamos aCrearDocumento un Factory Method porque es el responsable de fabricarun objeto.

+Abrir()

+Cerrar()

+Guardar()

Documento

DocumentoDibujo

+CrearDocumento()

+NuevoDocuemnto()

+AbrirDocumento()

Aplicacion

+CrearDocumento()

AplicacionDibujouses

Documento doc=CrearDocumento();

docs.Add(doc);

doc.Abrir();

return new DocumentoDibujo

7/21/2019 POO PARTE 2

22/78



Aplicacin: El patrn Factory Method se puede usar cuando:

Una clase no puede anticipar la clase de objeto que debe crear Una clase lleva a que sus subclases especifiquen el objeto que esta

creaLas clases delegan responsabilidades a una o varias clases de ayuda oHelper Subclasses, y UD. quiere localizar el conocimiento de cual clase deayuda es la delegada.

Estructura:

Figura 4 Estructura del patrn Factory Method

Participantes:

Product: define la interfaz de objetos que el Factory Method crea ConcreteProduct: implementa la interfaz Product Creator: declara el Factory Method, que retorna un objeto del tipo

Product. Puede definir una implementacin predeterminada delFactory Method que retorna un objeto ConcreteProductpredeterminado. Puede llamar al Factory Method para crear elobjeto Product.

ConcreteCreator: Sobrecarga el Factory Method para retornar unainstancia de ConcreteProduct.

Colaboraciones:

Elimina la necesidad de enlazar clases especficas en el cdigo. Solose manejan las interfaces de Product, por lo tanto no se manejaninstancias de ConcreteProduct directamente.

Una desventaja potencial se da cuando el cliente tiene que heredarde Creator para crear un tipo de ConcreteProduct ms especficoque los que se estn creando hasta este punto. No es una prcticamala, pero el cliente ya tiene que enfrentarse a un nuevo punto deevolucin en esta arquitectura.

Permiten conectar jerarquas paralelas de clases. Esto se da cuandotenemos un Factory Method aplicado a objetos del dominio, y se

Product

ConcreteProduct

+FectoryMethod()

Cretor

+FactoryMethod()

ConcreteCreatoruses

...

product=FactoryMethod()

...

return new ConcreteProduct

7/21/2019 POO PARTE 2

23/78



desea separar algunas de sus responsabilidades en clases de ayuda,las cuales se pueden organizar tambin en Factory Method paradefinir los comportamientos especficos de los distintosConcreteProdcuts.

Figura 5 Ejemplo de la relacin entre 2 jerarquas de clases que utilizan Factory Method

Builder

Propsito:Separar la construccin de objetos complejos de su

representacin para, mediante el mismo proceso de construccin, creardiferentes representaciones.

Motivo:Un mdulo de lectura de archivos RTF debera ser capaz detransformar a distintos formatos de texto, como PDF, XML, Texto planoASCII o a un formato de especfico de un determinado control de edicininteractiva. El problema, sin embargo, existe en que los formatos deconversin posibles pueden ser muchos, por lo tanto, agregar un formatonuevo, debera ser simple y no debera modificar el lector.

Una solucin es configurar la clase LectorRTF con la clase ConversorTexto

para convertir de un formato a otro. Cada vez que LectorRTF analiza undocumento RTF, utiliza ConversorTexto para convertirlo. En el momentoen que LectorRTF reconoce un smbolo RTF, enva una peticin aConversorTexto para que lo convierta. Esta ltima es la encargada derealizar la conversin y de representarlo en el formato solicitado.

Subclases de ConversorTexto se especializan en diferentes conversiones yformatos. Por ejemplo, ConversorTextoPlano ignora cualquier cadena queno se texto plano. ConversorPDF implementa mtodos para todas laspeticiones y as obtener un documento PDF. ConversorEditor generaobjetos complejos de interfaz de usuario para permitir visualizar y

modificar el documento.

+CrearManipulador()

Figura

+CrearManipulador()

Linea

+CrearManipulador()

Circulo

+Click()

+Drag()

+Resize()

Manipulador

+Click()

+Drag()+Resize()

ManipuladorCirculo

+Click()

+Drag()+Resize()

ManipuladorLinea

Clase12

* *

**

7/21/2019 POO PARTE 2

24/78



Figura 6 Ejemplo de Conversor de texto

Cada tipo de conversor utiliza los mecanismos necesarios para obtenerobjetos complejos segn su naturaleza, y los pone detrs de una interfaseabstracta, separando la lgica de conversin de la del lector.

El patrn Builder captura todas estas relaciones. Cada clase de conversines llamada un Builder, y el lector es llamado Director. Aplicado a esteejemplo, el patrn separa los algoritmos para interpretar un formato dado(en este caso RTF) de cmo crear y representar dicho formato en otro(Texto plano, PDF, entre otros).

Aplicacin:El patrn Builder se puede usar cuando:

Los algoritmos para crear objetos complejos deban serindependientes de las partes que modifican el objeto

El proceso de construccin debe permitir diferentesrepresentaciones para el objeto que se ha construido

Estructura:

Figura 7 Estructura del patrn Builder

+ParsearRTF()

LectorRTF

+ConvertirCaracteres()

+ConvertirFuente()

+ConvertirParrafo()

ConversorTexto


+GetTextoPlano()

ConversorTextoPlano


+ConvertirFuente()

+ConvertirParrafo()

+GetPDF()

ConversorPDF


+ConvertirFuente()

+ConvertirParrafo()

+GetEditor()

ConversorEditor

1 *

+Construir()

Director

+ConstruirParte()

Builder

+ConstruirParte()

+GetResultado()

ConcreteBuilder

1 *

Product

7/21/2019 POO PARTE 2

25/78



Participantes:

Builder: especifica una interfase abstracta para crear partes de unobjeto Product.

ConcreteBuilder: construye y ensambla partes de un Productimplementando la interfase Builder. Define y mantiene estados de larepresentacin que l crea. Provee una interfase para obtener elProduct.

Director: construye un objeto utilizando la interfase Builder. Product: representa el objeto bajo construccin. ConcreteBuilder

construye la representacin interna del Product y define las reglasde cmo se ensambla. Incluye clases que definen las partesconstitutivas, y las interfaces para ensamblar las partes en unproducto final.

Colaboraciones:

1. El cliente crea un objeto Director y lo configura con el Builderdeseado2. El objeto Director notifica al Builder cuando se debe construir una

parte del Product3. El objeto Builder maneja el requerimiento hecho por el Director y

agrega una parte nueva al Product4. El objeto Director obtiene la representacin del Product desde el

Builder

Figura 8 Ejemplo de construccin de un objeto

unCliente unDirector unConcreteBuilder

new ConcreteBuilder()

new Director(unConcreteBuilder)

Construir()ConstruirParteA()

ConstruirParteB()

ConstruirParteC()

GetResultado()

7/21/2019 POO PARTE 2

26/78

7/21/2019 POO PARTE 2

27/78



Figura 9 Ejemplo de editor de msica

Se puede reducir el nmero de subclases en este ejemplo haciendo que lasclases padre como Nota Musical sea el caso ms general, y que las distintasnotas (redonda, blanca, negra, entre otros.) sean instancias de Nota Musicalcon distinta imagen y duracin.

Aplicacin: El patrn Prototype se puede usar cuando:

Las clases a instanciar son especificadas en tiempo de ejecucin Para evitar construir jerarquas de Factories que son paralelas a

jerarquas de ProductosUna instancia de una clase puede ir pasando de estados, es convenienteparametrizar los tipos de estados y clonar la instancia cambindole elestado, en lugar de instanciar la clase que contiene el estado especfico.

Estructura: Figura 10 Estructura del patrn Prototype

+Manipular()

Herramienta

+Manipular()

HerramientaRotacion

+Manipular()

HerramientaGrafica

+Dibujar(posicion)()

+Clonar()()

Grafico


+Clonar()()

ClaveNotaMusical


+Clonar()

Redonda


+Clonar()

Corchea

p=prototipo.Clonar();

while(Mouse.Drag)

{

p.Dibujar(nueva posicion);

}

Sucede cuando se arrastra un icono de

la Toolbar al documento

1

*

Retornan copias de si mismas

+Metodo()

Cliente

+Clonar()()

Prototype

+Clonar()()

ConcretePrototype1

+Clonar()

ConcretePrototype2

p=prototipo.Clonar();

Retornan copias de si mismas

* *

7/21/2019 POO PARTE 2

28/78



Participantes:

Prototype: declara una interfase para clonarse a s mismo ConcretePrototype: implementa el mtodo que le permite clonarse

Cliente: crea un nuevo objeto solicitando al Prototype que se clone asi mismo

Colaboraciones: El cliente solicita al prototipo que se clone a si mismo

Consecuencias:

Ocultan al cliente los objetos concretos Se pueden agregar y quitar objetos productos en tiempo de

ejecucin Permite especificar nuevos objetos con solo cambiar los valores,

mediante la clonacin

Reduce el nmero de subclases

Singleton

Propsito:Asegura que exista solo una instancia de una clase, y provee unpunto de acceso global a ella.

Motivo: Es importante para determinadas clases que solo exista unainstancia de ellas. Si bien puede haber muchas impresoras configuradas enun sistema, seguramente solo existir una sola cola de impresin que lasadministre.

Para lograr esto hacemos que la propia clase se la encargada de la creacin yseguimiento de su nica instancia. Para asegurar que solo existe unainstancia, la clase intercepta cualquier intento de creacin y devuelve lamisma instancia.

Aplicacin: El patrn Singleton se puede usar cuando:

Debe existir solo una instancia de determinada clase, y debe ser accesibledesde puntos de acceso bien conocidos y definidos.

Estructura:

Figura 11 Estructura del patrn Singleton

+getInstance()

+OtrosMetodos()

-static uniqueInstnace

-otrosAtt

Singleton

retorna uniqueInstance

7/21/2019 POO PARTE 2

29/78



Participantes:

Singleton: Define un mtodo GetInstance que le permite a losclientes acceder a su nica instancia. Generalmente es responsabletambin del mecanismo de creacin de s misma.

Colaboraciones: El cliente accede a la instancia mediante el mtodoGetInstance

Consecuencias:

Puede controlar el acceso a su instancia Permite controlar el nmero de instancias, ya que puede ser que en

lugar de 1 necesitemos 3. Teniendo como base este patrn se puedelograr fcilmente esta opcin

Es un refinamiento de las variables globalesPermite mayor flexibilidad que los mtodos estticos de clases

Patrones estructurales

Los patrones estructurales nos describen como formar estructurascomplejas a partir de elementos ms simples. Nos muestran como laherencia puede ser utilizada para proporcionar mayor funcionalidad, o enotros casos, como comunicar objetos incompatibles o con soporte en otrasversiones.

Los patrones que pertenecen a este grupo son:

Adapter Bridge Composite Decorador Facade Flyweight Proxy

Adapter

Propsito: Convierte la interfase de una clase en otra interfase que es laque espera el cliente. Permite que clases con interfases incompatibles

puedan trabajar juntas.

Motivo: Debido a que ciertas clases de utilidad que tenemos desarrolladasque, supuestamente, deberan ser reutilizables, simplemente no lo sondebido a una incompatibilidad con las interfases de las clases propias deldominio de la aplicacin actual.

Consideremos el caso de un editor grfico que le permite al usuario dibujary mover elementos grficos como lneas, polgonos y cuadros de textodentro de imgenes o diagramas. La abstraccin principal del editor estconformada por la clase abstracta Forma Grfica. A su vez, el editor define

subclases de Forma Grfica para cada tipo de grfico distinto, como LneaGrfica para las lneas, Polgono Grfico para polgonos, entre otros.

7/21/2019 POO PARTE 2

30/78



Estas clases son relativamente fciles de implementar debido a que suscapacidades de edicin y dibujo son limitadas por la herencia. Pero la claseTexto Grfico que puede editar texto dentro de ella, es considerablementems difcil de implementar dado que la simple edicin de texto lleva unautilizacin complicada de buffers y refrescos de pantalla. A su vez, el editor

cuenta con una clase sofisticada de visualizacin y edicin de textodenominada Visualizador Texto. Lo ideal sera reutilizar Visualizador Textopara implementar Texto Grfico, pero la herramienta de edicin de texto nofue diseada desde un principio teniendo en cuenta la clase Forma Grfica,por lo tanto, la intercomunicacin entre estas clases se complica.

Se podra pensar modificar Visualizador Texto para que trabaje con lainterfase de Forma Grfica, pero para esto deberamos contar con el cdigofuente de las herramientas de texto, y aun as, no sera correcto hacerlo yaque las herramientas de texto no deberan adoptar el comportamiento deinterfases especificas al dominio del problema para hacer que esta

aplicacin funciones.En lugar de eso, podemos definir Texto Grfico para que adapte la interfasede Visualizador Texto a la de Forma Grfica. Esto se puede lograr de 2formas: 1- heredando la interfase de Forma Grfica y la implementacin deVisualizador Texto, o 2- utilizar una instancia de Visualizador Texto dentrode Texto Grfico e implementando esta misma en trminos de la interfasede Visualizador Texto. Estas 2 formas corresponden a las versiones de Clasey Objetos del patrn Adapter respectivamente. Llamamos Adapter oadaptador a la clase Texto Grfico.

Figura 12 Ejemplo del editor grfico

Se ilustra para este ejemplo la versin de Objetos del patrn. Se muestracomo las llamadas al mtodo Dimensionar Caja() declarado en la claseForma Grfica se transforma en llamadas al mtodo Acomodar Texto(),definido en Visualizador Texto. Podemos ver como Texto Grfico adapta eluso de la clase Visualizador Texto a la interfase de Forma Grfica. Ahora, eleditor grfico, puede utilizar las herramientas de texto, que antes eranincompatibles.

Aplicacin: El patrn Adapter se puede usar cuando:

Se necesita utilizar determinada clase, pero no se cuenta con lainterfase necesaria para el caso particular

EditorGrafico

+DimensionarCaja()

FormaGrafica

+DimensionarCaja()

LineaGrafica

+DimensionarCaja()

TextoGrafico

+AcomodarTexto()

VisualizadorTexto

* *

*

*

return text.AcomodarTexto()

7/21/2019 POO PARTE 2

31/78



Se desea crear clases reutilizables (framework) para que cooperencon clases desconocidas o no tienen, necesariamente, una interfasecompatible

Se necesita utilizar una serie de subclases, pero se vuelve muy tediosoadaptarlas mediante herencia a cada una. Un Adapter de Objetos puedeadaptar la interfase de la clase padre.

Estructura:

Figura 13 Estructura del Adapter de Clase

Figura 14 Estructura del Adapter de Objeto

Participantes:

Target: define la interfase especifica del dominio del problema que

el Cliente usa Cliente: utiliza con otros objetos la interfase Target Adaptee: define la interfase que necesita ser adaptada Adapter: adapta la interfase de Adpatee a la de Target

Colaboraciones: El Cliente llama a los mtodos de la interfase Adapter.sta llama a los mtodos de Adaptee para solucionar la peticin

Consecuencias: Las versiones de Adapter se diferencian entre s:

El Adapter de Clase:

liente

+Request()

Target

+Request()

dapter

+SpecificRequest()

daptee

* *

SpecificRequest()

Cliente

+Request()

Target

+Request()

Adapter

+SpecificRequest()

Adaptee

* *

Adaptee.SpecificRequest()

*

*

7/21/2019 POO PARTE 2

32/78



Adapta la interfase Adpatee a la de Target mediante una claseAdapter concreta. Por lo tanto no funciona para cuando se deseaadaptar un clase y todas sus subclases

La clase Adapter puede extender el comportamiento de Adaptee, yaque es una subclase de ella

Introduce solamente un objeto, y no se necesitan referenciasadicionales o indirectas para acceder a Adaptee

El Adapter de Objeto:

Un solo Adapter trabaja con al Adaptee y todas sus subclases, ypuede agregar funcionalidad a todos los Adaptee

Hace ms difcil de extender el comportamiento de Adaptee. Estorequiere herencia y que el Adapter haga referencias a las subclasesen lugar de la clase padre

Generalmente, el trabajo de adaptar una interfase a otra disminuye cuando

la incompatibilidad entre las mismas es mnima.

Bridge

Propsito: Separa una abstraccin de su implementacin, as las dospueden variar independientemente

Motivo: Cuando una abstraccin puede tener una de variasimplementaciones, la forma ms usual de organizarlas es la herencia. Laclase abstracta define las interfases para la abstraccin, y las subclasesconcretas las implementan en las formas necesarias. Pero este tipo desolucin no siempre es lo suficientemente flexible. La herencia une unaimplementacin a su abstraccin, haciendo difcil la modificacin,extensin y reutilizacin de ambas independientemente, o por separado.

Consideremos la implementacin de un framework de Interfaces Graficasde Usuario (GUI) portable, que pueda ser utilizado para escribiraplicaciones tanto en X Window como en Win32. Utilizando herenciapodramos definir una clase abstracta Window y las subclases XWindow yWWindow que implementan la interfase Window para las distintasplataformas. Esta solucin tiene 2 desventajas:

Se torna inconveniente agregar un nuevo tipo de ventana o unanueva plataforma. Por un lado, para el caso de un nuevo tipo deventana, debemos crear tantas subclases como plataformastengamos, e implementarlas en trminos de ellas. Por el otro, en elcaso de otra plataforma, debemos replicar la jerarqua para soportarlos distintos tipos de ventanas.

Hace que el cdigo del cliente sea dependiente de la plataforma.

Cada vez que el cliente crea una ventana, instancia una claseconcreta que tiene una implementacin especfica para laplataforma. Por ejemplo, si creamos un objeto XWindow, la

7/21/2019 POO PARTE 2

33/78



abstraccin Window queda unida a la implementacin de laplataforma X Window, lo que hace que la aplicacin sea menosportable. El cliente debera poder crear objetos de formatransparente, y que solamente la implementacin de las ventanasdependa de la plataforma, y no su aplicacin.

El patrn Birdge trata estos problemas poniendo la abstraccin Window ysu implementacin en diferentes jerarquas de de herencia. Existirnentonces 2 jerarquas, una para los distintos tipos de ventanas (Window,IconWindow, ModalWindow), y otra jerarqua para sus implementacionesespecficas de acuerdo a la plataforma.

Figura 15 Ejemplo en el framework de Ventanas

Todos los mtodos de las subclases de Window son implementadosmediante mtodos abstractos de las interfaces de WindowImp. Esto separala abstraccin de las ventanas de su implementacin en las distintasplataformas. Nos referimos a la relacin entre Window y WindowImp comoun Bridge o puente, que permite que ambas varen independientementeentre s.

Aplicacin:El patrn Bridge se puede usar cuando:

Para evitar unir permanentemente una abstraccin de suimplementacin.

Tanto la abstraccin como la implementacin deban ser extensiblesmediante herencia

Cambios en la implementacin de la abstraccin no impliquecambios en los clientes (que el cliente no deba recompilar)

Para ocultar completamente la implementacin a los clientes.

+DibujarTexto()

+DibujarRectangulo()

Window

+DibujarBorde()

IconWindow

+DibujarBorderFijo()

ModalWindow

+ImpDibujarTexto()

+ImpDibujarLinea()

WindowImp

+ImpDibujarTexto()

+ImpDibujarLinea()

XWindowImp

+ImpDibujarTexto()

+ImpDibujarLinea()

WWindowImp

DibujarRectangulo()

DibujarTexto()

WindowImp.ImpDibujarLinea()WindowImp.ImpDibujarLinea()

WindowImp.ImpDibujarLinea()

WindowImp.ImpDibujarLinea()

XDibujarLinea() XDibujarString()

7/21/2019 POO PARTE 2

34/78



Estructura:

Figura 16 Estructura del patrn Bridge

Participantes:

Abstraction: define la interfase de abstraccin. Mantiene unareferencia a Implementor Refined Abstraction: extiende la interfase definida por Abstraction Implementor: define la interfase para las clases de implementacin.

Generalmente, Implementor provee mtodos primitivos, mientrasque Abstraction provee mtodos de un nivel ms alto, queinvolucran a los primitivos

Concrete Implementor: implementa la interfase Implementor y define laimplementacin concreta

Colaboraciones:Abstraction transmite las peticiones del cliente a suobjeto Implementor

Consecuencias:

Separa las abstracciones de sus implementaciones. Esto evita,inclusive, la dependencia en tiempo de compilacin.

Permite extender las jerarquas de Abstraction e Implementorindependientemente.

Oculta los detalles de implementacin a los clientes

Composite

Propsito: Compone objetos en estructuras de rbol para representarjerarquas todo-partes.

Motivo:Aplicaciones grficas como los editores de dibujo o de esquemaspermiten a los usuarios crear diagramas complejos a partir de objetossimples. El usuario puede agrupar estos objetos para formar objetos msgrandes, los que a su vez pueden volver a agruparse. Una implementacinsimple de este tema puede distinguir entre las clases primitivas como Textoo Linea, conjuntamente con las clases que actan como contenedoras oagrupadoras.

Pero se nos presenta un problema: El cdigo que utiliza estas clases debedistinguir entre los 2 tipos, primitivos y contenedores, aun cuando el

+Metodo()

Abstraction

+DibujarBorde()

RefinedAbstraction

+MetodoImp()

Implementor

+MetodoImp()

ConcreteImplementorA

+MetodoImp()

ConcreteImplementorB

Implementor.MetodoImp()

7/21/2019 POO PARTE 2

35/78



usuario los utiliza de la misma manera. El solo reconocimiento de estadiferencia, hace la aplicacin ms compleja. El patrn Composite describecomo el uso de la composicin recursiva evita evaluar esta diferencia.

Figura 17 Ejemplo de la aplicacin de graficacin

La clave del patrn Composite es una clase abstracta que representa tanto alprimitivo como al contenedor. Para el sistema de grficos, esta clase esGrafico, que declara mtodos como Dibujar, que pertenece a todos losprimitivos, adems de los mtodos necesarios que necesitan manejar loscontenedores, como Agregar, Borrar, GetHijo, entre otros.

Las subclases Linea, Rectangulo, Texto se definen como objetos primitivos eimplementan el mtodo Dibujar. Mientras que la clase Imagen define unaagregacin de la clase Grafico e implementa el mtodo Dibujar para llamaral respectivo Dibujar de sus clases contenidas, y los mtodos relacionados

con el manejo de los primitivos contenidos.

Aplicacin: El patrn Composite se puede usar cuando:

Se desea representar jerarquas del tipo Todo- Partes.

Se desea abstraer al cdigo cliente de la diferenciacin entre objetoscompuestos y primitivos.

Estructura:

Figura 18 Estructura del patrn Composite

+Dibujar()

+Agregar()

+Borrar()

+GetHijo()

Grafico

+Dibujar()

Linea

+Dibujar()

Rectangulo

+Dibujar()

Texto +Dibujar()

+Agregar()

+Borrar()

+GetHijo()

Imagen

foreach g in glist do

g.Dibujar();

+Metodo1()

+Metodo2()

+Metodo3()

Component

+Metodo1()

Leaf+Metodo1()

+Metodo2()

+Metodo3()

Composite

foreach g in list do

g.Metodo1();

Cliente

7/21/2019 POO PARTE 2

36/78



Figura 19 Estructura tpica de una jerarqua de objetos utilizando Composite

Participantes:

Component: declara la interfase para los objetos de la composicin.Implementa el comportamiento comn a todas las clases. Declarauna interfase para acceder y manejar los objetos que contiene, yocasionalmente, declara otra interfase para manejar a los objetoscontenedores padres.

Leaf: representan las partes del a composicin. No puede tenerhijos. Definen el comportamiento de los objetos primitivos.

Composite: define el comportamiento de los componentes que serncontenedores. Guarda objetos Leaf y Composite. Implementa lasoperaciones relacionadas con los objetos contenidos de la interfaseComponent

Cliente: manipula los objetos de la composicin a travs de lainterfase Component.

Colaboraciones: El cliente utiliza la interfase Component parainteractuar con los objetos en la estructura de composicin. Si eldestinatario es un objeto Leaf, la peticin se maneja directamente. Si es unComposite, generalmente este la enva al objeto hijo correspondiente, yposiblemente, ejecuta lgica adicional antes o despus de la peticin.

Consecuencias:

Define jerarquas de clases que consisten en objetos primitivos ycompuestos. Los compuestos estn formados por primitivos ycompuestos recursivamente.

El cdigo cliente se comunica uniformemente tanto con objetosprimitivos como con los compuestos

La agregacin de nuevas clases, primitivas o compuestas, es deimplementacin fcil y transparente. Evitan cambios en el cdigocliente.

Como desventaja, al ser fcil de agregar nuevos objetos, se torna difcilrestringir la cantidad de objetos compuestos que podemos utilizar.

aComposite

aLeaf aLeaf aComposite aLeaf

aLeaf aLeaf aLeaf

7/21/2019 POO PARTE 2

37/78



Decorator

Propsito:Agregar responsabilidades nuevas a un objeto dinmicamente.Proveen una alternativa flexible para extender el comportamiento de lasclases en lugar de la herencia.

Motivo:Algunas veces solo deseamos agregar funcionalidad a un objeto enparticular, y no a toda la clase. Por ejemplo, un conjunto de herramientaspara crear GUIs, debera permitir agregar propiedades como bordessombreados, o comportamientos como poder hacer scroll en cualquiercomponente.

Una forma de agregar estas capacidades es a travs de la herencia.Heredando el control de alguna clase que aplique los bordes, lo podemoslograr, pero se torna inflexible debido a que el uso de esa clase siempreimplica el uso de bordes, no permitiendo que el usuario pueda decidir si

poner borde o no.

Una aproximacin ms flexible hacia este punto es incluir dichocomponente en un objeto que le agregue el borde. Este objeto es llamadodecorador o Decorator. Este objeto tiene la misma interfase que el

componente al que decora, entonces su manipulacin es transparente parael cdigo cliente, y permite colocar varios niveles de decoradores. El

Decorator puede ejecutar acciones adicionales, antes o despus de pasar lapeticin al componente.

Figura 20 Ejemplo de Decorator

Por ejemplo, veamos sino un editor de texto como los que hay en elmercado. Todos cuentan con un componente donde se escribe el texto, elcual puede o no ser plano. En caso de que sea plano, no necesitar ningnDecorator, pero si le deseamos agregar color de fondo, subrayado, negrita,vietas, entre otros, cada una de estas funciones se corresponden con undecorador que las lleva a cabo.

BorderDecorator

ScrollDecorator

EditorTexto

7/21/2019 POO PARTE 2

38/78



Figura 21 Composicin de decoradores con sus componentes

En este caso los distintos objetos decoradores heredan de Decorador, que asu vez est compuesto por objetos del tipo ComponenteVisual. Estacomposicin es la que nos permite utilizar los distintos decoradores en lasclases componentes.

Figura 22 Estructura de clases del ejemplo

Aplicacin: El patrn Decorator se puede usar cuando:

Se desea agregar comportamiento a objetos individualesLa extensin mediante herencia es imposible, debido a la extremacomplejidad que puede acarrear o a que las clases no se pueden heredar porestar declaradas como finales.

+Dibujar()

VisualComponent

+Dibujar()

EditorTexto

+Dibujar()

Decorator

component.Dibujar

+Dibujar()

+DibujarBorde()

-anchoBorde

BorderDecorator

+Dibujar()

+ScrollTop()+ScrollBottom()

-posicionScroll

ScrollDecorator

Decorator.Dibujar()

DibujarBorde()

aBorderDecorator

aScrollDecorator

aEditorTexto

component

component

7/21/2019 POO PARTE 2

39/78



Estructura:

Figura 23 Estructura del patrn Decorator

Participantes:

Component: define la interfase para los objetos que pueden tenerresponsabilidades agregadas dinmicamente

ConcreteComponent: define los objetos a los que se les puedeagregar comportamiento dinmico

Decorator: mantiene una referencia al objeto Component y define lamisma interfase que este ConcreteDecorator: agrega responsabilidad al Component.

Colaboraciones: El Decorator enva las peticiones a su objetoComponent. Puede ejecutar comportamiento antes o despus de enviar lapeticin.

Consecuencias:

Es ms flexible que la herencia esttica Evita las clases recargadas de comportamientos en los niveles altos

de la jerarqua de la herencia No es posible utilizar o confiar en la identidad de un objeto cuando

usa decoradores, porque no estamos tratando con el objeto en si,sino con otro objeto que lo abarca

Puede promover la proliferacin de objetos pequeos.

Facade

Propsito: Provee una interfase unificada y de alto nivel a un conjunto deinterfases de un subsistema, hacindolo ms fcil de usar.

Motivo: Estructurar un sistema mediante la separacin de subsistemasayuda a reducir la complejidad. Adems, siempre es deseable minimizar

+Metodo()

Component

+Metodo()

ConcreteComponent

+Metodo()

Decorator

component.Metodo()

+Metodo()

+Comportamiento()

ConcreteDecoratorB

+Metodo()

-estado

ConcreteDecoratorA

Decorator.Metodo()Comportamiento()

7/21/2019 POO PARTE 2

40/78



comunicaciones y dependencias entre estos subsistemas. Una forma delograrlo es introduciendo un objeto de fachada que provea una interfase

simple para las facilidades generales que provee un subsistema.

Figura 24 Ejemplo de utilizacin del patrn Facade

Consideremos, por ejemplo, un entorno de programacin que da acceso alas aplicaciones a su subsistema de compilacin. Este subsistema contieneclases como Scanner, Parser, ProgramNode, BytecodeStream yProgramNodeBuilder que sirven para implementar el compilador. Algunasaplicaciones pueden necesitar acceder a estas clases directamente, pero, lamayora de los programas que realizan una compilacin, no necesitan saberdetalles de cmo utilizar Parser o Scanner, simplemente necesitancompilar, por lo tanto, proveerles una interfase de bajo nivel, les complicala tarea.

Para proveer una interfase de alto nivel, el subsistema de compilacin

provee una clase Compiler. Esta clase define una interfase unificada para lafuncionalidad del compilador, actuando como la cara visible o fachada del

subsistema. Permite el uso de una interfase unificada y simple, a la vez queno oculta completamente las clases del subsistema, quedando permitido suacceso y uso especfico.

Figura 25 Ejemplo del subsistema de compilacin

Facade

+Compilar()

Compiler

Stream Scanner Symbol

Parser

ProgramNode

BytecodeStream

CodeGeneratorProgramNodeBuilder

7/21/2019 POO PARTE 2

41/78



Aplicacin: El patrn Facade se puede usar cuando:

Se desea proveer una interfase simple a un subsistema complejo Se desea minimizar los puntos de contactos entre subsistemas y

estos con la implementacin del cliente.

Estructura:

Figura 26 Estructura del patrn Facade

Participantes:

Facade: conoce cuales son las clases del subsistema que sonresponsables de determinado comportamiento.

Subsystem Classes: implementan la funcionalidad del subsistema.Manejan la carga de trabajo que enva el objeto Facade. Desconocende la existencia del objeto Facade.

Colaboraciones: Los clientes se comunican con el subsistema mediante elobjeto Facade. Este traslada las peticiones de los clientes a los objetos delsubsistema. Los clientes que utilizan el objeto Facade no necesitan utilizarlas clases del subsistema directamente.

Consecuencias:

Asla parcialmente a los clientes de los componentes de unsubsistema

Promueve el bajo acoplamiento entre subsistemas

Flyweight

Propsito: Permite soportar un gran nmero de objetos bsicamenteprimitivos mediante el uso.

Motivo: Veamos el ejemplo de un editor de documentos, que estprogramado segn el paradigma Orientado a Objetos. Generalmente estos

editores utilizan objetos para representar tablas, columnas, filas, prrafos, einclusive, podemos encontrar algunos que utilicen objetos para representarlos caracteres. Esto nos permite una flexibilidad muy grande en la

Facade

7/21/2019 POO PARTE 2

42/78



aplicacin, ya que podra extenderse para que soporte nuevos juegos decaracteres, adems de las reglas para manejarlos.

Figura 27 Vista detallada del editor

Segn el ejemplo del editor, se crea a cada letra del abecedario como unobjeto Flyweight. Cada objeto Flyweight almacena el cdigo del carcter quele corresponde, pero la posicin en donde aparece y el estilo de la letra sepueden determinar de las alineaciones del texto y de los comandos deformateo, por lo tanto el cdigo del carcter es intrnseco, mientras que la

dems informacin es extrnseca.

Lgicamente, parecera que hay un objeto para cada ocurrencia del carcteren el documento, pero fsicamente, cada ocurrencia de un carcter se refierea una nica instancia del mismo, mientras lo que cambia son suscoordenadas y estilos de visualizacin.

A A A A A A A

Objeto columna

Objeto fila

Objeto caracter

ser utilizado en distintos contextos. Acta independientemente del

contexto, y no debe tener conocimiento del contexto en el cual est siendoutilizado. Esto se debe a que posee dos conjuntos de propiedades, lasintrnsecas, que consisten en informacin propia del objeto, hacindolocompartible, y las extrnsecas, que es la informacin que relaciona al objetocon el contexto.

Pero este enfoque tiene una desventaja, y es el costo en el uso de recursos.Sabemos que cualquier documento que se cree puede involucrar cientos ymiles de caracteres, por lo que la utilizacin de memoria sera elevada,atentando contra el rendimiento del sistema. El patrn Flyweight describecomo compartir objetos en este tipo de arquitecturas evitando costosprohibitivos.

Un objeto Flyweight (o Peso Mosca) es un objeto compartido que puede

7/21/2019 POO PARTE 2

43/78



Figura 28 Vista lgica y fsica de las representacin de objetos del editor

La estructura de clases para estos objetos es muestra a continuacin.ObjetoGrafico es la clase abstracta para los distintos objetos que aparecenen el documento, alguno de los cuales sern Flyweight. Los mtodos quedependan del comportamiento extrnseco, necesitaran que el contexto seapasado como parmetro.

Figura 29 Estructura de clases posible del editor

El objeto Flyweight que representa a la letra a solo guarda el cdigo dedicho carcter, mientras que la informacin del contexto solo se utiliza enlos mtodos de posicin y formateo.

Aplicacin: El patrn Flyweight se puede usar cuando:

Una aplicacin cuenta con un gran nmero de objetos

Los costos de almacenamiento son altos debido a la gran cantidadde objetos La mayor parte del estado de un objeto se puede hacer extrnseca Cuando la aplicacin no dependa de la identidad de los objetos que

utiliza.

A B C D E F G H I J K L M N

M N O P Q R S T U V W X Y Z

columna

fila fila fila

A B C D E F G

columna

fila fila fila

A B C D E F G

Vista Lgica Vista Fsica

Flyweight pool

+Posicionar(entrada contexto)

+Formatear(entrada contexto)

ObjetoGrafico



Fila



-char c

Caracter



Columna

7/21/2019 POO PARTE 2

44/78



Estructura:

Figura 30 Estructura del patrn Flyweight

Participantes:

Flyweight: declara la interfase por la que reciben y actan sobre elestado extrnseco.

ConcreteFlyweight: implementa la interfase de Flyweight ymantiene el estado intrnseco. Este es el objeto que se comparte.

UnsharedConcreteFlyweight: pueden existir objetos Flyweight queno necesiten ser compartidos. Generalmente estos contienen objetosFlyweight como hijos.

FlyweightFactory: crea y maneja objetos Flyweight. Asegura que losFlyweight se compartan correctamente. Si el cdigo cliente requiereun Flyweight, esta devuelve una instancia existente o la crea en casode que no exista.

Cliente: mantiene las referencias a los objetos Flyweight. Mantienelos estados extrnsecos de los mismos.

Colaboraciones: ElCliente es el encargado de mantener el estadoextrnseco, y pasrselo al Flyweight cuando sea necesario. El Cliente nodebe instanciar los Flyweights directamente. Debe obtenerlos mediante elFlyweightFactory que asegura el uso compartido de los mismos.

Consecuencias:

El patrn Flyweight puede agregar costos en tiempos de ejecucinasociado con la transferencia o clculo de los estados extrnsecos, siestos formaban parte antes del estado intrnseco, pero que se ve

compensada por el ahorro en el uso de memoria. Generalmente se combina con el patrn Composite, pero con la

salvedad que el los objetos Leaf no deben tener una referencia haciasu contenedor.

Proxy

Propsito:Proporciona un sustituto o un intermediario paracontrolar el acceso a un objeto.

Motivo:Una razn, de varias, para controlar el acceso a un objeto espostergar su proceso de creacin e inicializacin hasta que realmente

necesitemos utilizarlo. Sigamos con nuestro querido editor, al cual lepodemos agregar imgenes. Algunas de estas imgenes que podemos

+getFlyweight(entrada id)

FlyweightFactory

+Metodo(entrada estadoExt)

Flyweight


-estadoInterno

ConcreteFlyweight


-allEstados

UnsharedConcreteFlyweight

Cliente

if (fl exists) { return fl;

}else {

fl=new Fl(); flPool.add(fl);

return fl;}

7/21/2019 POO PARTE 2

45/78



agregar pueden ser demasiado grandes, y por lo tanto costosas a la hora deinstanciarlas como objetos. Pero por otro lado, la apertura del documentodebera ser rpida, por lo tanto, deberamos evitar la carga de objetospesados en la apertura del documento. De hecho, esto innecesario, ya queno los visualizaramos a todos al mismo tiempo.

Esta idea nos sugiere crear cada objeto pesado bajo demanda, que en estecaso ocurre cuando se visualiza la imagen. Para realizar esto, introducimosotro objeto, denominado Proxy de Imgenes, que acta como suplente de laimagen real, y se encarga de instanciarla cuando sea requerido.

Figura 31 Carga de la imagen bajo demanda.

El Proxy de Imgenes crea la imagen real cuando el editor le requieramostrarla. Este pasa la peticin directamente al objeto imagen, quien seencarga de la instanciacin. La siguiente figura muestra ilustra el ejemplocon ms detalle.

Figura 32 Estructura de clases del editor.

El editor accede a las imgenes embebidas a travs de la interfase declarada

por la clase abstracta Grafico. ProxyImagen es la encargada de crear lasimgenes bajo demanda. Mantiene una referencia al objeto especfico quetiene los datos de la imagen, que puede ser un archivo externo. Este objetoes pasado como parmetro al constructor de ProxyImagen. Adems, guardauna referencia del objeto Imagen junto con sus datos de formato. Estareferencia no ser vlida hasta que ProxyImagen instancia la imagen real.El mtodo Dibujar se asegura de que la imagen sea instanciada antes dellamar al mismo mtodo de la imagen real. GetFormato solo pasa lasolicitud a la imagen real solo si esta es instanciada, sino devuelve los datosde formateo propios de ProxyImagen.

aDocumentoTexto

imageaProxyImagen

archivoImagen

aImagen

datos

DocumentoTexto

+Dibujar()

+GetFormato()

+Cargar()

Grafico

+Dibujar()

+GetFormato()

+Cargar()

-image

-formato

Imagen

+Dibujar()

+GetFormato()

+Cargar()

-archivo

-formato

ProxyImagen

if(image==null)

image=CargarImagen(archivo);

image.Dibujar();

if(image==null)

return formato;

else

return image.GetFormato();

7/21/2019 POO PARTE 2

46/78



Aplicacin: El patrn Proxy se puede usar cuando: Cuando se necesita una referencia especial o ms sofisticada adems

de la simple referencia al objeto que estamos solicitando. Se puedendar las siguientes variantes:

- Proxy remoto: provee una referencia local a un objeto que seencuentra en otro espaci de memoria (otra mquina)

- Proxy virtual: crea objetos pesados bajo demanda (caso deleditor)

- Proxy de proteccin: control el acceso al objeto original, muyapropiado cuando un objeto tiene distintos permisos deacceso

- Proxy inteligente: adems de proveer la referencia al objeto,realiza algunas operaciones propias, como contar lasreferencias existentes del mismo, liberar referencias delmismo objeto cuando se encuentren fuera de uso, entreotros.

Estructura:

Figura 33 Estructura del patrn Proxy

Participantes: Proxy: mantiene una referencia al objeto real. Puede referencia a un

Subject si este y RealSubject tienen la misma interfase. Provee unainterfase idntica al Subject, por lo tanto puede reemplazarlo.Controla el acceso al RealSubject y puede ser el encargado de crearloy/o eliminarlo. Funcionalidad adicional depender del tipo deProxy.

Subject: define una interfase comn para el Proxy y el RealSubject,de esta manera el Proxy puede ser usado donde se requiera el uso deRealSubject.

Un Proxy remoto oculta el hecho de que el objeto representado no se

encuentra localmente, o que reside en otro espacio de direcciones. Un Proxy virtual lleva a cabo optimizaciones como la creacin de

objetos bajo demanda.

+Metodo()

Subject

realSubject.Metodo();+Metodo()

RealSubject

+Metodo()

Proxy

RealSubject: define el objeto real que es representado por el Proxy.

Colaboraciones:Proxy pasa las peticiones al RealSubject cuando esapropiado. Depende del tipo de Proxy.

Consecuencias:

7/21/2019 POO PARTE 2

47/78



Tanto el Proxy de proteccin como el inteligente permiten tareas deoptimizacin cuando los objetos son accedidos.

Patrones de comportamiento

Los patrones de comportamiento especifican la asignacin de lasresponsabilidades que llevan a cabo los objetos de nuestro sistema, ascomo la forma en que estos objetos se comunican.

Los patrones que pertenecen a este grupo son:

Chain of Responsability Command Interpreter Iterator Mediator

Memento Observer State Strategy Template Method Visitor

Chain of Responsability

Propsito: Evitar el acoplamiento entre el objeto que enva una peticin yel objeto que la recibe, permitiendo que otros objetos encadenados se hagan

cargo de la misma.

Motivo:Consideremos, en este caso, la funcionalidad de mostrar ayudamediante una opcin del men contextual de una interfaz grfica deusuario. Dicha funcin permite mostrar datos especficos de ayuda de cadauno de los controles que aparecen en determinada ventana. En caso de noexistir ayuda para un determinado control, se muestra un texto msgeneral.

Una forma natural de organizar dicha ayuda sera de acuerdo a sugeneralidad (desde lo ms especfico a lo ms general). Adems, esta

funcionalidad debe ser llamada desde todas las interfaces grficas de laaplicacin, y cuyo resultado depender de la ventana contexto del controlseleccionado y de la disponibilidad de la informacin especfica para elmismo.

El problema aqu es que el objeto que debe proporcionar el resultado de laayuda, no es conocido explcitamente por el control que ha sidoseleccionado. Lo que necesitamos es desacoplar al control que inicia elpedido, del objeto que provee el resultado.

La idea del patrn Chain of Responsability es desacoplar los emisores de losreceptores de mensajes, dando oportunidad a distintos objetos de hacerse

cargo de la peticin.

7/21/2019 POO PARTE 2

48/78



Figura 34 Organizacin de los objetos de la cadena.

El primer objeto en la cadena recibe la peticin, quien la resuelve o la pasaal siguiente en la cadena, quien a su vez hace lo mismo. El objeto que iniciala peticin no tiene conocimiento explcito de quien la resolver.Por ejemplo, si hacemos la peticin de ayuda de un botn BtnImprimirubicado en Dilogo Impresin, el cual depende directamente del objetoAplicacin. La siguiente figura muestra como la peticin se pasa a lo largo

de la cadena.

Figura 35 Secuencia de los mensajes en la cadena.

En este caso, ni BtnImprimir ni Dilogo Impresin la resuelven, sino que lapasan hasta Aplicacin, quien la resuelve o la ignora.

Para pasar la peticin a lo largo de la cadena y asegurarnos de que losreceptores sean implcitos, hacemos que cada objeto de la cadena compartauna interfase comn para manejar la peticin y acceder al siguiente objetode la cadena. Por ejemplo, se puede definir una clase Ayuda con el mtodo

Ver Ayuda correspondiente. sta puede ser la clase padre de cada objetocandidato a mostrar dicha ayuda.

aBtnImprimir

handler

aBtnCerrar

handler

aDialogoGuardar

handler

aDialogoImpresion

handler

aAplicacion

handler

aBtnImprimir aDialogoImpresion aAplicacion

VerAyuda()VerAyuda()

7/21/2019 POO PARTE 2

49/78



Figura 36 Estructura de clases del ejemplo.

Las clases del ejemplo utilizan el mtodo de Ayuda para manejar laspeticiones de ayuda. Cada subclase puede sobrecargar dicho mtodo paraproveer la ayuda en las circunstancias correctas, o dejar la implementacinpor default para pasar la peticin hacia delante.

Aplicacin: El patrn Chain of Responsability se puede usar cuando:

Ms de un objeto necesitan manejar una peticin y no se conoce elencargado de manejarla a priori. El receptor final debe seralcanzado automticamente.

Se desea hacer una peticin a uno de varios objetos sin especificarexplcitamente al receptor.

El conjunto de objetos que pueden manejar la peticin se especificadinmicamente.

Estructura:

Figura 37 Estructura del patrn Chain of Responsability.

+VerAyuda()

-

Ayuda

Aplicacion Control

+VerAyuda()

+MostrarAyuda()

BotonDialogo

sucesor.Ayuda();

sucesor

if(resuelve peticion)

MostrarAyuda();

else

sucesor.Ayuda();

+ManejarPeticion()

-

Handler

+ManejarPeticion()

ConcreteHandler1

+ManejarPeticion()

ConcreteHandler2

7/21/2019 POO PARTE 2

50/78



Participantes:

Handler: Define la interfase para manejar la peticin.Opcionalmente, implementa la comunicacin hacia el objetosucesor.

ConcreteHandler: Maneja las peticiones de las cual es responsable.

Puede acceder a su sucesor en la cadena. Si puede resolver lapeticin, lo hace, de lo contrario, la pasa al sucesor.

Cliente: Inicia la peticin a un ConcreteHandler en la cadena.

Colaboraciones:Cuando un Cliente hace una peticin, esta se propagapor la cadena hasta que llega al receptor (ConcreteHandler) encargado deresolverla.

Consecuencias:

Reduccin notable del acoplamiento entre objetos Agrega flexibilidad al distribuir las responsabilidades a los objetos La recepcin de la peticin no est asegurada, ya que puede llegar al

final de la cadena y no ser resuelta, o no llegar porque la cadena noest bien configurada.

Command

Propsito:Este patrn permite solicitar una operacin a un objeto sinconocer realmente el contenido de esta operacin, ni el receptor real de lamisma. Para ello se encapsula la peticin como un objeto, con lo queadems se facilita la parametrizacin de los mtodos.

Motivo:Por ejemplo, cuando desarrollamos interfaces grficas, los

distintos controles involucrados pueden responder a determinados eventosque ellos poseen. Para desacoplar estos controles de la lgica real que llevala ejecucin disparada por un evento, se introduce el patrn Command.Este patrn permite a los objetos de la interfaz que realicen peticiones aobjetos no especficos de la aplicacin convirtiendo la misma peticin en unobjeto, que puede ser pasado o serializado. La clave de este patrn es laclase Command abstracta, que declara una interfase para ejecutar mtodos.En su forma ms simple, incluye solamente un mtodo execute(). Lassubclases concretas de Command especifican pares de requerimientos-receptores, registrando al receptor como una variable de instancia, e

impementando el mtodo execute() para completar la peticin. El receptortiene los datos y la lgica necesaria para llevar a cabo la peticin.

Figura 38 Estructura del ejemplo de interfaces.

Aplicacion

Menu MenuItem

+ejecutar()

Command

Toolbar ToolbarButton

Documento

+ejecutar()

AbrirCommand

+ejecutar()

PegarCommand

7/21/2019 POO PARTE 2

51/78



Figura 39 Ejemplo del comando Pegar.

Figura 40 Ejemplo del comando Abrir.

En las figuras anteriores se puede ver como se logra invocar los distintoscomandos de la aplicacin utilizando una sola interfase.

Cada uno de estos ejemplos denota como el patrn Command desacopla el objeto

que invoca el mtodo del que realmente tiene la lgica para llevarlo a cabo. Esto

nos hace ganar en flexibilidad sobre todo cuando un mismo mtodo o comando

se debe poder ejecutar desde distintos puntos o controles de nuestra aplicacin.

Aplicacin: El patrn Command se puede usar cuando:

Se desea facilitar la parametrizacin de las acciones a realizar. Se necesita proveer funcionalidad de deshacer o rollback. Desarrollar sistemas que utilizan mtodos de alto nivel que se

construyen con operaciones sencillas.

Estructura:

Figura 41 Estructura del patrn Command.

+ejecutar()

Command

+ejecutar()

AbrirCommand

+ejecutar()

PegarCommand Documento

+ejecutar()

Command

+ejecutar()

AbrirCommand

+ejecutar()

PegarCommandAplicacion

+ejecutar()

CommandInvoker

+ejecutar()

-state

ConcreteCommand+accion()

Receiver

Cliente

uses

7/21/2019 POO PARTE 2

52/78



Participantes:

Command: declara la interfase para ejecutar las operaciones ConcreteCommand: define la comunicacin entre el objeto Reciever

y la accin a ejecutar. Implementa el mtodo execute() invocandolas operaciones correspondiente

POO PARTE 2

Documents

Transcript of POO PARTE 2