UNIVERSIDAD SAN PEDRO

ESCUELA
Sistemas

Ingeniera Informtica y de

CURSO

Ingenieria de Sotware II

TEMA

Patrones de Diseo

DOCENTE
Victor

Albinagorta

INTEGRANTES
Kline

Lopez

Ordoez,

Campomanez

2015
HUARAZ ANCASH
PER

Felix
Kevin

NDICE
Introduccin................................................................................................... 6
1.

Qu es un patrn?............................................................................... 7
1.1.

Definiciones:...................................................................................... 7

2.

Desarrollo histrico............................................................................... 8

3.

Tipos de patrones................................................................................. 9

4.

5.

6.

7.

3.1.

Patrones de Creacin..........................................................................9

3.2.

Patrones Estructurales:.......................................................................9

3.3.

Patrones De Comportamiento...............................................................9

3.4.

Patrones de interfaces de usuario:..........................................................9

3.5.

Patrones para la construccin de sistemas empresariales:...........................9

3.6.

Patrones para la integracin de sistemas:................................................9

3.7.

Patrones de flujos de trabajo:...............................................................9

Patrones de Diseo Software de Creacin.............................................9

4.1.

Abstract Factory........................................................................... 10

4.2.

Factory Method............................................................................. 11

4.3.

Prototype...................................................................................... 12

4.4.

Esquema Singleton.......................................................................13

Patrones de Diseo Software de Comportamiento..............................15

5.1.

Command..................................................................................... 15

5.2.

Iterator......................................................................................... 16

5.3.

Observer....................................................................................... 18

5.4.

Strategy........................................................................................... 19

Patrones de Diseo Software Estructurales........................................21

6.1.

Adapter......................................................................................... 21

6.2.

Composite.................................................................................... 23

6.3.

Decorator..................................................................................... 24

6.4.

Proxy............................................................................................. 25

Bibliografia.......................................................................................... 28

NDICE DE FIGURA
Imagen 1________________________________________________________________11
Imagen 2________________________________________________________________12
Imagen 3: Este sera el diagrama de clases general del patrn:___13
Imagen 4________________________________________________________________14
Imagen 5: Esquema del patrn Command____________________________16
Imagen 6: Esquema del patrn Iterator______________________________18
Imagen 7: Esquema del patrn Observer_____________________________19
Imagen 8: Esquema del patrn Strategy_____________________________21
Imagen 9: Esquema del patrn Adapter______________________________22
Imagen 10: Esquema del patrn Composite__________________________24
Imagen 11: Esquema del patrn Decorator__________________________25
Imagen 12: Esquema del patrn Proxy_______________________________26

Resumen

Este paradigma viene dado por deteccin de la repeticin constante de problemas en los
distintos diseos orientados a objetos, lo que conlleva que se defina una coleccin de
patrones que reflejen las soluciones ptimas para cada uno de esos problemas. No es un
concepto trivial de entender, requiere un proceso de estudio previo y asimilacin, pero
una vez que se supera dicho ciclo, los diseos creados en base a patrones presentan un
mayor grado de flexibilidad, modularidad y reutilizacin

abstract

Introduccin
Los casos de usos se han llegado a convertirse en la base de muchas metodologas de
desarrollo orientadas a objetos. Estos generalmente proporcionan el fundamento y el
punto de partida para el resto de los procesos de anlisis y desarrollo. Un caso de uso es
una secuencia de transacciones en un sistema cuya tarea es producir un valor medible de
un actor individual del sistema. Uno de los aspectos ms importantes de los casos de uso
especfico la funcionalidad completa de un sistema.
Por otra parte el uso de patrones para el desarrollo de software establece la diferencia
entre un buen y un mal diseo orientado a objetos. Un patrn es un fragmento
nombrado de informacin instructiva, que captura la estructura esencial y la visin
interna de una familia de soluciones con probado xito sobre un problema recurrente
que surge dentro de un cierto contexto y fuerzas de sistema. En otras palabras, rehusar
soluciones que funcionaron bien una vez.

1. Qu es un patrn?
En programacin orientada a objetos se entiende por patrn una solucin probada
que se puede aplicar con xito a un determinado tipo de problemas que aparecen
repetidamente en el desarrollo de sistemas software.
Los patrones no son una librera. Van ms bien en la lnea de un esqueleto bsico que
cada desarrollador luego adapta a sus necesidades y a las peculiares caractersticas de
su aplicacin. Se describen fundamentalmente en forma textual, acompaada de
diagramas y de seudo-cdigo. (patronesdediseno.net16, 2015)
1.1. Definiciones:
Segn (Christopher Alexander, The Timeless Way, & Buildig, 1979) los
patrones de diseo software son el esqueleto de las soluciones a problemas
comunes en el desarrollo de software. En otras palabras, brindan una solucin
ya probada y documentada a problemas de desarrollo de software que estn
sujetos a contextos similares.
Podramos clasificar los patrones en tres grandes grupos segn la escala o nivel
de abstraccin:
Patrones de arquitectura: Aqullos que expresan un esquema organizativo
estructural fundamental para sistemas de software.
Patrones de dialectos: Patrones de bajo nivel especficos para un lenguaje de
programacin o entorno concreto.
Patrones de interaccin: Son patrones que nos permiten el diseo de interfaces
web.
Patrones de diseo: Aqullos que expresan esquemas para definir estructuras de
diseo (o sus relaciones) con las que construir sistemas de software.
Segn (Gamma, 2008)un Patrn de Diseo es "una solucin simple y elegante
a un problema especfico y comn del Diseo Orientado a Objetos (DOO)".
As mismo, se apostilla que "son soluciones basadas en la experiencia y cuya
fiabilidad est demostrada".

Un buen patrn debe:

Solucionar un problema: Un patrn captura soluciones, no solo

principios abstractos o estrategias

Es un concepto probado
La solucin no es obvia
Describe una relacin: No solo describen mdulos, describen

estructuras y mecanismos
Tiene un componente humano significante: es esttico y de utilidad

1. Desarrollo histrico
El trmino patrn se utiliza inicialmente en el campo de la arquitectura, por
Christopher Alexander, a finales de los 70s. Este conocimiento es trasportado al
mbito del desarrollo de software orientado por objetos y se aplica al diseo. De all
es extrapolado al desarrollo en general y a las dems etapas. Algunos libros que
marcan el desarrollo del rea son:
Alexander, Christopher. A Pattern

Language:

Towns,

Buildings,

Construction. 1977.
Alexander, Christopher. The Timeless Way of Building. 1979
Gamma et al. Design Patterns: Elementos of Reusable Object-Oriented
Software. 1994
Bushmann et al. Pattern-Oriented Software Architecture: A System of
Patterns. 1996
Coplien y Schmidth. Pattern Languages of Program Design. 1995
Algunos eventos importantes en la historia del tema de patrones en Ingeniera de
software son:
1987. Ward Cunningham y Kent Beck escriben sus experiencias de
ensear Smalltalk por medio de las ideas de Alexander en Using Pattern
Languages for Object-Oriented Programs.

 1990. El GoF empiezan la recopilacin de patrones de diseo

1991. Jim Coplien publica su recopilacin de idioms de C++ en Advanced
C++ Programming Styles and Idioms.
1994. El GoF publica el libro Design Patterns: Elementos of Reusable
Object-Oriented Software.
2. Tipos de patrones
1. Patrones de Creacin: patrones de diseo software que solucionan
problemas de creacin de instancias. Nos ayudan a encapsular y abstraer
dicha creacin.
2. Patrones Estructurales: patrones de diseo software que solucionan
problemas de composicin (agregacin) de clases y objetos.
3. Patrones De Comportamiento: patrones de diseo software que ofrecen
soluciones respecto a la interaccin y responsabilidades entre clases y
objetos, as como los algoritmos que encapsulan.
Adems de su aplicacin directa en la construccin de software en general, y
derivado precisamente del gran xito que han tenido, los patrones de diseo
software han sido aplicados a mltiples mbitos concretos producindose
"lenguajes de patrones" y extensos "catlogos" de la mano de diversos autores.
En particular son notorios los esfuerzos en los siguientes mbitos:
4. Patrones de interfaces de usuario: esto es, aquellos que intentan definir las
mejores formas de construir interfaces hombre-mquina.
5. Patrones para la construccin de sistemas empresariales: en donde se
requieren especiales esfuerzos en infraestructuras de software y un nivel de
abstraccin importante para maximizar factores como la escalabilidad o el
mantenimiento del sistema.
6. Patrones para la integracin

de

sistemas:

es

decir, para

la

intercomunicacin y coordinacin de sistemas heterogneos.

7. Patrones de flujos de trabajo: esto es para la definicin, construccin e
integracin de sistemas abstractos de gestin de flujos de trabajo y procesos
con sistemas empresariales.

3. Patrones de Diseo Software de Creacin

Los patrones de diseo software de creacin proporcionan ayuda a la hora de crear
objetos desde el punto de vista de proporcionar un apoyo en la toma de decisiones,
incluso cuando esta toma de decisiones sea de forma dinmica.
Gracias a ello, ayudan a estructurar y encapsular estas decisiones. Hay ocasiones en
la que nos encontraremos con que slo existe un patrn adecuado; otras en las que
varios podrn ayudarnos; y otras en que se pueden combinar mltiples patrones
convenientemente.
A continuacin, definiremos algunos de los patrones de diseo software de creacin
ms habitual.
4.1.

Abstract Factory
Nos encontramos frente a un problema en el que debemos crear diferentes
objetos, todos pertenecientes a la misma familia, como puede ser el sistema de
libreras necesarias para crear interfaces grficas. Visto esto podramos decir
que lo que intenta solucionar el patrn de diseo software de creacin Abstract
Factory es crear diferentes familias de objetos
Segn esto, podemos decir que los componentes tpicos del patrn Abstract
Factory es la siguiente:
Cliente: Entidad que llamar a la fbrica adecuada que necesite para crear uno
de los objetos que provee dicha factora, es decir, intentar obtener una
instancia de alguno de los productos que entren en juego (ProductoA,
ProductoB).
AbstractFactory: Definicin de la interfaz que usarn las diferentes factoras.
Como mnimo, debe ofrecer un mtodo para la obtencin de cada objeto que se
pueda crear. ("crearProductoA()" y "crearProductoB()")
Concrete Factories: Aqu se representarn las diferentes familias de productos.
Provee la instancia concreta del objeto que se encarga de crear.
Abstract Product: Definir las interfaces para la familia de productos genricos.
En el diagrama son "ProductoA" y "ProductoB". El cliente trabajar
directamente sobre esta interfaz, que ser implementada por los diferentes
productos concretos.
Concrete Product: Se encargar de la implementacin especfica de los
diferentes productos.

Este sera el diagrama de clases general del patrn de creacin Abstract

Factory:
Esquema Abstract Factory
Esquema del patrn Abstract Factory
En este enlace podr consultar un cdigo de ejemplo en Java del patrn de
creacin Abstract Factory.

Imagen 1

4.2.

Factory Method
Este patrn de diseo software de creacin consiste en utilizar una clase
constructora abstracta (similar al concepto del patrn Abstract Factory) con
unos mtodos definidos y otro(s) abstracto(s): el(los) dedicado(s) a la
construccin de objetos de un subtipo determinado.
El patrn de diseo software de creacin Factory Method puede ser usado
cuando:
La creacin de un objeto impide su reutilizacin sin una importante
duplicacin de cdigo.
La creacin de un objeto requiere acceso a la informacin o recursos que no
deberan estar contenidos en la clase de composicin.

La administracin de la duracin de los objetos generados debe ser centralizada

para garantizar un comportamiento coherente en la aplicacin.
Por tanto, los componentes del patrn de creacin Factory Method sera:
Product: define una interfaz de un objeto que metodo Factory creara.
ConcreteProduct: implementa la interfaz Product para crear un producto en
concreto.
Creator: declara el metodo factory que devolvera un objeto del tipo product.
ConcreteCreator: sobre escribe e metodo factory del creator devoler una
intancia de un producto en concreto (ConcreteProduct).
Este sera el diagrama de clases general de este patrn de creacin:
Esquema Factory Method
Esquema del patrn Factory Method
En este enlace podr consultar un cdigo de ejemplo en Java del patrn de
creacin Factory Method.

Imagen 2

4.3.

Prototype

El patrn de diseo de software de creacin Prototype, sirve para crear un

duplicado de un objeto, clonando, para ello, una instancia de ese objeto que ya
haya sido creada. Para ello, el patrn tiene que especificar el tipo de objeto que
quiere clonar, creando as un 'prototipo' de esa instancia. Este tipo o clase de
objetos deber contener en su interfaz el procedimiento que permita solicitar
esa copia, siendo desarrollado luego por las clases concretas del patrn que
deseen crear ese clon.
Desacar tambin, que el API de Java dispone de interfaz Cloneable que facilita
la implementacin de este patrn, hacindola compatible con otros prototipos
que se encuentran en las diferentes libreras de Java.

Imagen 3: Este sera el diagrama de clases general del patrn:

4.4.

Esquema Singleton

4.4.1. Esquema del patrn Prototype

Visto esto, los actores que intervienen en el patrn de creacin Prototype,

son:
Cliente: actor solicitante de la creacin (clonacin) de los nuevos objetos a
partir de los prototipos.
Prototipo Concreto: actor (clase) que presenta unas caractersticas
concretas que sern reproducidas en los nuevos objetos y que presenta la
implementacin necesaria para clonarse.

Prototipo: declara una interfaz, al a que accede el cliente, que sirve para la
clonacin de objetos.
El patrn de diseo de software de creacin Singleton (haciendo referencia
a una instancia nica) busca restringir la creacin de objetos pertenecientes
a una clase o el valor de un tipo a un nico objeto. Su intencin es
garantizar que una clase slo sea instanciada una vez y, adems,
proporcionar un nico punto de acceso global a la misma. Esto lo consigue
gracias a que es la propia clase la responsable de crear esa nica instancia,
(declarando el constructor de la clase como privado) y a que se permite el
acceso global a dicha instancia mediante un mtodo de clase.
Para implementar el patrn singleton hay que crear un mtodo que
instancie al objeto slo si todava no existe ninguna otra instancia. Para
asegurar que no vuelva a ser instanciado, se limita al constructor con
atributos protegidos o privados. Por esto, la implementacin del patrn
puede ser complicada en programas multihilo, ya que si dos o ms hilos de
ejecucin instanciaran la clase al mismo tiempo slo uno de ellos debera
lograr crear el objeto. La solucin clsica para este problema es utilizar
exclusin mutua en el mtodo de creacin de la clase que implementa el
patrn. Ejemplos de situaciones habituales en las que convendra aplicar
este ejemplo de patrn de diseo son aquellas en las que la clase principal
busca controlar el acceso a un recurso nico (como puede ser el ratn o un
archivo abierto en modo exclusivo) o cuando cierto tipo de datos debe
estar disponible para todos los dems objetos.
Este sera el diagrama de clases general del patrn de creacin Singleton:

Imagen 4

4. Patrones de Diseo Software de Comportamiento

Los patrones de diseo software de comportamiento son aquellos que estn

relacionados con algoritmos y con la asignacin de responsabilidades a los objetos.
Describen no solamente patrones de objetos o de clases, sino que tambin engloban
patrones de comunicacin entre ellos. Al igual que los otros tipos de patrones, se
pueden clasificar en funcin de que trabajen con clases (Template Method,
Interpreter) u objetos (Chain of Responsability, Command, Iterator, Mediator,
Memento, Observer, State, Strategy, Visitor).
La variacin de la encapsulacin es la base de muchos patrones de comportamiento.
Cuando un aspecto de un programa cambia frecuentemente, estos patrones trabajan
con un objeto que encapsula dicho aspecto, teniendo que definir por tanto, una clase
abstracta que describe la encapsulacin del objeto.
A continuacin, definiremos algunos de los patrones de diseo software
comportamiento ms habituales.
5.1.

Command
El patrn de diseo software de comportamiento Command permite realizar
una operacin sobre un objeto sin conocer realmente las instrucciones de esta
operacin ni el receptor real de la misma. Esto se consigue encapsulando la
peticin como si fuera un objeto, con lo que adems se facilita la
parametrizacin de los mtodos.
Las principales aplicaciones del patrn de comportamiento Command seran:

Facilitar la parametrizacin de las acciones a realizar.

Implementar estructuraas de CallBack, especificando qu rdenes
queremos que se ejecuten efrente a qu situaciones.

Independizar los enventos de "peticin" y "ejecucin".

Dar un soporte factible a la operacin "deshacer".

Desarrollar sistemas utilizando rdenes de alto nivel que se construyen

con primitivas.

Los principales agentes de este patrn son:

Command: Declara la interface para la ejecucion de la operacion.
ConcreteCommand: Define la relacin entre el objeto Receiver y una accin,
adems de implemetar el mtodo bsico Execute() al invocar las operaciones
correspondientes en Receiver.
Client: Crea un objeto ConcreteCommand y lo relaciona con su Receiver.
Invoker: Enva las solicitudes al objeto Command.
Receiver: Es la clase que gestiona la ejecucin de las operaciones asociadas a la
solicitud. Cualquier clase puede ser receptora.
Este sera el diagrama de clases general del patrn de comportamiento
Command:

Imagen 5: Esquema del patrn Command

5.2.

Iterator
El patrn de diseo de comportamiento Iterator es uno de los mayores
exponentes de los patrones de comportamient. Presenta la interfaz que declara
los mtodos necesarios para acceder, de forma secuencial, a los objetos de una
coleccin.
El iterator cubre la necesidad de acceder a los elementos de un contenedor de

objetos sin tener que trabajar con su estructura interna. Adems, es posible que
se necesite ms de una forma de recorrer la estructura siendo para ello
necesario crear modificaciones en la clase. Mediante el uso del patrn, se
aaden mtodos que permiten recorrerla sin referenciar su representacin, por
lo que la responsabilidad del recorrido se traslada a un objeto iterador.
La gran desventaja de que usar este objeto iterador, ms o menos encapsulado,
es que muchas veces e necista conocer la estructura del contenedor para elegir
del tipo de iterador ms adecuado. Esto se soluciona abstrayendo los tipos de
los distintos iteradores y dotando a las estructuras de un mtodo que cree un
iterador concreto.
Las entidades participantes en el esquema general de este patrn de diseo
software de comportamiento son:

Iterator: Interfaz que se usar para recorrer el contenedor y acceder a los

objetos o elementos que albergue, de tal modo que no sea necesario
conocer los detalles de la estructura, siendo capaces de manejarla de todos
modos.

ConcreteIterator: Clase que implementa la interfaz propuesta por el

Iterator. Mantendr la posicin actual en el recorrido de la estructura
almacenndola en el aggregate, sabiendo as cual ser el siguiente objeto
en el recorrido.

Aggregate: Es la interfaz que se usar para la fabricacin de iteradores.

ConcreteAggregate: Implementa la estructura de datos y el mtodo de

fabricacin de iteradores que crea un iterador especfico para su estructura.

Por lo tanto, es fundamental que se implemente el control de la iteracin y

definir el recorrido, bien sea como un iterador externo o como uno interno que
presente una actuacin concreta sobre la estructura aplicndola, de forma
transparente, a todos los elementos.
Este sera el diagrama de clases general de este patrn de comportamiento:

Imagen 6: Esquema del patrn Iterator

5.3.

Observer
El patrn de comportamiento Observer define una interaccin entre objetos, de
manera que cuando uno de ellos cambia su estado, el Observer se encarga de
notificar

este

cambio

los

dems.

Por tanto, la razn de ser de este patrn es desacoplar las clases de los objetos,
aumentando la modularidad del lenguaje y evitando bucles de actualizacin.
La idea bsica del patrn es que el objeto de datos (o sujeto) contenga atributos
mediante los cuales cualquier objeto observador (o vista) se pueda suscribir a l
pasndole una referencia a s mismo. De este modo, el sujeto mantiene as una
lista de las referencias a sus observadores.
Dadas estas propiedades, el patrn Observer suele emplearse en el desarrollo
de frameworks de interfaces grficas orientados a objetos, enlazando 'listeners'
a los objetos que pueden disparar eventos.
Las clasese participantes en el esquema general de este patrn de
comportamiento son:

Subject: Es el que conoce a sus observadores, proporcionando una Interfaz

para que se suscriban los objetos de tipo Observer.

Observer: Define la interfaz para actualizar los objetos a los que se deben
notificar los cambios en el objeto Subject.

ConcreteSubject: Guarda

el

estado

de

inters

para

los

objetos

ConcreteObserver y envia una notificacin a sus observadores cuando

cambia su estado.

ConcreteObserver: Mantiene una referencia a un objeto ConcreteSubject,

guardando el estado que debera permanecer sincronizado con el objeto
observado, adems de implementar la interfaz Observer para mantener su
estado consistente con el objeto observado.

Este sera el diagrama de clases general del patrn de comportamiento

Observer:

Imagen 7: Esquema del patrn Observer

5.4. Strategy
Este es un patrn de diseo software de comportamiento que determina la
forma de implementar el intercambio de mensajes entre diferentes objetos que
realizan diferentes tareas, pero que comparten elementos comunes. El patrn de
comportamiento Strategy permite gestionar un conjunto de operaciones de
entre los cuales el cliente puede elegir el que le convenda ms en cada
situacin, e intercambiarlo, de forma dinmica, cuando lo necesite.
Para llevar a cabo esta funcionalidad, este patrn de comportamiento trabaja
con los algoritmos que implementan las diferentes estrategias de forma que los
encapsula en una jerarqua, consiguiendo que el cliente trabaje contra un objeto
intermediario o 'Context'. En este punto, el cliente puede elegir el algoritmo
que prefiera de entre los implementados en las estrategias del sistema, o dejar
al contexto la tarea de elejir al ms apropiado para cada situacin concreta.
Por lo tanto, cualquier sistema que presente un servicio o funcin determinada,
que pueda o deba ser realizada de varias maneras dependiendo del contexto,
ser indicado gestionarlo con el patrn Strategy.
Las clasese participantes en el esquema general de este patrn de
comportamiento son:

Context: Actor que necesita de las operaciones concretas de las diferentes

estrategias, referenciando a estas ltimas. Puede definir una interfaz
intermedia que facilite el acceso a sus datos propios por parte de la
estrategia necesaria, en caso de necesitar el intercambio de informacin
entre el Context y diche estrategia.

Strategy: Es la interfaz comn para todos los algoritmos implementados

en las diferentes estrategias. Ser lo que use el Context para invocar a la
estrategia concreta que necesite.

ConcreteStrategy: Clases

donde

se

implementan

los

algoritmos

necesarios, usando para ello la interfaz Strategy.

Este sera el diagrama de clases general del patrn de comportamiento
Strategy:

Imagen 8: Esquema del patrn Strategy

5. Patrones de Diseo Software Estructurales

Los patrones de diseo estructurales estn enfocados en la gestin de la forma en la

que las clases y los objetos se combinan para dar lugar a estructuras ms complejas.
Al igual que en las otros tipos de patrones, podemos hablar de patrones
estructurales asociados a clases (Adapter) y asociados a objetos (Bridge,
Composite, Decorator, Facade, Flyweight, Proxy). Los primeros utilizan la herencia
mientras que los segundos se basan en la composicin. Los patrones estructurales
asociados a objetos describen formas de componer los objetos para conseguir
nuevas funcionalidades. La flexibilidad de la composicin de estos objetos surge de
la posibilidad de cambiar dicha composicin en tiempo de ejecucin, lo que es
imposible con la composicin esttica tradicional de clases.
6.1.

Adapter
El patrn Adapter convierte la interfaz de una clase en la que otra necesita,
permitiendo que clases con interfaces incompatibles trabajen juntas.
Por lo tanto, el uso de este patrn estructural est indicado cuando se quiere
usar una clase ya implementada y su interfaz no es similar con la necesitada o

cuando se desea crear una clase reusable que coopere con clases no
relacionadas o que tengan interfaces compatibles.
Sin embargo, hay que hacer distincin entre si queremos adaptar un objeto o
una

clase

interfaz

completa.

Un adaptador de clase adapta la clase Adaptee a la interfaz de la clase Target,

trabajando con una clase adaptada concreta. Por ello, una clase adaptadora no
funcionar cuando se desee adaptar, adems de la clase objetivo, todas sus
subclases.
Sin embargo, un adaptador de objetos permite que un nico Adapter trabaje
con muchos Adaptees. De este modo, el Adapter tambin puede agregar
funcionalidad a todos los Adaptees de una sola vez.
Los participantes de este patrn seran los siguientes:

Client: Es el principal agente en la formacin de objetos para la interfaz

Target.

Target: Interfaz del dominio especfico que usa el Client.

Adaptee: Es la interfaz ya existente que necesita adaptarse.

Adapter: Es quien adapta la interfaz del Adaptee a la interfaz Target.

Este sera el diagrama de clases general del patrn:

Imagen 9: Esquema del patrn Adapter

6.2.

Composite
El patrn Composite sirve para construir objetos que estn formados por tros
objetos ms simples, pero siempre similares entre s, gracias a la composicin
recursiva. Por lo tanto, al tner todos estos objetos una misma interfaz, el
Composite simplifica el tratamiento de los mismos.
El patrn composite es ampliamente usado en el tratamiento de interfaces de
usuario en las que se necesita, por ejemplo, representar un conjunto de
elementos de una interfaz grfica. Algunos de estos elementos sern simples,
mientras que otros sern ms complejos y estarn formados por varios
elementos simples. Por tanto, el comportamiento y/o la informacin que
proporciona un elemento complejo est determinada por los elementos que lo
componen.
Generalizando, nos encontraramos frente a una situacin en la que
neceistaramos representar jerarquas de objetos de tipo parte y compuestos en
la que se quiere usar la misma interfaz en las partes y en los compuestos. El
patrn Composite, lo que nos ofrece es crear una interfaz o clase abstracta que
acte comosuperclase de las clases concretas que representan las partes y los
compuestos. Las clases que representan los compuestos pueden ser tratadas
como partes, porque soportan la interfaz.
De este modo, encontramos que los componentes del patrn seran los
siguientes:

Client: Manipula objetos atravez de la interfaz proporcionada por

Component.

Component: Declara la interfaz para los objetos de la composicion, es la

interfaz de acceso y manipulacion de los componentes hijo e implementa
algunos comportamientos por defecto.

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.

Segn esto, este sera el diagrama de clases general del patrn:

Imagen 10: Esquema del patrn Composite

6.3.

Decorator
El patrn de diseo estructural Decorator facilita la tarea de aadir
dinmicamente funcionalidades a un Objeto. De este modo, elimina de
necesidad de crear clases que fuesen heredando de la primera, incorporando no
slo la nueva funcionalidad, sino tambin otras nuevas y asociarlas a ella.
A veces se desea adicionar responsabilidades a un objeto pero no a toda la
clase. Las responsabilidades se pueden adicionar por medio de los mecanismos
de Herencia, pero este mecanismo no es flexible porque la responsabilidad es
adicionada estticamente. La solucin flexible es la de rodear el objeto con otro
objeto que es el que adiciona la nueva responsabilidad. Este nuevo objeto es el
Decorator.
Este ejemplo de patrones estructurales de diseo software es til cuando:

Queremos aadir o expander las funcionalidades de objetos de forma

dinmica y transparente.

Necesitamos que ciertas responsabilidades de un objeto puedan ser

retiradas de forma sencilla en un futuro.

- No es posible o no compensa realizar esta expansin de funcionalidades

mediante herencia.

- Existe la necesidad de expandir dinmicamente la funcionalidad de un

objeto y/o eliminar la funcionalidad extendida.
Visto esto, sealar que los participantes de este patrn seran los
siguientes:

Component: Define la interface de los objetos a los que se le puede

adicionar responsabilidades dinamicamente.

ConcreteComponent: Define el objeto al que se le puede adicionar una

responsabilidad.

Decorator: Mantiene una refeencia al objeto Component y define una

interface de acuerdo con la interface de Component.

ConcreteDecorator: Es el encargado de sumar la responsabilidad al

componente. Puede haber varipos ConcreteDecorator.
Por lo tanto, este sera el diagrama de clases general del patrn:

Imagen 11: Esquema del patrn Decorator

6.4.

Proxy
Esta patrn estructural tiene como propsito proporcionar un intermediario
para controlar el acceso a un objeto. Por ello tiene distintas aplicaciones:

Proxy Remoto: Denominado as cuando representa a un objeto remoto.

Proxy Virtual: Usado para crear objetos bajo demanda.

Proxy de Referencia "inteligente": Cuando sirve como sustituto de un

puntero que realiza operaciones adicionales cuando accede al objeto.

Proxy de Proteccin: Denominado as cuando se usa para controlar el

acceso al objeto original.

La finalidad principal del patrn de diseo estructural Proxy, sera proporciona

un representante o sustituto de otro objeto para controlar el acceso a ste. Esto
lo hace segn la motivacin deMotivacin: retrasar el coste de crear e
inicializar un objeto hasta que sea realmente necesario. Por lo tanto, es usado
cuando se necesita una referencia a un objeto ms flexible o sofisticado que un
puntero. Por ejemplo, si que queremos construir una aplicacin que usa
muchos objetos visuales, lo ideal es que dichos objetos slo se instanciaran
cuando se vayan a utilizar, de tal forma que se ahorre carga en memoria y
tiempo.
Con esto, las clases participantes en el patrn, seran las siguientes:

Proxy: Mantiene una referencia al objeto real, mientras que proporciona

una interfz idntica a la del objeto real (Real Subject) y controla el acceso
a este objeto, siendo responsable de crearlo y borrarlo.

Subject: Define una interfaz comn para el proxy y el objeto real.

RealSubject: Clase del objeto real que el proxy representa.

Segn esto, este sera el diagrama de clases general del patrn:

Imagen 12: Esquema del patrn Proxy

6. Bibliografia
Christopher Alexander, The Timeless Way, & Buildig. (1979). Reglas de los
patrones de diswo.
Gamma, E. (2008). Design Patterns: Elements of Reusable Object-Oriented
Software.
patronesdediseno.net16. (Noviembre de 2015). Obtenido de
http://patronesdediseno.net16.net/