Curso de java básico (scjp)

Presentación del tema: "Curso de java básico (scjp)"— Transcripción de la presentación:

1 Curso de java básico (scjp)

2 Introducción a los patrones de diseño

3 Objetivos generales Definir qué es un patrón de diseño.
Cuándo utilizarlos. Clasificación de patrones. Patrones mas importantes. Ejemplos

4 Qué es un Patrón de Diseño?
El diseño es una actividad El cómo frente al qué Hacerlo correcto frente a hacer lo correcto Asignar responsabilidades a las clases Un patrón describe soluciones a problemas que surgen cuando se desarrolla software dentro de un contexto particular. Son descripciones de soluciones a problemas de diseño general que se repiten una y otra vez. Un patrón de diseño nos brinda las siguientes respuestas: Problema: Qué problema de diseño soluciona? Solución: Cómo solucionar el problema? Contexto: Precondiciones para que se pueda aplicar el pattern. Restricciones: Qué afecta la aplicación del pattern

5 Qué es un Patrón de Diseño?
Algunas propiedades no funcionales Reutilización Facilidad de modificación Facilidad de comprensión Robustez Eficiencia Facilidad de uso Dentro de las propiedades no funcionales vemos que: Reutilización: nos permite que el código sea reutilizable. Facilidad de modificación: nos permite que el costo de cambio en el código de alguna funcionalidad sea mínimo. Facilidad de comprensión: el aplicar patrones de diseño, ayuda a que el código sea legible y se entienda mejor su diseño. Robustez: permite que la aplicación sea robusta, bien definida y diseñada. Eficiencia: permite que el sistema sea eficiente. Facilidad de uso: la aplicación de un patrón es simple, solo basta con adaptar las situaciones plateadas y aplicación de cada patrón.

6 Qué es un Patrón de Diseño?
Definición: Patrón: Modelo que sirve de muestra para sacar otra cosa igual (RAE). Patrón de diseño: Una solución general a un problema general que puede adaptarse a un problema concreto. Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno. También describe el núcleo de la solución al problema, de forma que puede utilizarse un millón de veces sin hacer dos veces lo mismo

7 Historia Christopher Alexander - 1979 - The Timeless Way of Building.
Definió qué es un patrón de diseño Pattern Language. 1987, Ward Cunningham y Kent Beck Design Patterns - GoF En 1979 el arquitecto Christopher Alexander aportó al mundo de la arquitectura el libro The Timeless Way of Building; en él proponía el aprendizaje y uso de una serie de patrones para la construcción de edificios de una mayor calidad. En palabras de este autor, "Cada patrón describe un problema que ocurre infinidad de veces en nuestro entorno, así como la solución al mismo, de tal modo que podemos utilizar esta solución un millón de veces más adelante sin tener que volver a pensarla otra vez.“ Los patrones que Christopher Alexander y sus colegas definieron, publicados en un volumen denominado A Pattern Language, son un intento de formalizar y plasmar de una forma práctica generaciones de conocimiento arquitectónico. Los patrones no son principios abstractos que requieran su redescubrimiento para obtener una aplicación satisfactoria, ni son específicos a una situación particular o cultural; son algo intermedio. Un patrón define una posible solución correcta para un problema de diseño dentro de un contexto dado, describiendo las cualidades invariantes de todas las soluciones.

8 Más tarde, en 1987, Ward Cunningham y Kent Beck usaron varias ideas de Alexander para desarrollar cinco patrones de interacción hombre-ordenador (HCI) y publicaron un artículo en OOPSLA-87 titulado Using Pattern Languages for OO Programs. No obstante, no fue hasta principios de los 90's cuando los patrones de diseño tuvieron un gran éxito en el mundo de la informática a partir de la publicación del libro Design Patterns escrito por el grupo Gang of Four (GoF) compuesto por Erich Gamma, Richard Helm, Ralph Johnson y John Vlisides, en el que se recogían 23 patrones de diseño comunes.

9 Categorías de Patrones
Según la escala o nivel de abstracción: Patrones de arquitectura Patrones de diseño Patrones de Análisis Patrones de bajo nivel(idiomas) Patrones de arquitectura: Aquéllos que expresan un esquema organizativo estructural fundamental para sistemas software. Patrones de diseño: Aquéllos que expresan esquemas para definir estructuras de diseño (o sus relaciones) con las que construir sistemas software. Patrones de Análisis: Expresan estructuras comunes que surgen durante el análisis. Idiomas: Patrones de bajo nivel específicos para un lenguaje de programación o entorno concreto.

10 Estructuras o plantillas de patrones
La plantilla mas común es la utilizada por el GoF y consta de los siguientes apartados: Nombre de patrón Clasificación del patrón Intención Motivación Aplicabilidad Estructura Participantes Colaboraciones Consecuencias Implementación Código de ejemplo Patrones relacionados Nombre de patrón: Nombre estándar del patrón por el cual será reconocido en la comunidad. Clasificación del patrón: creacional, estructural o de comportamiento. Intención: ¿Qué problema pretende resolver el patrón? Motivación: Escenario de ejemplo para la aplicación del patrón. Aplicabilidad: Usos comunes y criterios de aplicabilidad del patrón. Estructura: Diagramas de clases oportunos para describir las clases que intervienen en el patrón. Participantes: Enumeración y descripción de las entidades abstractas (y sus roles) que participan en el patrón. Colaboraciones: Explicación de las interrelaciones que se dan entre los participantes. Consecuencias: Consecuencias positivas y negativas en el diseño derivadas de la aplicación del patrón. Implementación: Técnicas o comentarios oportunos de cara a la implementación del patrón. Código de ejemplo: Código fuente ejemplo de implementación del patrón.Usos conocidos: Ejemplos de sistemas reales que usan el patrón. Patrones relacionados: Referencias cruzadas con otros patrones.

11 Clasificación Clasificación de patrones del libro GoF: Creacionales
Estructurales Comportamiento Creacionales: Creación de objetos Estructurales: Composición de clases Comportamiento: Interacción de objetos

12 Patrones Creacionales
Abstract Factory – (Fabrica abstracta) Builder – (Constructor virtual) Factory Method – (Método de fabricación) Prototype – (Prototipo) Singleton – (Instancia Única) Abstract Factory (Fábrica abstracta): Permite trabajar con objetos de distintas familias de manera que las familias no se mezclen entre sí y haciendo transparente el tipo de familia concreta que se esté usando. Builder (Constructor virtual): Abstrae el proceso de creación de un objeto complejo, centralizando dicho proceso en un único punto. Factory Method (Método de fabricación): Centraliza en una clase constructora la creación de objetos de un subtipo de un tipo determinado, ocultando al usuario la casuística para elegir el subtipo que crear. Prototype (Prototipo): Crea nuevos objetos clonándolos de una instancia ya existente. Singleton (Instancia única): Garantiza la existencia de una única instancia para una clase y la creación de un mecanismo de acceso global a dicha instancia.

13 Patrones Estructurales
Adapter – (Adaptador) Bridge – (Puente) Composite – (Objeto compuesto) Decorator – (Envoltorio) Facade – (Fachada) Flyweight – (Pero ligero) Proxy Adapter (Adaptador): Adapta una interfaz para que pueda ser utilizada por una clase que de otro modo no podría utilizarla. Bridge (Puente): Desacopla una abstracción de su implementación. Composite (Objeto compuesto): Permite tratar objetos compuestos como si de uno simple se tratase. Decorator (Envoltorio): Añade funcionalidad a una clase dinámicamente. Facade (Fachada): Provee de una interfaz unificada simple para acceder a una interfaz o grupo de interfaces de un subsistema. Flyweight (Peso ligero): Reduce la redundancia cuando gran cantidad de objetos poseen idéntica información. Proxy: Mantiene un representante de un objeto.

14 Patrones Comportamiento
Patrones de comportamiento: Chain of Responsability – (Cadena de responsabilidad) Command – (Orden) Interpreter – (Interprete) Iterator – (Iterador) Mediator – (Mediador) Chain of Responsibility (Cadena de responsabilidad): Permite establecer la línea que deben llevar los mensajes para que los objetos realicen la tarea indicada. Command (Orden): Encapsula una operación en un objeto, permitiendo ejecutar dicha operación sin necesidad de conocer el contenido de la misma. Interpreter (Intérprete): Dado un lenguaje, define una gramática para dicho lenguaje, así como las herramientas necesarias para interpretarlo. Iterator (Iterador): Permite realizar recorridos sobre objetos compuestos independientemente de la implementación de estos. Mediator (Mediador): Define un objeto que coordine la comunicación entre objetos de distintas clases, pero que funcionan como un conjunto.

15 Patrones Comportamiento
Patrones de comportamiento: Chain of Responsability – (Cadena de responsabilidad) Command – (Orden) Interpreter – (Interprete) Iterator – (Iterador) Mediator – (Mediador) Memento – (Recuerdo) Observer – (Observador) State – (Estado) Strategy – (Estrategia) Template Method – (Método plantilla) Visitor – (Visitante) Chain of Responsibility (Cadena de responsabilidad): Permite establecer la línea que deben llevar los mensajes para que los objetos realicen la tarea indicada. Command (Orden): Encapsula una operación en un objeto, permitiendo ejecutar dicha operación sin necesidad de conocer el contenido de la misma. Interpreter (Intérprete): Dado un lenguaje, define una gramática para dicho lenguaje, así como las herramientas necesarias para interpretarlo. Iterator (Iterador): Permite realizar recorridos sobre objetos compuestos independientemente de la implementación de estos. Mediator (Mediador): Define un objeto que coordine la comunicación entre objetos de distintas clases, pero que funcionan como un conjunto. Memento (Recuerdo): Permite volver a estados anteriores del sistema. Observer (Observador): Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambie de estado se notifique y actualicen automáticamente todos los objetos que dependen de él. State (Estado): Permite que un objeto modifique su comportamiento cada vez que cambie su estado interno. Strategy (Estrategia): Permite disponer de varios métodos para resolver un problema y elegir cuál utilizar en tiempo de ejecución.

16 Template Method (Método plantilla): Define en una operación el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos, esto permite que las subclases redefinan ciertos pasos de un algoritmo sin cambiar su estructura. Visitor (Visitante): Permite definir nuevas operaciones sobre una jerarquía de clases sin modificar las clases sobre las que opera.

17 Patrones importantes En las próximas transparencias mostraremos los patrones más importantes que los alumnos deben saber, para desarrollar la mayor cantidad de problemas. Estos son: Strategy State Singleton Composite Template Method Proxy Observer Iterator Facade

18 Patrón - Strategy Intención:
Definir un grupo de clases que representan un conjunto de posibles comportamientos. Estos comportamientos pueden ser fácilmente intercambiados en una aplicación modificando la funcionalidad en cualquier instante. Motivación: Estructurar una familia de algoritmos de modo que sus clientes puedan intercambiarlos en tiempo de ejecución. El patrón Strategy define una familia de algoritmos. Los cuales están encapsulados lo cual los hace intercambiables. Este patrón permite que el algoritmo varíe independientemente, según el objeto que lo use. También es conocido como patrón Policy

19 Patrón - Strategy En el siguiente diagrama vemos que la clase StrategyClient, posee un método llamado performStrategicMethod, el cual dentro de su bloque, contiene la siguiente línea de código: strategy.strategicMethod(); La idea es que según el tipo de objeto que sea strategy, se ejecutara el método de alguna de las clases que heredan de la interace IStrategy. Ejemplo: Strategy1 strategy = new Strategy1();

20 Patrón - Strategy Participantes:
Istrategy: declara una interfaz común para todos las variantes de un algoritmo StrategyX: implementa una variable del algoritmo StrategyClient: es el responsable de crear y mantener una referencia a una estrategia concreta. Colaboraciones: El cliente de la estrategia decide la estrategia a crear. Consecuencias: Factoriza aspectos comunes de una familia de algoritmos y utilizarlos en las clases base de la jerarquía. Aumenta cohesión del cliente. Sistematiza el uso de implementaciones alternativas. El cliente es el responsable de crear estrategias, por tanto debe comprender las responsabilidades que ofrecen. Menor eficiencia. Aumento el numero de objetos creados.

21 Patrón - State Intención:
Cambiar fácilmente el comportamiento de un objeto en tiempo de ejecución. Motivación: Cambiar el comportamiento dependiendo del estado. Cuando queremos que un objeto cambie su comportamiento, según cambia su estado, se presenta el problema de la complejidad de código.

22 Patrón - State El patrón State permite a un objeto alterar su comportamiento cuando su estado interno cambia. Como vemos en el diagrama, la clase cliente, utiliza la clase Context para cambiar su estado. En base a ese cambio, el objeto podrá alterar su comportamiento según los estados definidos en: StateOne, StateTwo y StateThree.

23 Patrón - State Participantes:
Context: Define la Interfaz y mantiene una instancia con el estado actual. State: Define una interfaz para el comportamiento asociado a un determinado estado del Contexto. ConcreteState: Cada subclase implementa el comportamiento asociado con un estado del contexto. Consecuencias: Localiza el comportamiento dependiente del estado y divide dicho comportamiento en diferentes estados. Hace explícitas las transiciones entre estados. Los objetos Estado pueden compartirse.

24 Patrón - Singleton Intención:
Garantizar que una clase sólo tenga una instancia y proporcionar un punto de acceso global a ella. Motivación: Es importante que algunas clases tengan exactamente una instancia. Ejemplo: aunque puede haber muchas impresoras en un sistema, sólo debería haber una cola de impresión. Una variable global hace accesible a un objeto, pero no nos previene de crear múltiples instancias de un objeto.

25 Patrón - Singleton Como mencionamos anteriormente, el patrón Singleton es utilizado para asegurarnos que solo una instancia de dicha clase es creada. Para ello, es que se limita el acceso al constructor de la misma, con visibilidad private, pudiendo acceder a la única instancia creada a través del metodo getInstance(). El código seria el siguiente: public class Empresa { private Empresa empresa= new Empresa(); private Empresa(){} public Empresa getInstance(){ return empresa; }

26 Patrón - Singleton Participantes:
Singleton: Define una operación getInstance que permite que los clientes, accedan a su única instancia. GetInstance() es una operación de clase (es decir en java, tiene el modificador static). Es el responsable de crear su única instancia.

27 Patrón - Singleton Consecuencias:
Acceso controlado a su única instancia. Puesto que la misma encapsula su única instancia, puede tener un control estricto sobre cómo y cuándo acceden a ella los clientes. El patrón Singleton es una mejora sobre las variables globales. Ya que evita contaminar el espacio de nombres con instancias de clases. El patrón hace fácil cambiar de opinión y poder crear más de una instancia de la clase.

28 Patrón - Composite Intención:
Componer objetos en jerarquías parte-todo y permitir a los clientes tratar objetos simples y compuestos de modo uniforme. Motivación: Necesitamos representar un conjunto de elementos de una interfaz gráfica de usuario. Algunos de estos elementos son simples, mientras que otros están formados por varios elementos más simples. El comportamiento y/o la información que proporciona un elemento complejo está determinada por los elementos que lo componen.

29 Patrón - Composite Este patrón de diseño nos permite componer objetos en estructuras de arboles para representar jerarquías. Permite tratar objetos individuales y composiciones de objetos de forma uniforme. Como vemos en el diagrama, este patrón define una estructura de árbol. Un ejemplo practico lo vemos en la representación de un sistema de archivos, donde una carpeta esta formada por carpetas, y cada carpeta posee carpetas. En este ejemplo, la carpeta raíz: C:// es un componente, el cual posee hijos: todas las carpetas (objetos Composite). Las carpetas que no poseen carpetas, serian las hojas (Leaf). Como vemos, la estructura definida es recursiva.

30 Patrón - Composite Participantes:
Client: Manipula objetos a través de la interfaz proporcionada por Component. Component: Declara la interfaz para los objetos de la composición, es la interfaz de acceso y manipulación de los componentes hijo e implementa algunos comportamientos por defecto.

31 Patrón - Composite Participantes:
Composite: Define el comportamiento de los componentes compuestos, almacena a los hijos e implementa las operaciones de manejo de los componentes. Leaf: Definen comportamientos para objetos primitivos del compuesto.

32 Patrón - Composite Colaboración:
Los clientes utilizan la interfaz de la clase component para interactuar con los elementos de la estructura compuesta. Si el recipiente es una hora, se trata correctamente, sino se redirige la petición a sus hijos realizando operaciones adicionales

33 Patrón - Composite Consecuencias:
Define jerarquías de clases formadas por objetos primitivos y compuestos. Simplifica al cliente, ya que puede tratar de forma uniforme estructuras compuestas. La desventaja de facilitar añadir nuevos componentes es que hace difícil restringir los componentes de un compuesto.

34 Patrón – Template Method
Intención: Proporcionar un método que permite que las subclases redefinan parte del método sin reescribirlo. Motivación: Cuando se construyen jerarquías de clases complejas para una aplicación, a menudo se duplican distintas partes de código. esa situación no es deseable, porque la intención es reutilizar tanto código como sea posible . La refactorización de código para que los métodos comunes estén en una superclase es un paso en la dirección correcta. El problema es que algunas veces una operación que ha sido refactorizada confía en la información especifica que solamente esta disponible en una subclase. Debido a esto, los desarrolladores a menudo deciden no refactorizar y aceptar la presencia de código duplicado en distintas clases.

35 Patrón - Template Method
Este patrón define el esqueleto de un algoritmo en una operación, difiriendo en algunos pasos en la sub clase. Este permite que en las sub clases, se redefinan ciertas operaciones de un algoritmo sin cambiar la estructura del algoritmo principal. Un claro ejemplo es una clase Empleado, la cual contenga un método calcularSueldo();. Según ciertos factores, el sueldo de un empleado ira variando. Esa variación, la cual esta dada por la forma en que se realiza el calculo, es un ejemplo de aplicación de este patrón, ya que según cada tipo de empleado, los descuentos aplicados irán variando

36 Patrón - Template Method
Participantes: Client: Manipula objetos a través de la interfaz proporcionada por Component. AbstractTemplate: Implementa un método plantilla que define el esqueleto de un algoritmo y define métodos abstractos que implementan las subclases concretas.

37 Patrón - Template Method
Participantes: ConcreteTemplate: Implementa los métodos abstractos para realizar los pasos del algoritmo que son específicos de la subclase.. Colaboración: Las clases concretas confían en que la clase abstracta implemente la parte fija del algoritmo.

38 Patrón - Template Method
Consecuencias: Favorece la reutilización del código. Muy útiles para construir bibliotecas, pues ayuda a factorizar el comportamiento común de las clases. Lleva a una estructura de control invertido (Principio de Hollywood): la superclase base invoca los métodos de las subclases.

39 Patrón – Proxy Intención:
Proporcionar un representante de otro objeto, por distintas razones como pueden ser el acceso, la velocidad o la seguridad, entre otras. Motivación: Retrasar el coste de crear e inicializar un objeto hasta que es realmente necesario. Por ejemplo, no abrir las imágenes de un documento hasta que no son visibles. Puede haber ocasiones en que se desee posponer el coste de la creación de un objeto hasta que sea necesario usarlo. El objeto proxy actúa en lugar del verdadero objeto, y ofrece las misma interfaz, y las solicita en el objeto cuando es necesario.

40 Patrón - Proxy Este patrón provee un sustituto o representante de otro objeto, de manera de controlar el acceso a el. En el diagrama, vemos que el objeto real es: RealSubject, y el representante es el objeto Proxy. Este patrón suele ser utilizado cuando se quiere limitar el acceso a un objeto, para ello, se envía un representante de objeto real, el puede o no contener todos los datos del mismo. También es utilizado para aminorar la carga de los sistemas, de manera tal que solo se envíe la información que se necesita.

41 Patrón - Proxy Participantes:
Subject: Define la interfaz común para el RealSubject y el proxy, de modo que pueda usarse un Proxy en cualquier sitio en el que se espere un RealSubject. RealSubject: Define el objeto real representado. Proxy: Mantiene una referencia que permite al Proxy acceder al objeto real, Proporciona una interfaz idéntica a la del sujeto, de manera que un Proxy pueda ser sustituido por el sujeto real. Controla el acceso al sujeto real, y puede ser responsable de su creación y borrado.

42 Patrón - Proxy Consecuencias:
El patrón Proxy introduce un nivel de indirección al acceso a un objeto. Esta indirección adicional tiene muchos posibles usos, dependiendo del tipo de proxy. Intención: Proporcionar a los componentes una forma flexible de enviar mensajes de difusión a los receptores interesados. Un proxy remoto puede ocultar el hecho de que un objeto reside en un espacio de direcciones diferente. Un proxy virtual puede llevar a cabo optimizaciones tales como crear un objeto por encargo. Tales como los proxies de protección como las referencias inteligentes permiten realizar tareas adicionales cuando se accede a un objeto.

43 Patrón – Observer Motivación:
Muchas veces un efecto lateral de partir un sistema en una colección de objetos relacionados es que necesitamos mantener la consistencia entre objetos relacionados.

44 Patrón - Observer Este patrón define una dependencia uno a muchos entre objetos que cuando uno de ellos cambia de estado, todos los dependientes son notificados y actualizados automáticamente. Un ejemplo simple seria: Imaginemos que tenemos 3 supermercados. En cada uno, tenemos un programa que lleva el stock de la mercadería. Si en una sucursal, se ingresara mercadería nueva, las demás sucursales querrían ser notificadas de ese nuevo ingreso de mercadería, de manera que si un cliente solicita cierto producto, el vendedor pueda decirle si poseen o no stock y en que sucursal se encuentra disponible. En este caso, todas las sucursales deberían ser notificadas sobre el nuevo ingreso, teniendo una relación, o dependencia de uno a muchos.

45 Patrón - Observer Participantes:
Subject: Conoce a sus observadores, Proporciona una Interfaz para que se suscriban los objetos Observer. Observer: Define una interfaz para actualizar los objetos que deben ser notificados de cambios en el objeto Subject. ConcreteSubject: Guarda el estado de interés para los objetos ConcreteObserver, envía una notificación a sus observadores cuando cambia su estado.

46 Patrón - Observer Participantes:
ConcreteObserver: Mantiene una referencia a un objeto ConcreteSubject, Guarda el estado que debería permanecer sincronizado con el objeto observado, Implementa la interfaz Observer para mantener su estado consistente con el objeto observado.

47 Patrón - Observer Colaboraciones
El objeto observado notifica a sus observadores cada vez que ocurre un cambio. Después de ser informado de un cambio en el objeto observado, cada observador concreto puede pedirle la información que necesita para reconciliar su estado con el de aquél.

48 Patrón – Iterator Intención:
Proporcionar una forma coherente de acceder secuencialmente a los elementos de una colección, independientemente del tipo de colección subyacente. Motivación: Un objeto agregado, tal como una lista, debería proveer un modo de brindar acceso a sus elementos sin exponer su estructura interna. Más aún, quizás se desea recorrer la lista en diferentes formas, dependiendo de lo que Ud. quiera realizar. La idea principal en este patrón es tomar la responsabilidad del acceso y recorrido de la lista y colocarla dentro del objeto iterator. La clase Iterator define una interfaz para el acceso de los elementos de la lista. Un objeto iterador es responsable de mantener la pista del elemento actual; esto es, sabe cuáles elementos ya han sido recorridos.

49 Patrón - Iterator El patrón Iterator, provee una forma de acceder a elementos de una secuencia, sin exponer la representación de cada uno de ellos. Como vemos en el ejemplo, la clase Iterator provee métodos para acceder a los elementos de una secuencia, sin importar el tipo o la estructura de los mismos.

50 Patrón - Iterator Participantes:
Iterador: Define una interfaz para recorrer los agregados. IteradorConcreto: implementa la interfaz iterador. Agregado: Define la interfaz para crear un objeto iterador. AgregadoConcreto: Implementa la interfaz de creación de un iterador para devolver un iterador concreto.

51 Patrón - Iterator Colaboraciones:
Un iteradorConcreto almacena la posición del objetoactual en el agregado de modo que sabe cual es el objeto siguiente en el recorrido.

52 Patrón – Facade Intención:
Proporcionar una interfaz simplificada para un grupo de subsistemas o un sistema complejo. Motivación: Simplificar el acceso a un conjunto de clases proporcionando una única clase que todos utilizan para comunicarse con dicho conjunto de clases. Reducir la complejidad y minimizar dependencias

53 Patrón - Facade El patrón Façade, provee una interfaz unificada a una serie de interfaces en un subsistema. Es decir, que el único punto de acceso al sistema es a través de ella, por lo que logra modularizarlo y separar las responsabilidades de cada clase. Este patrón permite reducir la complejidad y minimizar la comunicación y dependencias entre los distintos subsistemas.

54 Patrón - Facade Participantes:
Facade: Conoce cuales clases del subsistema son responsables de una petición y delega las peticiones de los clientes en los objetos del subsistema. Clases del subsistema: Implementan la funcionalidad del subsistema, manejan el trabajo asignado por el objeto Facade y además de esto no tienen ningún conocimiento del Facade.

55 Patrón - Facade Consecuencias:
Oculta a los clientes el comportamiento del subsistema, haciendo que este sea mas fácil de usar. Promueve un débil acoplamiento entre subsistemas

56 Resumen Patrones de diseño. Clasificación de patrones. Historia
Lista de Patrones Patrones más importantes. Ejercicios

57 Referencias GoF – Gang of Four