You are on page 1of 27

2015

UNIVERSIDAD NACIONAL DE TRUJILLO

TECNOLOGA DE LA PROGRAMACIN II

UNIVERSIDAD NACIONAL DE
TRUJILLO
FACULTAD DE INGENIERA
ESCUELA DE INGENIERA DE SISTEMAS
PATRN DE DISEO FACADE E ITERATOR
GRUPO N 6
DELGADO CHAO, CRISTHIAN (Coordinador)
IPARRAGUIRRE SIXE, ABNER
MONTERO MACO, GUSTAVO
ROJAS ALARCON, JORDAN
ROJAS LPEZ, JOS YERSON
CURSO:
TECNOLOGA DE LA PROGRAMCIN II

DOCENTE:
Mg. VIDAL MELGAREJO ZORAIDA YANET
CICLO:
V
1|P gi na

UNIVERSIDAD NACIONAL DE TRUJILLO

TECNOLOGA DE LA PROGRAMACIN II

PATRN DE DISEO FACADE E ITERATOR


NDICE
INTRODUCCIN ............................................................................................................. 3
1.

2.

PATRN DE DISEO FACADE ........................................ Error! Marcador no definido.


1.1.

DEFINICIN ........................................................................................................ 5

1.2.

OBJETIVO............................................................................................................ 5

1.3.

MOTIVACIN ..................................................................................................... 5

1.4.

ESTRUCTURA ...................................................................................................... 6

1.4.1.

DIAGRAMA GENERAL.................................................................................. 6

1.4.2.

DIAGRAMA DE CLASES................................................................................ 8

1.4.3.

PARTICIPANTES ........................................................................................... 9

1.4.4.

COLABORACIONES ...................................................................................... 9

1.4.5.

APLICACIN .............................................................................................. 10

1.4.6.

VENTAJAS Y DESVENTAJAS ....................................................................... 11

1.4.7.

PATRONES RELACIONADOS ...................................................................... 11

1.4.8.

EJEMPLO EN JAVA..................................................................................... 12

PATRN DE DISEO ITERATOR..................................... Error! Marcador no definido.


2.1. DEFINICIN .......................................................................................................... 18
2.2. OBJETIVO ............................................................................................................. 18
2.3. MOTIVACIN ....................................................................................................... 18
2.4. ESTRUCTURA........................................................................................................ 19
2.4.1. DIAGRAMA DE CLASES .................................................................................. 19
2.4.2. PARTICIPANTES ............................................................................................. 20
2.4.3. COLABORACIONES ........................................................................................ 20
2.4.4. APLICACIONES .............................................................................................. 20
2.4.5. CONSECUENCIAS .......................................................................................... 20
2.4.6. EJEMPLO ....................................................................................................... 21

CONCLUSIONES ........................................................................................................... 26
BIBLIOGRAFA ............................................................................................................. 27

2|P gi na

UNIVERSIDAD NACIONAL DE TRUJILLO

TECNOLOGA DE LA PROGRAMACIN II

INTRODUCCIN

El patrn Facade o Fachada es un tipo de patrn estructural, surge por la necesidad de


estructurar un entorno de programacin y reducir su complejidad con la divisin de
subsistemas (componentes) ms sencillos e independientes entre s, minimizando las
comunicaciones y dependencias entre estos.

El Patrn Fachada se caracteriza por ser una puerta de entrada hacia otro subsistema.
Provee una interfaz unificada y sencilla que haga de intermediaria entre un cliente y
una interfaz o grupo de interfaces ms complejas. Facade define una interfaz de alto
nivel que hace, el subsistema fcil de usar.

El patrn Facade nos permite simplificar la interfaz de comunicacin entre dos objetos
X y Z de tal forma que para el objeto X sea ms sencillo interactuar con el objeto Z. De
esta manera el cliente solo se conecta con una interfaz sencilla, mientras que la
interfaz sencilla se conecta a su vez a otras interfaces ms complejas.

3|P gi na

UNIVERSIDAD NACIONAL DE TRUJILLO

TECNOLOGA DE LA PROGRAMACIN II

1. PATRN DE
DISEO FACADE

4|P gi na

UNIVERSIDAD NACIONAL DE TRUJILLO

1.1.

TECNOLOGA DE LA PROGRAMACIN II

DEFINICIN

El patrn de diseo facade o fachada nos permite simplificar el interface de


comunicacin entre dos objetos X y Z de tal forma que para el objeto X sea ms
sencillo interactuar con el objeto Z. De esta manera el cliente solo se conecta con una
interface sencilla, mientras que la interface sencilla se conecta a su vez a otras
interfaces ms complejas. Proporciona una interfaz unificada para un conjunto de
interfaces de un sistema. Define una interfaz de alto nivel que hace que el subsistema
sea ms fcil de usar.
El Patrn Fachada se caracteriza por ser una puerta de entrada hacia otro subsistema.
Provee una interfaz unificada y sencilla que haga de intermediaria entre un cliente y
una interfaz o grupo de interfaces ms complejas. Es un patrn de diseo tipo
estructural perteneciente a la pandilla de los 4. El patrn fachada esconde toda la
complejidad de un subsistema y sirve como puerta de acceso.
1.2.

OBJETIVO

El objetivo del patrn Facade es agrupar las interfaces de un conjunto de objetos en


una interfaz unificada volviendo a este conjunto ms fcil de usar por parte de un
cliente.
El patrn Facade encapsula la interfaz de cada objeto considerada como interfaz de
bajo nivel en una interfaz nica de nivel ms elevado. La construccin de la interfaz
unificada puede necesitar implementar mtodos destinados a componer las interfaces
de bajo nivel.
1.3.

MOTIVACIN

Por lo general, dentro de un entorno de programacin, la mayora de los clientes de un


compilador no suelen preocuparse de detalles como el anlisis sintctico y la
generacin de cdigo.
Para proporcionar una interfaz de ms alto nivel que asle a estas clases de los clientes
del subsistema de compilacin tambin incluye una clase compilador. Esta clase define
una interfaz uniforme para la funcionalidad del compilador.
Reduce la complejidad.
Minimizar la comunicacin y dependencias entre subsistemas.
Introducir un objeto fachada que proporcione una interfaz nica y simplificada
para los servicios del sistema.
La clase compilador funciona como una fachada:
Ofrece a los clientes una interfaz nica y simple
Esta clase aglutina las clases que implementan la funcionalidad del compilador
sin ocultarlas por completo.
5|P gi na

UNIVERSIDAD NACIONAL DE TRUJILLO

TECNOLOGA DE LA PROGRAMACIN II

La fachada del compilador facilita la vida a los programadores.


Esta clase aglutina las clases que implementan la funcionalidad del compilador
sin ocultarlas por completo.
1.4. ESTRUCTURA
1.4.1. DIAGRAMA GENERAL

Por ejemplo, se tiene la clase A debe saber cul es exactamente la clase que le
proporciona el servicio: b1() es de B, c1() de C, d1() de D, ...

6|P gi na

UNIVERSIDAD NACIONAL DE TRUJILLO

TECNOLOGA DE LA PROGRAMACIN II

Pero el problema sera mayor, si hay ms de un cliente:

En estos caso, se puede usar este patrn de la siguiente forma: Proporcionando una
clase que implemente todos los servicios (b1(),c1(),d1()). Los clientes slo usarn
dicha clase.

7|P gi na

UNIVERSIDAD NACIONAL DE TRUJILLO

TECNOLOGA DE LA PROGRAMACIN II

1.4.2. DIAGRAMA DE CLASES

8|P gi na

UNIVERSIDAD NACIONAL DE TRUJILLO

TECNOLOGA DE LA PROGRAMACIN II

1.4.3. PARTICIPANTES
Los participantes del patrn son los siguientes:
Fachada (WebServiceAuto) y su interfaz constituyen la parte abstracta
expuesta a los clientes del sistema. Esta clase posee referencias hacia
las clases y componentes que forman el sistema y cuyos mtodos se
utilizan en la fachada para implementar la interfaz unificada.
Las clases y componentes del sistema (RecogidaVehculo,
GestinDocumento y Catlogo) implementan las funcionalidades del
sistema y responden a las consultas de la fachada. No necesitan a la
fachada para trabajar.
1.4.4. COLABORACIONES
Los clientes se comunican con el sistema a travs de la fachada que se encarga,
de forma interna, de invocar a las clases y los componentes del sistema. La
fachada no puede limitarse a transmitir las invocaciones. Tambin debe realizar
la adaptacin entre su interfaz y la interfaz de los objetos del sistema mediante
cdigo especfico. El diagrama de secuencia de la figura 14.3 ilustra esta
adaptacin para un ejemplo cuyo cdigo especfico a la fachada debe ser
invocado (mtodos calcula1 y calcula2).
Los clientes que utilizan la fachada no deben acceder directamente a los objetos del
sistema.

9|P gi na

UNIVERSIDAD NACIONAL DE TRUJILLO

TECNOLOGA DE LA PROGRAMACIN II

1.4.5. APLICACIN
Usos conocidos problemas y soluciones:
Problema: Un cliente necesita acceder a parte de la funcionalidad de un
sistema ms complejo. Solucin:
Definir una interfaz que permita acceder solamente a esa funcionalidad.
Problema: Existen grupos de tareas muy frecuentes para las que se puede crear
cdigo ms sencillo y legible. Solucin:
Definir funcionalidad que agrupe estas tareas en funciones o mtodos
sencillos y claros.
Problema: Una biblioteca es difcilmente legible. Solucin:
Crear un intermediario ms legible.
Problema: Dependencia entre el cdigo del cliente y la parte interna de una
biblioteca. Solucin:
Crear un intermediario y realizar llamadas a la biblioteca slo o, sobre
todo, a travs de l.
Problema: Necesidad de acceder a un conjunto de APIs que pueden adems
tener un diseo no muy bueno. Solucin:
Crear una API intermedia, bien diseada, que permita acceder a la
funcionalidad de las dems.
Problema: Muchas clases cliente quieren usar varias clases servidoras, y deben
saber cul es exactamente la que le proporciona cada servicio. El sistema se
volvera muy complejo, porque habra que relacionar todas las clases cliente
con todas y cada una de las clases servidoras. Solucin:
Crear una o varias clases Facade, que implementen todos los servicios,
de modo que o todos los clientes utilicen esa nica clase, o que cada
grupo de clientes use la fachada que mejor se ajuste a sus necesidades.
El patrn se utiliza en los siguientes casos:
Para proveer una interfaz simple de un sistema complejo. La
arquitectura de un sistema puede estar basada en numerosas clases
pequeas, que ofrecen una buena modularidad y capacidad de
evolucin. No obstante estas propiedades tan estupendas no interesan
en absoluto a los clientes, que slo necesitan un acceso simple que
responda a sus exigencias.
10 | P g i n a

UNIVERSIDAD NACIONAL DE TRUJILLO

TECNOLOGA DE LA PROGRAMACIN II

Para dividir un sistema en subsistemas, la comunicacin entre


subsistemas se define de forma abstracta a su implementacin gracias a
las fachadas.
Para sistematizar la encapsulacin de la implementacin de un sistema
de cara al exterior.
1.4.6. VENTAJAS Y DESVENTAJAS
VENTAJAS
La principal ventaja del patrn fachada consiste en que para modificar
las clases de los subsistemas, slo hay que realizar cambios en la
interfaz/fachada, y los clientes pueden permanecer ajenos a ello.
Adems, y como se mencion anteriormente, los clientes no necesitan
conocer las clases que hay tras dicha interfaz.
DESVENTAJAS
Como inconveniente, si se considera el caso de que varios clientes
necesiten acceder a subconjuntos diferentes de la funcionalidad que
provee el sistema, podran acabar usando slo una pequea parte de la
fachada, por lo que sera conveniente utilizar varias fachadas ms
especficas en lugar de una nica global.
1.4.7. PATRONES RELACIONADOS
El patrn Abstract Factory puede proporcionar una interfaz para crear
un subsistema de objetos de forma independiente a otros subsistemas.
El patrn Mediator es parecido a Facade en sentido de que abstrae
funcionalidad a partir de unas clases existentes.
Normalmente se necesita un objeto fachada, por tanto estos se
implementan como singleton.

11 | P g i n a

UNIVERSIDAD NACIONAL DE TRUJILLO

TECNOLOGA DE LA PROGRAMACIN II

1.4.8. EJEMPLO EN JAVA


Queremos ofrecer la posibilidad de acceder al sistema de venta de vehculos
como servicio web. El sistema est arquitecturizado bajo la forma de un
conjunto de componentes que poseen su propia interfaz como:

El componente Catlogo.
El componente GestinDocumento.

El componente RecogidaVehculo.

Es posible dar acceso al conjunto de la interfaz de estos componentes a los clientes del
servicio web, aunque esta posibilidad presenta dos inconvenientes principales:
Algunas funcionalidades no las utilizan los clientes del servicio web, como por ejemplo
las funcionalidades de visualizacin del catlogo.
La arquitectura interna del sistema responde a las exigencias de modularidad y
evolucin que no forman parte de las necesidades de los clientes del servicio web, para
los que estas exigencias suponen una complejidad intil.
El ejemplo del servicio web que vamos a simular con ayuda de un pequeo programa
escrito en Java. Se muestra en primer lugar el cdigo fuente de los componentes del
sistema, comenzando por la clase ComponenteCatalogo y su interfazCatalogo.
La base de datos que constituye el catlogo se reemplaza por una sencilla tabla de
objetos. El mtodo busca Vehculos realiza la bsqueda de uno o de varios vehculos en
funcin de su precio gracias a un simple bucle.
El patrn Facade resuelve este problema proporcionando una interfaz unificada ms
sencilla y con un nivel de abstraccin ms elevado. Una clase se encarga de
implementar esta interfaz unificada utilizando los componentes del sistema.
Esta solucin se ilustra en el diagrama siguiente. La clase WebServiceAuto ofrece una
interfaz a los clientes del servicio web. Esta clase y su interfaz constituyen una fachada
de cara a los clientes.
La interfaz de la clase WebServiceAuto est constituida por el mtodo buscaVehculos
(precioMedio, desviacinMax) cuyo cdigo consiste en invocar al mtodo
buscaVehculos(precioMin, precioMax) del catlogo adaptando el valor de los
argumentos de este mtodo en funcin del precio medio y de la desviacin mxima.
Conviene observar que si bien la idea del patrn es construir una interfaz de ms alto
nivel de abstraccin, nada nos impide proporcionar en la fachada accesos directos a
ciertos mtodos de los componentes del sistema.

12 | P g i n a

UNIVERSIDAD NACIONAL DE TRUJILLO

TECNOLOGA DE LA PROGRAMACIN II

13 | P g i n a

UNIVERSIDAD NACIONAL DE TRUJILLO

TECNOLOGA DE LA PROGRAMACIN II

14 | P g i n a

UNIVERSIDAD NACIONAL DE TRUJILLO

TECNOLOGA DE LA PROGRAMACIN II

Continuamos con el componente de gestin de documentos constituido por la interfaz


GestionDocumento y la clase ComponenteGestionDocumento. Este componente
constituye la simulacin de una base de documentos.

La clase WebServiceAutoImpl implementa ambos mtodos. Destacamos el clculo del


precio mnimo y mximo para poder invocar al mtodo BuscaVehiculos de la clase
ComponenteCatalogo
La interfaz de la fachada llamada WebServiceAuto define la firma de dos mtodos

15 | P g i n a

UNIVERSIDAD NACIONAL DE TRUJILLO

TECNOLOGA DE LA PROGRAMACIN II

destinados a los clientes del servicio web.

Por ltimo, un cliente del servicio web puede escribirse en Java como sigue:

Este cliente muestra dos documentos as como los vehculos cuyo precio est
comprendido entre 5.000 y 7.000. El resultado de la ejecucin de este programa
principal es el siguiente:

16 | P g i n a

UNIVERSIDAD NACIONAL DE TRUJILLO

TECNOLOGA DE LA PROGRAMACIN II

2. PATRN DE

DISEO ITERATOR

17 | P g i n a

UNIVERSIDAD NACIONAL DE TRUJILLO

TECNOLOGA DE LA PROGRAMACIN II

2.1. DEFINICIN
Es un mecanismo de acceso a los elementos que constituyen una estructura de datos
para la utilizacin de estos sin exponer su estructura interna.
El patrn Iterator proporciona un acceso secuencial a una coleccin de objetos a los
clientes sin que stos tengan que preocuparse de la implementacin de esta coleccin.
2.2. OBJETIVO
Proporcionar una forma de acceder a los elementos de una coleccin de
objetos de manera secuencial sin revelar su representacin interna.
Define una interfaz que declara mtodos que permitan acceder
secuencialmente a la coleccin.
2.3. MOTIVACIN
El patrn surge del deseo de acceder a los elementos de un contenedor de
objetos (por ejemplo, una lista) sin exponer su representacin interna. Adems,
es posible que se necesite ms de una forma de recorrer la estructura siendo
para ello necesario crear modificaciones en la clase.
La solucin que propone el patrn es aadir mtodos que permitan recorrer la
estructura sin referenciar explcitamente su representacin. La responsabilidad
del recorrido se traslada a un objeto iterador.
El problema de introducir este objeto iterador reside en que los clientes
necesitan conocer la estructura para crear el iterador apropiado

18 | P g i n a

UNIVERSIDAD NACIONAL DE TRUJILLO

TECNOLOGA DE LA PROGRAMACIN II

2.4. ESTRUCTURA
2.4.1. DIAGRAMA DE CLASES

19 | P g i n a

UNIVERSIDAD NACIONAL DE TRUJILLO

TECNOLOGA DE LA PROGRAMACIN II

2.4.2. PARTICIPANTES
Los participantes del patrn son los siguientes:
Iterador es la clase abstracta que implementa la asociacin del iterador con los
elementos de la coleccin as como los mtodos. Es genrica y est
parametrizada mediante el tipo TElemento.
IteradorConcreto (IteradorVehculo) es una subclase concreta de Iterador que
relaciona TElemento con ElementoConcreto.
Coleccin (Catlogo) es la clase abstracta que implementa la asociacin de la
coleccin con los elementos y el mtodo creaIterador.
ColeccinConcreta (CatlogoVehculo) es una subclase concreta de Coleccin
que relaciona TElemento con ElementoConcreto y TIterador con
IteradorConcreto.
Elemento es la clase abstracta de los elementos de la coleccin.
ElementoConcreto (Vehculo) es una subclase concreta de Elemento utilizada
por IteradorConcreto y ColeccinConcreta.
2.4.3. COLABORACIONES
El iterador guarda en memoria el objeto en curso en la coleccin. Es capaz de calcular
el objeto siguiente del recorrido.
2.4.4. APLICACIONES
El patrn se utiliza en los casos siguientes:
Es necesario realizar un recorrido de acceso al contenido de una coleccin sin
acceder a la representacin interna de esta coleccin.
Debe ser posible gestionar varios recorridos de forma simultnea.
2.4.5. CONSECUENCIAS
Los iteradores simplifican la interfaz de las colecciones, ya que la interfaz de los
recorridos se encuentra en los iteradores y no en la clase que corresponde a la
estructura en cuestin.
Permite variaciones en el recorrido de una coleccin.
Para cambiar el algoritmo de recorrido basta cambiar la instancia de
Iterator concreta
Nuevos recorridos mediante nuevas subclases de Iterator
Se puede tener ms de un recorrido en progreso al mismo tiempo por
cada coleccin

20 | P g i n a

UNIVERSIDAD NACIONAL DE TRUJILLO

TECNOLOGA DE LA PROGRAMACIN II

2.4.6. EJEMPLO

Queremos proporcionar un acceso secuencial a los vehculos que componen el


catlogo. Para ello, podemos implementar en la clase del catlogo los siguientes
mtodos:
inicio: inicializa el recorrido por el catlogo.
item: reenva el vehculo en curso.
siguiente: pasa al vehculo siguiente.
Esta tcnica presenta dos inconvenientes:
Hace aumentar de manera intil la clase catlogo.
Slo permite recorrer el catlogo una vez, lo cual puede ser insuficiente (en
especial en el caso de aplicaciones multitarea).
El patrn Iterator proporciona una solucin a este problema. La idea consiste en crear
una clase Iterador donde cada instancia pueda gestionar un recorrido en una
coleccin. Las instancias de esta clase Iterador las crea la clase coleccin, que se
encarga de inicializarlas.
El objetivo del patrn Iterator es proporcionar una solucin que pueda ser configurada
segn el tipo de elementos que componen la coleccin. Presentamos por tanto dos
clases abstractas genricas:
Iterador es una clase abstracta genrica que incluye los mtodos inicio, item y
siguiente.
Catlogo es a su vez una clase abstracta genrica que incluye los mtodos que
crean, inicializan y devuelven una instancia de Iterador.
A continuacin es posible crear las subclases concretas de estas dos clases abstractas
genricas, subclases que relacionan en particular los parmetros de genericidad con
los tipos utilizados en la aplicacin.
La figura siguiente muestra el uso del patrn Iterator para recorrer los vehculos del
catlogo que responden a una consulta.
Este diagrama de clases utiliza parmetros genricos que suponen ciertas restricciones
(TElemento es un subtipo de Elemento y TIterador es un subtipo de
Iterador<TElemento>). Las dos clases Catlogo e Iterador poseen una asociacin con
un conjunto de elementos, siendo el conjunto de elementos referenciados por Iterador
un subconjunto de los referenciados por Catlogo.
Las subclases CatlogoVehculo e IteradorVehculo heredan mediante una relacin
que fija los tipos de parmetros de genericidad de sus superclases respectivas.

21 | P g i n a

UNIVERSIDAD NACIONAL DE TRUJILLO

TECNOLOGA DE LA PROGRAMACIN II

DIAGRAMA DEL EMPLO

22 | P g i n a

UNIVERSIDAD NACIONAL DE TRUJILLO

TECNOLOGA DE LA PROGRAMACIN II

Presentamos a continuacin un ejemplo escrito en Java del recorrido del catlogo de


vehculos con ayuda de un iterador.
El cdigo fuente de la clase abstracta Elemento se muestra a continuacin. Los
elementos poseen una descripcin. El mtodo palabraClaveValida verifica si aparece
cierta palabra clave en la descripcin.
public abstract class Elemento
{
protected String descripcion;
public Elemento(String descripcion)
{
this.descripcion = descripcion;
}

public boolean palabraClaveValida(String palabraClave)


{
return descripcion.indexOf(palabraClave) != -1;
}

La subclase concreta Vehiculo incluye un mtodo visualiza.


public class Vehiculo extends Elemento
{
public Vehiculo(String descripcion)
{
super(descripcion);
}
public void visualiza()
{
System.out.print("Descripcion del vehculo: " +
descripcion);
}
}

La clase Iterador incluye los mtodos inicio, siguiente, item as como el mtodo
setPalabraClaveConsulta que inicializa el iterador.
import java.util.List;
public abstract class Iterador
<TElemento> extends Elemento
{
protected String palabraClaveConsulta;
protected int indice;
protected List<TElemento> contenido;
public void setPalabraClaveConsulta(String
palabraClaveConsulta, List<TElemento> contenido))
{
this.palabraClaveConsulta = palabraClaveConsulta;
this.contenido = contenido;
}
public void inicio()
{
23 | P g i n a

UNIVERSIDAD NACIONAL DE TRUJILLO

TECNOLOGA DE LA PROGRAMACIN II

indice = 0;
int tamao = contenido.size();
while ((indice < tamao) && (!contenido.get(indice)
.palabraClaveValida(palabraClaveConsulta)))
indice++;

public void siguiente()


{
int tamao = contenido.size();
indice++;
while ((indice < tamao) && (!contenido.get(indice)
.palabraClaveValida (palabraClaveConsulta)))
indice++;
}
public TElemento item()
{
if (indice < contenido.size())
return contenido.get(indice);
else
return null;
}
}

La subclase IteradorVehiculo se contenta con enlazar TElemento con Vehiculo.


public class IteradorVehiculo extends
Iterador<Vehiculo>
{
}

La clase Catalogo gestiona el atributo contenido que es la coleccin de elementos e


incluye el mtodo bsqueda que crea, inicializa y devuelve el iterador.
El mtodo creaIterador es abstracto. En efecto, no es posible crea una instancia con
un tipo que es un parmetro genrico. Su implementacin debe realizarse en una
subclase que enlace el parmetro con una subclase concreta.
import java.util.*;
public abstract class Catalogo
<TElemento extends Elemento,
TIterador extends Iterador<TElemento>>
{
protected List<TElemento> contenido =
new ArrayList<TElemento>();
protected abstract TIterador creaIterador();
public TIterador busqueda(String palabraClaveConsulta)
{
TIterador resultado = creaIterador();
resultado.setPalabraClaveConsulta(palabraClaveConsulta
, contenido);
return resultado;
}
}
24 | P g i n a

UNIVERSIDAD NACIONAL DE TRUJILLO

TECNOLOGA DE LA PROGRAMACIN II

La subclase concreta CatalogoVehiculo relaciona TElemento con Vehiculo y


TIterador con IteradorVehiculo.
Incluye dos elementos:
Un constructor que construye la coleccin de vehculos (en una aplicacin
real, esta coleccin provendra de una base de datos).
La implementacin del mtodo creaIterador.
public class CatalogoVehiculo extends
Catalogo<Vehiculo, IteradorVehiculo>
{
public CatalogoVehiculo()
{
contenido.add(new Vehiculo("vehiculo economico"));
contenido.add(new Vehiculo("pequeo vehiculo
economico")); contenido.add(new Vehiculo("vehiculo de
gran calidad"));
}
protected IteradorVehiculo creaIterador()
{
return new IteradorVehiculo();
}
}

Por ltimo, la clase Usuario incluye el programa principal que crea el catlogo de
vehculos y un iterador basado en la bsqueda de la palabra clave "econmico". A
continuacin, el programa principal muestra la lista de vehculos devueltos por el
iterador.
public class Usuario
{
public static void main(String[] args)
{
CatalogoVehiculo
catalogo
=
new
CatalogoVehiculo(); IteradorVehiculo iterador =
catalogo.busqueda(
"economico")
;
Vehiculo vehiculo;
iterador.inicio();
vehiculo = iterador.item();
while (vehiculo != null)
{
vehiculo.visualiza();
iterador.siguiente();
vehiculo
iterador.item();
}

}
}

La ejecucin de este programa produce el resultado siguiente:


Descripcin del vehculo: vehculo econmico
Descripcin del vehculo: pequeo vehculo econmico.
25 | P g i n a

UNIVERSIDAD NACIONAL DE TRUJILLO

TECNOLOGA DE LA PROGRAMACIN II

CONCLUSIONES
-Podemos concluir del patrn facade:
Protege al cliente de los componentes del subsistema, as reduce el nmero
de objetos con los que el cliente se relaciona. Y hace ms fcil de usar al
subsiste-ma.
Promueve un acoplamiento dbil entre el cliente y el subsistema. Esto
permite modificar componentes en el subsistema sin modificar el cliente.
No evita que se use clases del subsistema si la aplicacin la necesita

-En cuanto al patrn Iterator:


Es conveniente usar el patrn iterator cuando una clase necesita accesar el
contenido de una coleccin, sin hacerse dependiente de la clase que
implementa la coleccin.
Permite variaciones en el recorrido de un agregado Los iteradores simplifican
la interfaz de los agregados ya que el recorrido de los mismos se define en
una interfaz separada.
Se puede hacer ms de un recorrido a la vez sobre un mismo agregado ya que
cada iterador mantiene el estado de su propio recorrido

26 | P g i n a

UNIVERSIDAD NACIONAL DE TRUJILLO

TECNOLOGA DE LA PROGRAMACIN II

BIBLIOGRAFA
Erich GAMMA; Richard Helm; Ralph Johnson; Jhon Vlissides. Patrones de
Diseo. Elementos de Software orientado a Objetos Reutilizables. PEARSON.
Edicin en Espaol 2003.
BrandonHarris.
http://es.wikipedia.org/wiki/Archivo:Facade_UML_class_diagram.svg
Jess Garca Molina, Anlisis y diseo de software - Patrones de diseo,
dis.um.es/~jmolina/astema3
Erich Gamma (2003). Patrones de diseo. 2. Carlos Bermejo (2005).
Patrones de diseo de software. 3. David Chvez Lpez (2006).Patrones de
diseo en Java. 4. Eduardo Mosqueira Rey (2006) .Patrones de Diseo.
http://modelosprogramacion.blogspot.com/2009/05/nombre-facade.html
http://www.ciberaula.com/articulo/patron_iterator/

27 | P g i n a

You might also like