patron facade e iterator

UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGA DE LA PROGRAMACIN II

1 | P g i n a

UNIVERSIDAD NACIONAL DE

TRUJILLO

FACULTAD DE INGENIERA

ESCUELA DE INGENIERA DE SISTEMAS

PATRN DE DISEO FACADE E ITERATOR

2015

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


2 | P g i n a

PATRN DE DISEO FACADE E ITERATOR

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

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


3 | P g i n a

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.


4 | P g i n a

1. PATRN DE

DISEO FACADE


5 | P g i n a

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

Esta clase aglutina las clases que implementan la funcionalidad del compilador

sin ocultarlas por completo.


6 | P g i n a

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, ...


7 | P g i n a

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.


8 | P g i n a

1.4.2. DIAGRAMA DE CLASES


9 | P g i n a

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.


10 | P g i n a

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.


11 | P g i n a

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.


12 | 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.

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


15 | 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.

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


16 | P g i n a

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:


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

2.4. ESTRUCTURA

2.4.1. DIAGRAMA DE CLASES


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


21 | 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). 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.


22 | P g i n a

DIAGRAMA DEL EMPLO


23 | 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 extends Elemento

{

protected String palabraClaveConsulta;

protected int indice;

protected List contenido;

public void setPalabraClaveConsulta(String

palabraClaveConsulta, List contenido))

{ this.palabraClaveConsulta = palabraClaveConsulta;

this.contenido = contenido;

}

public void inicio()

{


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

{

}

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

{

protected List contenido =

new ArrayList();

protected abstract TIterador creaIterador();

public TIterador busqueda(String palabraClaveConsulta)

{

TIterador resultado = creaIterador();

resultado.setPalabraClaveConsulta(palabraClaveConsulta

, contenido);

return resultado;

}

}


25 | P g i n a

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

{

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.


26 | P g i n a

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


27 | 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_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/

patron facade e iterator

Documents

Transcript of patron facade e iterator