Your SlideShare is downloading. ×
Monografia decorator
Monografia decorator
Monografia decorator
Monografia decorator
Monografia decorator
Monografia decorator
Monografia decorator
Monografia decorator
Monografia decorator
Monografia decorator
Monografia decorator
Monografia decorator
Monografia decorator
Monografia decorator
Monografia decorator
Monografia decorator
Monografia decorator
Monografia decorator
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Monografia decorator

298

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
298
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Tópicos Especiales en Ingeniería De Software UNIVERSIDAD NACIONAL DE TRUJILLO Facultad de Ciencias Físicas y Matemáticas Escuela Profesional de Ingeniería Informática “PATRON DE DISEÑO: DECORATOR” CURSO : Tópicos especiales en Metodología e Ingeniería de Software CICLO : VI PROFESOR : Díaz Pulido Arturo ALUMNA : Malpartida Aranda Vanessa Jaqueline TRUJILLO - PERU 2014 1
  • 2. Tópicos Especiales en Ingeniería De Software INDICE ÍNDICE…………………………………………………………………………………2 DEDICATORIA………………………………………………………………………..3 INTRODUCCIÓN……………………………………………………………………...4 I. Capitulo: Patrón de Diseño Software………………………………….…….....….5 1.1 Reseña Histórica………………………………………………………..……..5 1.2 Definición…………………………………………………………….……….6 1.3 Ventajas y Desventajas………………………………………………….…….7 1.4 Clasificación de Patrones de Diseño……………………....………….….……7 II. Capitulo: Patrón de diseño: Decorator……………………..…………………......10 2.1. Definición…………………………………………………………...……....10 2.2. Características…………………………………………………………….....10 2.3. Componentes…………………………………………………………......…11 2.4. Estructura………………………………………………………..…..……....11 2.5. Ventajas y Desventajas……………………………………………..……….12 2.6. Implementación……………………………………………..………………13 CONCLUSIONES…………………………………………………………………..…17 REFERENCIAS BIBLIOGRÁFICAS………………………………………………...18 2
  • 3. Tópicos Especiales en Ingeniería De Software DEDICATORIA Primeramente a dios por haberme permitido llegar hasta este punto y haberme dado salud, ser el manantial de vida y darme lo necesario para seguir adelante día a día para lograr mis objetivos, además de su infinita bondad y amor. A mi familia por el apoyo brindado en todo momento, por la motivación constante que me ha permitido directa o indirectamente a realizar culminar este documento. A mi maestro por su apoyo constante ofrecido en este trabajo, por haberme transmitidos los conocimientos obtenidos y haberme llevado pasó a paso en el aprendizaje. 3
  • 4. Tópicos Especiales en Ingeniería De Software INTRODUCCION A veces queremos añadir responsabilidades a objetos individuales y no a toda la clase, una interfaz gráfica de usuario toolkit, por ejemplo, en donde se le permite añadir características como los bordes o comportamientos como el desplazamiento de cualquier componente de la interfaz del usuario. Siguiendo con el ejemplo, una forma de añadir responsabilidades es con herencia. Heredar un borde a otra clase pone un borde alrededor de cada subclase instanciada. Esto es inflexible, porque la elección del borde se hace estáticamente. Un cliente no puede controlar cómo y cuándo se decora un componente del borde. Un enfoque más flexible es incluir el componente en otro objeto que se adiciona al borde. El objeto adjuntado se llama decorador, El decorador se ajusta a la interfaz del componente que decora de modo que su presencia es transparente para el cliente de los componentes. Por eso se ha visto la utilidad del patrón Decorator para el uso en sistemas de entretenimiento. Hemos ganado una nueva herramienta que puede ser útil en cualquier contexto en el que tengamos que ‘decorar’ entidades de nuestro sistema. Este mecanismo permite aprovechar las diferentes pinceladas sobre un mismo objeto de forma que podemos utilizarlas cuando nos sea conveniente sin ceñirnos a una jerarquía concreta o a los mecanismos de herencia tradicionales. 4
  • 5. Tópicos Especiales en Ingeniería De Software I. Capitulo: Patrón de Diseño de Software 1.1 Reseña Histórica 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 la que esa mayor calidad se refería a la arquitectura antigua y la menor calidad correspondía a la arquitectura moderna, que el romper con la arquitectura antigua había perdido esa conexión con lo que las personas consideraban que era 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. Dentro de las soluciones de Christopher Alexander se encuentran cómo se deben diseñar ciudades y dónde deben ir las perillas de las puertas. Más tarde, en 1987, Ward Cunningham y Kent Beck, sobrepasados por el pobre entrenamiento que recibían los nuevos programadores en orientación a objetos, se preguntaban cómo se podían capturar las buenas ideas para luego de alguna manera traspasarlas a los nuevos programadores recién instruidos en herencia y polimorfismo. Leyendo a Alexander se dieron cuenta del paralelo que existía entre la buena arquitectura propuesta por Alexander y la buena arquitectura OO, de modo que usaron varias ideas de Alexander para desarrollar cinco patrones de interacción hombre-ordenador (HCI) y publicaron un artículo en OOPSLA87 titulado Using Pattern Languages for OO Programs. No obstante, no fue hasta principios de la década de 1990 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. 5
  • 6. Tópicos Especiales en Ingeniería De Software 1.2 Definición Un patrón de diseño puede considerarse como un documento que define una estructura de clases que aborda una situación particular. Los patrones de diseño software son el esqueleto de las soluciones a problemas comunes en el desarrollo de software. En otras palabras, brindan una solución ya probada y documentada a problemas de desarrollo de software que están sujetos a contextos similares. Los patrones de diseño software pretenden:      Proporcionar catálogos de elementos reusables en el diseño de sistemas software. Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente. Formalizar un vocabulario común entre diseñadores. Estandarizar el modo en que se realiza el diseño. Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente. Asimismo, no pretenden:      Imponer ciertas alternativas de diseño frente a otras. Eliminar la creatividad inherente al proceso de diseño. No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el mismo problema o similar que soluciona el patrón, siempre teniendo en cuenta que en un caso particular puede no ser aplicable. Abusar o forzar el uso de los patrones puede ser un error. Por otro lado, según la publicación del GoF (Hang of Four), guía de referencia en el campo del estudio de los patrones de diseño software. 6
  • 7. Tópicos Especiales en Ingeniería De Software 1.3 Ventajas y Desventajas Como ventajas tenemos, que los patrones proporcionan una estructura conocida por todos los programadores, de manera que la forma de trabajar no resulte distinta entre los mismos. Así mismo la incorporación de un nuevo programador, no requerirá conocimiento de lo realizado anteriormente por otro. También, los patrones permiten tener una estructura de código común a todos los proyectos que implemente una funcionalidad genérica. La utilización de patrones de diseño, permite ahorrar grandes cantidades de tiempo en la construcción de software, así el software construido es más fácil de comprender, mantener y extender. Las desventajas de los patrones de diseño es que provoca la creación de muchos objetos pequeños encadenados lo que puede llegar a complicar la depuración. Así mismo la flexibilidad que provee puede dar problemas, pues da la oportunidad para colocarle muchos deslizadores y varios rebordes, lo que traería como consecuencia que el componente sea poco práctico y de baja calidad. También puede conducir a la proliferación de clases pequeñas. 1.4 Clasificación de Patrones de Diseño Los patrones de diseño se dividen en tres grupos principales: PATRONES DE CREACIÓN  Abstract Factory. Proporciona una interfaz para crear familias de objetos o que dependen entre sí, sin especificar sus clases concretas.  Builder. Separa la construcción de un objeto complejo de su representación, de forma que el mismo proceso de construcción pueda crear diferentes representaciones.  Factory Method. Define una interfaz para crear un objeto, pero deja que sean las subclases quienes decidan qué clase instanciar. Permite que una clase delegue en sus subclases la creación de objetos.  Prototype. Especifica los tipos de objetos a crear por medio de una instancia prototípica, y crear nuevos objetos copiando este prototipo.  Singleton. Garantiza que una clase sólo tenga una instancia, y proporciona un punto de acceso global a ella. 7
  • 8. Tópicos Especiales en Ingeniería De Software PATRONES ESTRUCTURALES  Adapter. Convierte la interfaz de una clase en otra distinta que es la que esperan los clientes. Permiten que cooperen clases que de otra manera no podrían por tener interfaces incompatibles.  Bridge. Desvincula una abstracción de su implementación, de manera que ambas puedan variar de forma independiente.  Composite. Combina objetos en estructuras de árbol para representar jerarquías de parte-todo. Permite que los clientes traten de manera uniforme a los objetos individuales y a los compuestos.  Decorator. Añade dinámicamente nuevas responsabilidades a un objeto, proporcionando una alternativa flexible a la herencia para extender la funcionalidad.  Facade. Proporciona una interfaz unificada para un conjunto de interfaces de un subsistema.  Flyweight. Usa el compartimiento para permitir un gran número de objetos de grano fino de forma eficiente.  Proxy. Proporciona un sustituto o representante de otro objeto para controlar el acceso a éste. PATRONES DE COMPORTAMIENTO   Chain of Responsibility. Crea una cadena con los objetos receptores y pasa la petición a través de la cadena hasta que esta sea tratada por algún objeto. Command. Encapsula una petición en un objeto, permitiendo así parametrizar a los clientes con distintas peticiones, encolar o llevar un registro de las peticiones y poder deshacer la operaciones.  Interpreter. Dado un lenguaje, define una representación de su gramática junto con un intérprete que usa dicha representación para interpretar las sentencias del lenguaje.  Iterator. Proporciona un modo de acceder secuencialmente a los elementos de un objeto agregado sin exponer su representación interna.  Mediator. Define un objeto que encapsula cómo interactúan un conjunto de objetos. Promueve un bajo acoplamiento al evitar que los objetos se 8
  • 9. Tópicos Especiales en Ingeniería De Software refieran unos a otros explícitamente, y permite variar la interacción entre ellos de forma independiente.  Observer. Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambia de estado se notifica y actualizan automáticamente todos los objetos.  State. Permite que un objeto modifique su comportamiento cada vez que cambia su estado interno. Parecerá que cambia la clase del objeto.  Strategy. Define una familia de algoritmos, encapsula uno de ellos y los hace intercambiables. Permite que un algoritmo varíe independientemente de los clientes que lo usan.  Template Method. Define en una operación el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos. Permite que las subclases redefinan ciertos pasos del algoritmo sin cambiar su estructura.  Visitor. Representa una operación sobre los elementos de una estructura de objetos. Permite definir una nueva operación sin cambiar las clases de los elementos sobre los que opera.  Memento. Se utiliza para guardar el estado de un objeto y poder luego restaurar el objeto a un estado previo. 9
  • 10. Tópicos Especiales en Ingeniería De Software II. Capitulo: Patrón de diseño: Decorator 2.1. Definición Decorator es un patrón que se utiliza para incrementar un conjunto de propiedades de un objeto dinámicamente y sin tener que agregar estas propiedades a la clase base, esto quiere decir que el patrón Decorator describe una solución al problema de agregar una funcionalidad a un objeto sin cambiar realmente nada del código en el objeto. También podemos decir que el patrón Decorator es una alternativa para la herencia cuando se identifica que va a ocurrir una "explosión" de subclases, lo que muchas veces ocurre cuando se necesita añadir comportamiento en tiempo de ejecución. 2.2. Características El patrón Decorator responde a la necesidad de añadir dinámicamente funcionalidad a un Objeto, esto nos permite no tener que crear sucesivas clases que hereden de la primera incorporando la nueva funcionalidad, sino otras que la implementan y se asocian a la primera. Permite agregar funcionalidades y responsabilidades a objetos de forma dinámica y transparente para el usuario, esto se realiza por medio de relaciones con otras clases extendiendo su funcionalidad al incorporar las de las clases asociadas, de esta forma el patrón no es dependiente de la Herencia ya que aunque esta puede jugar un papel importante, prevalece el uso de conceptos como la composición al momento de definir comportamientos. Este patrón de diseño nos permite modificar, retirar o agregar responsabilidades a un objeto dinámicamente. Cuando digo dinámicamente, me refiero a que las funcionalidades se modifican/agregan/retiran durante la ejecución del script o aplicación. El patrón decorator permite añadir responsabilidades a objetos concretos de forma dinámica. Los decoradores ofrecen una alternativa más flexible que la herencia para extender las funcionalidades. Este patrón se debe utilizar cuando hay una necesidad de extender la funcionalidad de una clase, pero no hay razones para extenderlo a través de la herencia. Se quiere agregar o quitar dinámicamente la funcionalidad de un objeto. 10
  • 11. Tópicos Especiales en Ingeniería De Software Dado que este patrón decora un objeto y le agrega funcionalidad, suele ser muy utilizado para adicionar opciones de "embellecimiento" en las interfaces al usuario. 2.3. Componentes Componente: Define la interfaz para objetos que pueden tener responsabilidades añadidas a ellos dinámicamente. Componente Concreto: Son las clases cuya funcionalidad se puede extender y en las que se delega en última instancia para realizar las operaciones propias de la clase. Decorador: Es la clase abstracta que declara la estructura común a todos los Decoradores y declara la responsabilidad de mantener una referencia al objeto que se extiende. Es posible que sobrecargue todos los métodos de la clase Componente con llamadas al componente concreto, de forma que aquellos métodos cuya funcionalidad no se extiende simplemente llaman a los originales. Decorador Concreto: Se trata de una clase que hereda de Decorator y que define una funcionalidad concreta a añadir al componente. 2.4. Estructura Fig. 1. Diagrama de clases del modelo de uso del Decorator. 11
  • 12. Tópicos Especiales en Ingeniería De Software 2.5. Ventajas y Desventajas La gran ventaja del patrón Decorator es que nos permite extender objetos incluso en situaciones cuando la extensión vía herencia no es viable o no es necesaria. Adicionalmente nos ayuda a conservar el principio de Abierto/Cerrado, en donde se dicta que cada entidad debe estar abierta a extensión pero cerrada a modificación. También contribuye a reutilizar diseño gráfico, identificando aspectos claves de la estructura de un diseño que puede ser aplicado en una gran cantidad de situaciones. La importancia de la reutilización del diseño no es despreciable, ya que ésta nos provee de numerosas ventajas: reduce los esfuerzos de desarrollo y mantenimiento, mejora la Seguridad informática, eficiencia y consistencia de nuestros diseños, y nos proporciona un considerable ahorro en la inversión. Otra ventaja es que las decoraciones nos evitan la labor de crear clases complejas con mucho código, que en la mayoría de los casos no será evaluado. Nosotros podemos usar distintas combinaciones o secuencias de decoraciones para generar distintos comportamientos o resultados Más flexibilidad que la herencia de clases, El patrón Decorator proporciona una forma más flexible para añadir funciones a los objetos que puede ser mantenido con estático de herencia. Con decoradores, las responsabilidades pueden ser añadir y suprimir en tiempo de ejecución simplemente conectar y desconectar por ellos. En contrario, la herencia exige la creación de una nueva clase por cada. Existen también desventajas acerca del uso del patrón Decorator, por ejemplo si estas decorando demasiado a un objeto, vas a terminar con un montón de decoraciones o clases pequeñas. Si tu código está muy desordenado, entonces se tendrá muchas dificultades tratando de encontrar las clases decorativas. Otra desventaja es el aumento en la complejidad a la hora de instanciar el objeto a ser decorado. El exceso de decoraciones que agregan métodos a un objeto, puede ser problemático si no se especifican que decoraciones extienden el API del objeto y cuáles son los nuevos métodos que se aportan. 12
  • 13. Tópicos Especiales en Ingeniería De Software 2.6. Implementación Varias situaciones deben ser consideradas cuando se desea implementar Decorator:     La conformidad de interfaces. La interfaz de un objeto decorator debe ajustarse a la interfaz del objeto que decora. Omitir la clase abstracta decorator. No hay necesidad de agregar una clase abstracta decorator cuando sólo hay que manejar una responsabilidad. Mantener los componentes de las clases ligeros. Tanto el componente como los decoradores deben descender de una clase común ligera. Debe ser una interfaz y no un almacén de datos. Si la clase componente no es lo suficientemente ligera es mejor utilizar strategy. La clase decorador es realmente muy simple, para explicarlo mejor haremos uso de un ejemplo, Un restaurante de comidas rápidas ofrece 3 tipos de combos (Combo Básico, Combo Familiar, Combo Especial) cada combo tiene características diferentes en cuanto a cantidad, porciones, salsas entre otros, el restaurante también ofrece la posibilidad de aumentar el pedido mediante diferentes porciones adicionales (Tomate, Papas, Carne, Queso), se desea crear un sistema de pedidos que permita al usuario seleccionar el combo deseado, así como armar su propio pedido con las porciones adicionales, el sistema deberá informar sobre el pedido del usuario y el valor total del mismo. En el problema nos están solicitando algo puntual, fácilmente deducimos que tenemos una familia de Combos en la que podemos usar la herencia, pero si atacáramos nuestro problema solo con este concepto, entonces tendríamos que crear clases concretas por cada posible combinación de porciones adicionales, tal vez esto no sería problema y el sistema funcione, pero si queremos realizar varias combinaciones para crear nuevos pedidos tendríamos que entrar a modificar el código fuente y luego ejecutar nuevamente la aplicación para que los cambios puedan ser visualizado, por esta razón anteriormente dijimos que usando la herencia el comportamiento solo se definiría estáticamente basados en lo heredado por las clases Padre. La solución que nos da el patrón Decorator es solo utilizar la herencia para que las clases Decorator tengan el mismo tipo de los objetos a decorar y utilizaremos la composición para determinar el comportamiento de forma dinámica y en tiempo de ejecución basados en concepto de "Usa" relacionando los decoradores con los componentes concretos, así no modificaríamos la lógica de las clases existentes cada vez. 13
  • 14. Tópicos Especiales en Ingeniería De Software Crearemos nuestro sistema ajustándonos al diagrama de clases del patrón, tenemos una SuperClase Combo que representa los combos de comidas rápidas disponibles de la cual heredan los tipos ComboBasico, ComboFamiliar y ComboEspecial, también hereda de él las clases Decorator, en este caso tenemos la clase de Adicionales como el decorador y a su vez las hijas que corresponden a cada porción, siendo estas las clases decoradoras concretas. 14
  • 15. Tópicos Especiales en Ingeniería De Software Componentes. Este paquete contiene la Jerarquía de componentes del patrón, aquí tenemos la SuperClase Combo y sus hijas concretas, el Combo es una clase Abstracta que define una descripción que cada subClase definirá (de que se compone el combo), así como también el método abstracto valor que será definido por cada subClase que lo implemente. La estructura de las clases concretas también es simple, definirán el precio del combo correspondiente y asignaran una descripción. (Cada Clase es igual) Decoradores. Los Decoradores en este caso serán las porciones adicionales, tenemos una clase AdicionalesDecorator que es el decorador principal del cual implementaran los decoradores concretos, esta clase es hija de la clase Combo y proporciona un método abstracto descripción () para anexar a la descripción del combo, la porción seleccionada por el usuario. Cada Decorador concreto implementa el método getDescripcion(), agregando a la descripción la porción seleccionada por el usuario, también implementa el método valor() de la clase Combo, en el cual se agrega al valor del combo, el precio de la porción, como vemos en estos decoradores concretos se aplica la composición en el momento que creamos el objeto combo (la clase Combo es abstracta por lo tanto no puede ser instanciada directamente, por lo tanto el 15
  • 16. Tópicos Especiales en Ingeniería De Software objeto que llega como parámetro al constructor se creó previamente por medio de polimorfismo) Principal. Finalmente en el paquete principal tenemos la clase donde se ejecuta el programa y la ventana que representa el Menú de Selección desde el cual el usuario puede seleccionar el Combo y las porciones a pedir, al enviar el pedido el sistema de forma dinámica por medio del patrón Decorator valida las combinaciones solicitadas y calcula el precio Total del pedido. La lógica del patrón actúa como envoltorios dependiendo de los posibles tipos de combos y adicionales seleccionadas, si queremos un combo familiar con papas extra entonces se crea esta agrupación, de esa manera, al aplicar el patrón pudimos crear un menú de comidas que puede ser construido por el usuario, sin necesidad de modificar cada vez el código fuente. 16
  • 17. Tópicos Especiales en Ingeniería De Software CONCLUCION En conclusión este patrón ayuda a que no prolifere la herencia como fundamento de tus diseños y no sobrecargar la clase base agregando comportamiento, se debe tener cuidado con la generación excesiva de decoradores, elegir con cuidado las funcionalidades que merecen ser decoradas o envueltas. Como vemos el patrón nos facilita enormemente el trabajo en este tipo de problemáticas, imaginemos tener que usar solo la herencia para crear un Menú que cumpla con las necesidades de cada cliente, cuantas combinaciones se tendrían que realizar por cada posible combinación, en cambio con el patrón tan solo necesitamos las clases bases y los decoradores, gracias a la lógica aplicada, las combinaciones se realizan solas. Cuando usamos este patrón reducimos las posibilidades de generar errores o defectos secundarios no deseados, ya que si queremos añadir nuevas funcionalidades, agregamos nuevo código sin modificar el existente. Con el Patrón los diseños son resistentes al cambio y lo suficientemente flexibles como para satisfacer necesidades cambiantes, además de utilizar la herencia y la composición también aplica conceptos de polimorfismo que pueden ser evidenciados en el código fuente. 17
  • 18. Tópicos Especiales en Ingeniería De Software REFERENCIAS BIBLIOGRAFICAS 1. Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns. Elements of Reusable Object-Oriented Software 2. Addison Wesley. (1995). Design Patterns. 3. GUERRA, Esther. (2009). Técnicas de Programación. Universidad Carlos III de Madrid. España 4. MARTELLI, Alex. (2007). Design Patterns in Python. 5. Sellares, Toni. (2013). The Decorator Pattern. Universitat de Girona. España 6. Yorio, Dario. Identificación y Clasificación de Patrones en el Diseño de Aplicaciones Móviles. Universidad Nacional de la Plata. Tesis. 7. P.S.C. Alencar, D.D. Cowan, Thomas Kunz, and C.J.P. Lucena. (1996). A Formal Architectural Design Patterns-Based Approach to Software Understanding. Proceedings of the 4th International Workshop on Program Comprehension. 8. B, Appleton. (2000). Patterns and Software: Essential Concepts and Terminology. Synthesis of material from many knowledgeable and well respected members of the patterns community. 9. Peñaranda Cordero Yesenia. (2012). Patrón Decorador. 10. Benitez Romero, Juan. Vives Abrines Javier. (). Decorator y Prototype. 18

×