Patrones de Diseño

Definiciones de patrón de diseño

• Conjunto de prácticas de desarrollo que dan una solución conocida a
un problema presentado recurrentemente.
• Técnicas ampliamente utilizadas para resolver problemas comunes en
el desarrollo de software .
• Propuestas de desarrollo reutilizables para solucionar de una manera
aceptable problemas conocidos y clasificados.
• Catálogo de ideas para resolver problemas que nos proporcionan un
lenguaje común para comunicarnos con otros desarrolladores.
Ventajas de utilizar patrones de diseño
• Facilita futuros cambios en el desarrollo, haciéndolo más flexible.
• Estandariza las aplicaciones.
• Promueve buenas prácticas de programación.
• Crea un lenguaje común que facilita su entendimiento.
Clasificación de patrones de diseño
• Patrones Estructurales

• Patrones de Creación

• Patrones de Comportamiento
Patrones Estructurales
• Ponen su punto de enfoque en definir formas de componer clases y
objetos para formar estructuras mayores.
• Describen cómo hacer crecer las estructuras compuestas para crear
funcionalidades que agreguen flexibilidad a la misma.
Patrones Estructurales - Clasificación
• Adapter
• Bridge
• Composite
• Decorator
• Facade
• Flyweight
• Proxy
Patrones Creacionales
• Tienen el enfoque en solucionar los problemas relacionados con la
creación de instancias.
• Nos ayudan a encapsular y abstraer dicha creación.
• Procuran independizar al sistema de cómo sus objetos son creados
y/o representados.
Patrones Creacionales - Clasificación
• Abstract Factory
• Builder
• Factory Method
• Prototype
• Singleton
Patrones de Comportamiento
• Ofrecen soluciones respecto a la interacción y responsabilidades
entre clases y objetos, y los algoritmos que encapsulan.
• Enfatizan la colaboración entre objetos.
Patrones de Comportamiento - Clasificación
• Chain of Responsability • Strategy
• Command • Template Method
• Interpreter • Visitor
• Iterator
• Mediator
• Memento
• Observer
• State
Patrones Estructurales

Adapter
CLASIFICACION : Patrón Estructural.

PROPÓSITO : Transformar una interfaz en otra, de modo que

una clase que no pueda utilizar la primera haga uso
de ella a través de la segunda.

OTRO NOMBRE : Wrapper

APLICABILIDAD: Cuando se desea utilizar una clase existente y su
interfaz no sea igual a la necesitada.

Cuando se desea crear una clase reutilizable que

coopere con clases no relacionadas, es decir, cuando
no tienen necesariamente interfaces compatibles.

Cuando se necesita utilizar varias subclases

existentes, pero como es poco práctico adaptar cada
interfaz, se crea un objeto que adapte la interfaz de
la clase padre.
Patrón Adapter – Estructura
Target: Interfaz que unifica las interfaces Adapter: Implementa el Target, hace pivot entre
incompatibles. Cliente/ Adaptee. Oculta la forma de comunicarse
con el Adaptee.
Adaptee: Representa la clase con interfaz
incompatible.
Patrón Adapter – Colaboraciones

CLIENT llama a las operaciones sobre una instancia ADAPTER. De hecho, el adaptador llama a las
operaciones de ADAPTEE que llevan a cabo el pedido
Patrón Adapter - Implementación

• Crear una nueva clase, la cual será el Adapter, y un método en ella

que extienda el componente existente e implemente la interfaz
obligatoria.

• En el Cliente, crear una nueva instancia del Adapter en base a la

interfaz Target.

• Llamar al método que extiende el componente y ya definido en el

Adapter.
Patrón Adapter
• Ver ejemplo en C#
Patrones Estructurales

Bridge
CLASIFICACION : Patrón Estructural.

PROPÓSITO : Desacoplar una abstracción de su implementación

de modo que los dos puedan ser modificados de
forma independiente.

OTRO NOMBRE : HandleBody

APLICABILIDAD:
Cuando se desea evitar un enlace permanente entre
la abstracción y su implementación.

Cuando los cambios en la implementación de una

abstracción no deben afectar a las clases que hacen
uso de ella.

Cuando se desea compartir una implementación

entre múltiples objetos.
Patrón Bridge – Estructura
Client: Utiliza los objetos proporcionados por
Abstraction.
Abstraction: Define una interfaz abstracta.
Mantiene una referencia a un objeto tipo
Implementor. Define operaciones de alto nivel
basadas en las de Implementor
RefinedAbstraction: Extiende la interfaz definida
por Abstraction.
Implementor: Define la interfaz para la
implementación de clases. Provee operaciones
primitiva.
ConcreteImplementor: Implementa la interfaz de
Implementor y define su implementación
concreta.
Patrón Bridge – Colaboraciones
Abstraction envía las solicitudes de Client a su
objeto ejecutor, desacoplando la interfaz e
implementación, así esta no se vincula
permanentemente a la interfaz y se puede
determinar en tiempo de ejecución (incluso
cambiar).
Se eliminan dependencias de compilación,
consiguiendo una arquitectura más estructurada
en niveles
Se mejora la extensibilidad donde las jerarquías
de abstracción y de implementación pueden
evolucionar independientemente.
Patrón Bridge - Implementación
• Crear una clase abstracta A
• Crear una interfaz B
• Crear una nueva clase C que herede de la clase abstracta A e
implemente la interfaz B
• En la clase C estructurar el método de la clase abstracta A y agregar
los que provienen de la implementación de la interfaz B
• Crear las clases de los diferentes tipos de C disponibles,
sobrescribiendo los métodos implementados de la interfaz B.
Patrón Bridge – Tipos de Implementaciones
• Solo un implementor:
• Existe una relación 1 a 1 entre Abstraction e Implementor.
• Se instancia directamente.
• De todas maneras el código queda más limpio y abierto a extensibilidad.
• Mas de un implementor:
• Si Abstraction conoce todas las clases, ConcreteImplementor puede instanciar
una de ellas en su constructor.
• Puede decidir cual instanciar dependiendo los parámetros del constructor.
• Tambien puede elegirse una implementación inicial por defecto y cambiarla
después acorde al uso
• O puede delegar la decisión a otro objeto.
Patrón Bridge
• Ver ejemplo en C#
Patrones Estructurales

Composite
CLASIFICACION : Patrón Estructural.

PROPÓSITO : Construir objetos complejos a partir de otros más

simples, gracias a la composición recursiva y a una
estructura en forma de árbol, y tratarlos de manera
uniforme.
APLICABILIDAD:
Cuando se desea representar jerarquías parte-todo
que superen cierto tamaño.

Cuando se desea que los clientes puedan ignorar la

diferencia entre colecciones de objetos y objetos
individuales, haciendo que ambos se traten de la
misma manera.
Patrón Composite – Estructura
Client (CompositeApp): Maneja los objetos en la Implementa las operaciones referentes a los hijos.
composición mediante la interfaz Component.
Component (DrawingElement):
Declara la interfaz para los objetos de la composición.
Implementa algunos comportamientos por defecto.
Es la interfaz de acceso y manipulación de los
componentes hijo.
Leaf (PrimitiveElement): Representa objetos hoja en la
composición. Una hoja no tiene hijos.
Define comportamiento para objetos primitivos.
Composite (CompositeElement): Define el
comportamiento de los objetos que tienen hijos.
Almacena los objetos hijos.
Patrón Composite – Colaboraciones
Client utiliza la interfaz Component
para acceder a los objetos dentro de
la composición.
Si se trabaja con un objeto simple
(Leaf), la petición se maneja
directamente.
Si se trabaja contra un objeto de la
composición (Composite), entonces,
por lo general, la petición es dirigida a
todos los hijos, en algunos casos,
realizando algunas tareas previas y
posteriores a la operación.
Patrón Composite - Implementación
A la hora de implementar una estructura Composite debemos tener en
cuenta:

• Referencias explícitas a los padres.

• Compartir componentes.
• Maximizar la interfaz Component.
• Declarar las operaciones de manejo de hijos.
• Implementaría Component una lista de componentes?.
• Orden de los hijos.
• “Caching” para mejorar el rendimiento.
• Quién borraría componentes?.
• Cuál es la mejor estructura de datos para almacenar componentes?.
Patrón Composite
• Ver ejemplo en C#
Patrones Estructurales

Decorator
CLASIFICACION : Patrón Estructural.

PROPÓSITO : Añadir dinámicamente funcionalidad a un Objeto.

Extender funcionalidades sin hacer subclases.
APLICABILIDAD:
Cuando la extensión mediante la herencia no es viable.
Cuando hay una necesidad de extender la funcionalidad de
una clase, pero no hay razones para extenderlo a través de la
herencia.
Cuando existe la necesidad de extender dinámicamente la
funcionalidad de un objeto, o quitar la funcionalidad
extendida.
Patrón Decorator – Estructura
Component : Clase abstracta o interfaz que deben
poseer los objetos que necesiten ser decorados.
ConcreteComponent: Componente real al cual se le
pueden añadir responsabilidades adicionales.
Decorator: Se trata de una clase abstracta que contiene
una referencia al componente asociado. Debe
implementar la interfaz Componente, en la que delega
la funcionalidad real.
ConcreteDecorator: Elemento real que añadirá las
funcionalidades y/o responsabilidades al componente
objetivo.
Patrón Decorator – Colaboraciones

El decorador redirige las peticiones

al componente asociado

Opcionalmente puede realizar

tareas adicionales antes y después
de redirigir la petición.
Patrón Decorator - Implementación
A la hora de implementar una estructura Decorator se realiza lo
siguiente:
• Se cra a partir de Ventana la subclase abstracta VentanaDecorator.
• De VentanaDecorator se hereda BordeDecorator y BotonAyudaDecorator.
• VentanaDecorator encapsula el comportamiento de Ventana y utiliza
composición recursiva para que sea posible añadir tantas capas de Decorators
como se desee.
• Podemos crear tantos Decorators como queramos heredando de
VentanaDecorator.
Patrón Decorator
• Ver ejemplo en C#
Patrones Estructurales

Facade
CLASIFICACION : Patrón Estructural.

PROPÓSITO : Estructurar un entorno de programación y reducir

su complejidad con la división en subsistemas,
minimizando las comunicaciones y dependencias
entre estos.
APLICABILIDAD:
Cuando se necesite proporcionar una interfaz simple para un
subsistema complejo

Cuando se necesite estructurar varios subsistemas en capas,

siendo la fachada el punto de ingreso a cada nivel.

Cuando se desee desacoplar un sistema de sus clientes y de

otros subsistemas, haciéndolo mas independiente, portable y
reutilizable.
Patrón Facade - Estructura
Facade : Conoce que clases del subsistema son
responsables de una determinada petición, y delega
esas peticiones de los clientes a los objetos apropiados
del subsistema.
Subclases (ModuleA, ModuleB, ModuleC):
Implementan la funcionalidad del subsistema. Realizan
el trabajo solicitado por la fachada. No conocen la
existencia de la fachada.
Patrón Facade – Colaboraciones
Cliente: Se comunica con el subsistema
enviando peticiones al objeto Facade, el
cual las reenvía a los objetos apropiados
del subsistema.

Los objetos del subsistema realizan el

trabajo final, y la fachada hace algo de
trabajo para pasar de su interfaz a las del
subsistema.

Los clientes que usan la fachada no

tienen que acceder directamente a los
objetos del sistema.
Patrón Facade - Implementación
A la hora de implementar una estructura Decorator debemos tener en
cuenta:

• Referencias explícitas a los padres.

• Compartir componentes.
• Maximizar la interface Component.
• Declarar las operaciones de manejo de hijos.
• Implementaría Component una lista de componentes?.
• Orden de los hijos.
• “Caching” para mejorar el rendimiento.
• Quién borraría componentes?.
• Cuál es la mejor estructura de datos para almacenar componentes?.
Patrón Facade
• Ver ejemplo en C#
Patrones Estructurales

Flyweight
CLASIFICACION : Patrón Estructural.

PROPÓSITO : Eliminar o reducir la redundancia cuando tenemos

gran cantidad de objetos que contienen información
idéntica, además de lograr un equilibrio entre
flexibilidad y rendimiento (utilización de recursos).
APLICABILIDAD:
Necesitamos representar muchos dispositivos AVL idénticos
que envían y reciben información a través de sus entradas y
salidas digitales, así que creamos una clase que tenga por
atributos las características del dispositivo.
Patrón Flyweight – Estructura

FlyweightFactory : Fábrica
que utilizaremos para crear los
objetos Flyweight u objetos
ligeros.
Flyweight: Corresponde a los
objetos que deseamos
reutilizar con el fin de que
nuestros objetos sean mas
ligeros.
Patrón Flyweight – Colaboraciones
El cliente solicita al FlyweightFactory la creación
del objeto FlyWeight.

El FlyweightFactory, antes de crear el objeto,

valida si ya existe un objeto idéntico al que se le
esta solicitando. De ser así, regresa el objeto
existente, de no existir, crea el nuevo objeto y lo
almacena en cache para ser reutilizado mas
adelante.

El objeto Flyweight se crea o es tomado del cache

y es devuelto al cliente.
Patrón Flyweight - Implementación
• Crear una clase PelotaFlyweight, que contendrá la información común (radio y
color) y otra clase PelotaConcreta, que contendrá las coordenadas concretas de
cada pelota y una referencia a un objeto de tipo PelotaFlyweight.
• Al crearse instancias de PelotaConcreta, se les deberá proveer de referencias a la
instancia de PelotaFlyweight adecuada a nuestras necesidades.
• En este caso solamente tendríamos una instancia de PelotaFlyweight, puesto que
hemos dicho que todas nuestras pelotas tienen el mismo radio y color, pero
pensando en un ejemplo en el que tuviéramos varios grupos de pelotas, y dentro
de cada uno de los cuales se compartieran el radio y el color, se puede
utilizar Flyweight conjuntamente con el patrón Factory, de tal modo que este
último, en el momento en que se le soliciten instancias de PelotaConcreta con
determinadas características (mismo radio y color que el solicitado), compruebe
si ya existe un PelotaFlyweight con ese radio y color, y devuelva esa referencia o,
en caso de que no exista, la cree y la registre. El patrón Factory se encargaría de
gestionar los PelotaFlyweightexistentes.
Patrón Flyweight
• Ver ejemplo en C#
Patrones Estructurales

Proxy
CLASIFICACION : Patrón Estructural.

PROPÓSITO : Proporcionar un subrogado o intermediario de un

objeto para controlar su acceso.
APLICABILIDAD:
Cuando se necesita una referencia a un objeto mas flexible o
sofisticada que un puntero.
Dependiendo de la función que se desea realizar con dicha
referencia podemos distinguir diferentes tipos de proxies:
proxy remoto: representante local de un objeto remoto.
proxy virtual: Crea objetos costosos bajo demanda.
proxy de protección: Controla el acceso al objeto original.
proxy de referencia inteligente: Sustituto de un puntero que
lleva a cabo operaciones adicionales cuando se accede a un
objeto.
Patrón Proxy – Estructura

Proxy : Clase que mantiene una referencia al

RealSubject y proporciona una interfaz idéntica al
Subject.
Además controla el acceso a dicho RealSubject y puede
ser el responsable de su creación y borrado.
También tiene otras responsabilidades que dependen
del tipo de proxy.
Subject: Define una interfaz común para el proxy y el
objeto real, de tal modo que se puedan usar de manera
indistinta.
RealSubject: Clase del objeto real que el proxy
representa.
Patrón Proxy – Colaboraciones
El proxy redirige las peticiones al objeto real que
representa.

Ejemplos:
Diagrama de clases para un ejemplo de patrón
proxy.
Diagrama de secuencia para un ejemplo en que
NO se usa el patrón proxy.
Diagrama de secuencia para un ejemplo en que
se usa el patrón proxy.
Patrón Proxy - Implementación
A la hora de implementar una estructura Decorator debemos tener en
cuenta:

• Referencias explícitas a los padres.

• Compartir componentes.
• Maximizar la interfaz Component.
• Declarar las operaciones de manejo de hijos.
• Implementaría Component una lista de componentes?.
• Orden de los hijos.
• “Caching” para mejorar el rendimiento.
• Quién borraría componentes?.
• Cuál es la mejor estructura de datos para almacenar componentes?.
Patrón Proxy
• Ver ejemplo en C#
Patrones de Diseño

Preguntas
Muchas gracias