Monografia decorator

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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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

Monografia decorator

Recomendados

Recomendados

Más contenido relacionado

Similar a Monografia decorator

Similar a Monografia decorator (20)

Último

Último (20)

Monografia decorator