Patrón Facade e Iterator

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
GRUPO N 6ITERATOR
DELGADO
CHAO,
(Coordinador)
IPARRAGUIRRE SIXE, ABNER
MONTERO MACO, GUSTAVO
ROJAS ALARCON, JORDAN
ROJAS LPEZ, JOS YERSON
CRISTHIAN
CURSO:
TECNOLOGA DE LA PROGRAMCIN II
DOCENTE:
Mg. VIDAL MELGAREJO ZORAIDA YANET
CICLO:
V
1|Pgina
PATRN DE DISEO FACADE E ITERATOR

NDICE
INTRODUCCIN.......................................................................
1. 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
2. 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|Pgina
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|Pgina
. PATRN DE DISEO FACAD

4|Pgina
1.1. 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
5|Pgina
Esta clase aglutina las clases que implementan la funcionalidad

del compilador sin ocultarlas por completo.
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|Pgina
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.
1.4.2.
DIAGRAMA DE CLASES
7|Pgina
1.4.3.
PARTICIPANTES
Los participantes del patrn son los siguientes:

8|Pgina
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|Pgina
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
funciones o mtodos sencillos y claros.
tareas
en
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
10 | P g i n a
los clientes, que slo necesitan un acceso simple que

responda a sus exigencias.
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
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.
12 | P g i n a
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.
13 | P g i n a
14 | P g i n a
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.
15 | P g i n a
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 destinados a los clientes del servicio web.
16 | P g i n a
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:
17 | P g i n a
2. PATRN DE DISEO ITERATOR

18 | P g i n a
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
19 | P g i n a
20 | P g i n a
2.4. ESTRUCTURA
2.4.1. DIAGRAMA DE CLASES
21 | P g i n a
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
22 | P g i n a
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.
23 | P g i n a
Las subclases CatlogoVehculo e IteradorVehculo heredan

mediante una relacin que fija los tipos de parmetros de genericidad
de sus superclases respectivas.
DIAGRAMA DEL EMPLO
24 | P g i n a
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()
25 | P g i n a

{
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);
26 | P g i n a
return resultado;
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
CatalogoVehiculo(); IteradorVehiculo
catalogo.busqueda(
"economico")
;
Vehiculo vehiculo;
iterador.inicio();
vehiculo = iterador.item();
while (vehiculo != null)
{
vehiculo.visualiza();
iterador.siguiente();
vehiculo
iterador.item();
}
=
new
iterador =
27 | P g i n a
La ejecucin de este programa produce el resultado

siguiente:
Descripcin del vehculo: vehculo econmico
Descripcin del vehculo: pequeo vehculo econmico.
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
28 | P g i n a
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_di
agram.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/nom
bre-facade.html
http://www.ciberaula.com/articulo/patron_iterator/
29 | P g i n a

Patrón Facade e Iterator

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Patrón Facade e Iterator

Загружено:

Авторское право:

Доступные форматы

UNIVERSIDAD NACIONAL DE TRUJILLO

UNIVERSIDAD NACIONAL DE TRUJILLO

PATRN DE DISEO FACADE E ITERATOR

UNIVERSIDAD NACIONAL DE TRUJILLO

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

El Patrn Fachada se caracteriza por ser una puerta de entrada hacia

El patrn Facade nos permite simplificar la interfaz de comunicacin

UNIVERSIDAD NACIONAL DE TRUJILLO

. PATRN DE DISEO FACAD

UNIVERSIDAD NACIONAL DE TRUJILLO

UNIVERSIDAD NACIONAL DE TRUJILLO

Esta clase aglutina las clases que implementan la funcionalidad

Por ejemplo, se tiene la clase A debe saber cul es

de B, c1() de C, d1() de D, ...

UNIVERSIDAD NACIONAL DE TRUJILLO

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

En estos caso, se puede usar este patrn de la siguiente

UNIVERSIDAD NACIONAL DE TRUJILLO

Los participantes del patrn son los siguientes:

UNIVERSIDAD NACIONAL DE TRUJILLO

Fachada (WebServiceAuto) y su interfaz constituyen

Los clientes se comunican con el sistema a travs de la fachada

UNIVERSIDAD NACIONAL DE TRUJILLO

Usos conocidos problemas y soluciones:

Problema: Una biblioteca es difcilmente legible. Solucin:

UNIVERSIDAD NACIONAL DE TRUJILLO

los clientes, que slo necesitan un acceso simple que

El patrn Abstract Factory puede proporcionar una

UNIVERSIDAD NACIONAL DE TRUJILLO

Queremos ofrecer la posibilidad de acceder al sistema de venta

Es posible dar acceso al conjunto de la interfaz de estos componentes

UNIVERSIDAD NACIONAL DE TRUJILLO

Conviene observar que si bien la idea del patrn es construir una

UNIVERSIDAD NACIONAL DE TRUJILLO

UNIVERSIDAD NACIONAL DE TRUJILLO

Continuamos con el componente de gestin de documentos

UNIVERSIDAD NACIONAL DE TRUJILLO

La clase WebServiceAutoImpl implementa ambos mtodos.

La interfaz de la fachada llamada WebServiceAuto define la firma

UNIVERSIDAD NACIONAL DE TRUJILLO

Este cliente muestra dos documentos as como los vehculos cuyo

UNIVERSIDAD NACIONAL DE TRUJILLO

2. PATRN DE DISEO ITERATOR

UNIVERSIDAD NACIONAL DE TRUJILLO

UNIVERSIDAD NACIONAL DE TRUJILLO

UNIVERSIDAD NACIONAL DE TRUJILLO

UNIVERSIDAD NACIONAL DE TRUJILLO

UNIVERSIDAD NACIONAL DE TRUJILLO

Queremos proporcionar un acceso secuencial a los vehculos que

UNIVERSIDAD NACIONAL DE TRUJILLO

Las subclases CatlogoVehculo e IteradorVehculo heredan

UNIVERSIDAD NACIONAL DE TRUJILLO

Presentamos a continuacin un ejemplo escrito en Java del

public boolean palabraClaveValida(String palabraClave)

La subclase concreta Vehiculo incluye un mtodo visualiza.

La clase Iterador incluye los mtodos inicio, siguiente, item

UNIVERSIDAD NACIONAL DE TRUJILLO

public void siguiente()

public TElemento item()

La subclase IteradorVehiculo se contenta con enlazar

La clase Catalogo gestiona el atributo contenido que es la

UNIVERSIDAD NACIONAL DE TRUJILLO

La subclase concreta CatalogoVehiculo relaciona TElemento

Un constructor que construye la coleccin de vehculos