INSTITUTO SUPERIOR TECNOLÓGICO

DEL AZUAY
ISTA

Matriz: Cuenca ecuador

Teléfonos: 07 2809 551 - 0995363076
Dirección: Octavio Chacón Moscoso 1-98 y Primera
Transversal (Parque industrial)
Asignatura: Periodo Académico: Nivel: Sección:

Tendencias Actuales de la mayo 2022 – octubre Quinto B Matutina

2022
programación

Nombre Y Apellidos Del Docente: Nombre Y Apellido Del Estudiante(S):

● Jose Murillo Mayancela

Ing. Diego Cale ● Genesis Peña Villalba
● Mayra Peñafiel Torres
● Boris Quizhpe Romero

Título Del Deber: Fecha: Carrera:

Patrones de Diseño, Patrones estructurales 14 - 06 - 2022 Desarrollo de

software
 PATRONES ESTRUCTURALES
¿Cómo debemos pensar en patrones a la hora de realizar diseños?
1. Mantener las cosas simples (KISS, Keep it simple, Stupid!). El objetivo es simplicidad, no aplicar
patrones forzadamente.
2. La experiencia y el conocimiento permiten utilizar patrones de diseño a un diseño, estudiando
siempre las consecuencias que implica.
3. La posibilidad de eliminar patrones para simplificar también es una opción.
4. Si no es necesario hoy, resistir la tentación de hacerlo ahora, es un pensamiento hipotético que puede
que nunca se llegue a utilizar.
5. En definitiva, centrar el pensamiento en el diseño, no en patrones. Hay que utilizarlos solamente
cuando hay una necesidad natural.

ADAPTER

1. PROPÓSITO
El propósito de este patrón de diseño es principalmente el permitir la colaboración o utilización de
dos objetos que contengan diseños o interfaces que no sean compatibles.

2. PROBLEMA
Mejorar una aplicación integrando una biblioteca inteligente de análisis de una tercera persona. Pero
la biblioteca de análisis solo funciona con datos en formato JSON y nuestra aplicación descarga la
información de bolsa desde varias fuentes en formato XML para presentarla al usuario con bonitos gráficos
y diagramas. provocando un problema de compatibilidad en los formatos que estamos utilizando y el que
queremos implementar..

1
 3. SOLUCIÓN
Crear un adaptador que convierte la interfaz de uno de los objetos para que el otro objeto lo
comprenda. Este adaptador envolverá uno de los objetos para esconder su complejidad de tal manera que el
objeto envuelto no es consciente de la existencia del adaptador.
Primero el adaptador obtendrá una interfaz compatible con uno de los objetos existentes para luego
utilizando esta interfaz invocar desde el objeto existente a los métodos del adaptador con seguridad.
Finalmente al recibir una llamada el adaptador pasa la solicitud al segundo objeto adaptándolo al formato y
orden que este puede aceptar.

4. ANALOGÍA DEL MUNDO REAL

Cuando viajas de Europa a Estados Unidos por primera vez, puede ser que te lleves una sorpresa
cuanto intentes cargar tu computadora portátil. Los tipos de enchufe son diferentes en cada país, por lo que
un enchufe español no sirve en Estados Unidos. El problema puede solucionarse utilizando un adaptador que
incluya el enchufe americano y el europeo.

5. APLICABILIDAD
Utiliza la clase adaptadora cuando quieras usar una clase existente, pero cuya interfaz no sea
compatible con el resto del código.
Utiliza el patrón cuando quieras reutilizar varias subclases existentes que carezcan de alguna
funcionalidad común que no pueda añadirse a la superclase.

6. CÓMO IMPLEMENTARLO
1) Asegúrate de que tienes al menos dos clases con interfaces incompatibles:
2
 a) Una útil clase servicio que no puedes cambiar (a menudo de un tercero, heredada o con
muchas dependencias existentes).
b) Una o varias clases cliente que se beneficiarían de contar con una clase de servicio.
2) Declara la interfaz con el cliente y describe el modo en que las clases cliente se comunican con la
clase de servicio.
3) Crea la clase adaptadora y haz que siga la interfaz con el cliente. Deja todos los métodos vacíos por
ahora.
4) Añade un campo a la clase adaptadora para almacenar una referencia al objeto de servicio. La
práctica común es inicializar este campo a través del constructor, pero en ocasiones es adecuado
pasarlo al adaptador cuando se invocan sus métodos.
5) Uno por uno, implementa todos los métodos de la interfaz con el cliente en la clase adaptadora. La
clase adaptadora deberá delegar la mayor parte del trabajo real al objeto de servicio, gestionando tan
solo la interfaz o la conversión de formato de los datos.
6) Las clases cliente deberán utilizar la clase adaptadora a través de la interfaz con el cliente. Esto te
permitirá cambiar o extender las clases adaptadoras sin afectar al código cliente.

7. PROS Y CONTRAS

PROS CONTRAS

Puedes separar la interfaz o el código de conversión de La complejidad general del código aumenta, ya que
datos de la lógica de negocio primaria del programa. debes introducir un grupo de nuevas interfaces y clases.

Puedes introducir nuevos tipos de adaptadores al

programa sin descomponer el código cliente existente,
siempre y cuando trabajen con los adaptadores a través
de la interfaz con el cliente.

8. RELACIONES CON OTROS PATRONES

BRIDGE STRATEGY ADAPTER DECORATOR PROXY FACADE

diseñarse por se utiliza

anticipado, lo habitualmente
que te permite con una
desarrollar aplicación
partes de una existente
aplicación de
forma
independiente
entre sí

proporciona le proporciona le proporciona

una interfaz una interfaz la misma
diferente al mejorada interfaz
objeto envuelto

la interfaz define una

existente sea nueva interfaz

3
 utilizable para objetos
existentes

Se basa en delegar trabajo a otros objetos,

solucionar problemas diferentes, comunicar a otros
desarrolladores el problema que resuelve.

9. UN EJEMPLO APLICADO
Tenemos una interfaz MediaPlayer y una clase concreta AudioPlayer implementando la interfaz
MediaPlayer . AudioPlayer puede reproducir archivos de audio en formato mp3 de forma predeterminada.
Tenemos otra interfaz AdvancedMediaPlayer y clases concretas que implementan la interfaz
AdvancedMediaPlayer . Estas clases pueden reproducir archivos en formato vlc y mp4.
Queremos que AudioPlayer también reproducir otros formatos. Para lograr esto, hemos creado una clase de
adaptador MediaAdapter que implementa la interfaz MediaPlayer y usa objetos AdvancedMediaPlayer para
reproducir el formato requerido.

BRIDGE

4
 1. PROPÓSITO
Permite dividir una clase grande, o un grupo de clases estrechamente relacionadas, en dos jerarquías
separadas (abstracción e implementación) que pueden desarrollarse independientemente la una de la otra.

2. PROBLEMA
La jerarquía crece exponencialmente conforme agreguemos nuevos elementos. Cuanto más
avancemos, peor será.

3. SOLUCIÓN
Este patrón intenta resolver este problema pasando de la herencia a la composición del objeto. Esto
quiere decir que se extrae una de las dimensiones a una jerarquía de clases separada, de modo que las clases
originales referencian un objeto de la nueva jerarquía, en lugar de tener todo su estado y sus funcionalidades
dentro de una clase.

4. ANALOGÍA DEL MUNDO REAL

5
La Abstracción (también llamada interfaz) es una capa de control de alto nivel para una entidad. Esta capa
no tiene que hacer ningún trabajo real por su cuenta, sino que debe delegar el trabajo a la capa de
implementación (también llamada plataforma). Ejemplo:

5. APLICABILIDAD
● Cuando se quiera dividir y organizar una clase monolítica que tenga muchas variantes de una sola
funcionalidad
● Cuando se necesite poder cambiar implementaciones durante el tiempo de ejecución.

6. CÓMO IMPLEMENTARLO
● Identifica las dimensiones ortogonales de tus clases. Estos conceptos independientes pueden ser:
abstracción/plataforma, dominio/infraestructura, front end/back end, o interfaz/implementación.
● Comprueba qué operaciones necesita el cliente y defínelas en la clase base de abstracción.
● Determina las operaciones disponibles en todas las plataformas. Declara aquellas que necesite la
abstracción en la interfaz general de implementación.
● Crea clases concretas de implementación para todas las plataformas de tu dominio, pero asegúrate de
que todas sigan la interfaz de implementación.
● Dentro de la clase de abstracción añade un campo de referencia para el tipo de implementación. La
abstracción delega la mayor parte del trabajo al objeto de la implementación referenciado en ese
campo.
● Si tienes muchas variantes de lógica de alto nivel, crea abstracciones refinadas para cada variante
extendiendo la clase base de abstracción.
● El código cliente debe pasar un objeto de implementación al constructor de la abstracción para
asociar el uno con el otro. Después, el cliente puede ignorar la implementación y trabajar solo con el
objeto de la abstracción.

7. PROS Y CONTRAS

PROS CONTRAS

Puedes crear clases y aplicaciones independientes Puede ser que el código se complique si aplicas el
de plataforma. patrón a una clase muy cohesionada.

El código cliente funciona con abstracciones de alto

6
 nivel. No está expuesto a los detalles de la
plataforma.

Principio de abierto/cerrado. Puedes introducir

nuevas abstracciones e implementaciones
independientes entre sí.

Principio de responsabilidad única. Puedes

centrarte en la lógica de alto nivel en la abstracción
y en detalles de la plataforma en la implementación.

8. RELACIONES CON OTROS PATRONES

BRIDGE STATE STRATEGY ADAPTER

diseñarse por anticipado, Se utiliza habitualmente

lo que te permite con una aplicación
desarrollar partes de una existente
aplicación de forma
independiente entre sí

Se basa en delegar trabajo a otros objetos, solucionar problemas diferentes, comunicar a otros desarrolladores el
problema que resuelve.

Puedes combinar Builder

con Bridge

Puedes utilizar Abstract

Factory junto a Bridge.
Este emparejamiento
resulta útil cuando algunas
abstracciones definidas
por Bridge sólo pueden
funcionar con
implementaciones
específicas

9. UN EJEMPLO APLICADO
Tenemos una interfaz DrawAPI que actúa como un puente implementador y clases concretas RedCircle ,
GreenCircle implementando la interfaz DrawAPI . Shape es una clase abstracta y utilizará el objeto de
DrawAPI . BridgePatternDemo , nuestra clase de demostración usará la clase Shape para dibujar círculos de
diferentes colores.

7
 COMPOSITE

1. PROPÓSITO
Permite componer objetos en estructuras de árbol y trabajar con esas estructuras como si fueran
individuos.

2. PROBLEMA
Solo puede usarse cuando el modelo central se puede representar como un árbol.

3. SOLUCIÓN
Directa: Desenvolver cada módulo y presar su contenido, nivel de anidación, etc. En fin, un montón
de detalles que harían que este método sea muy tedioso de realizar.

8
 Sugerido: trabajar con una interfaz directa para calcular el total, es decir que el producto devuelva
su precio y para una caja recorrer cada artículo dentro de esta, busca el precio y devuelve un total por caja,
esta caja podría contener más cajas o incluso añadir costos adicionales.
La principal ventaja de esta solución es que no se debe preocupar por la composición total de la clase
ya que solo se requiere un atributo específico que se puede obtener llamando/invocando a métodos de la
misma clase.

4. ANALOGÍA DEL MUNDO REAL

Los ejércitos están formados por varias ramas/divisiones, que a su vez se dividen en ramas o
subdivisiones, cuyas órdenes se seguirán en orden de jerarquía.

5. APLICABILIDAD
Se utiliza cuando:
● Se implementa una estructura de objetos con forma de árbol.
● Proporciona dos elementos básicos:
○ Hojas simples
○ Contenedores complejos.
El contenedor puede estar compuesto por hojas y por más contenedores. permitiendo así construir
una estructura de objetos recursivos anidados como un árbol.
● El código cliente trata elementos simples y complejos por igual.
● Todos los elementos comparten una interfaz común. Utilizando la misma interfaz.

6. CÓMO IMPLEMENTARLO
a. Asegurarse de que el modelo central puede representarse como una estructura de árbol y lo divide en
elementos simples y contenedores que sean capaces de contener más elementos o contenedores.
b. Declarar la interfaz con componente con una lista de métodos para componentes tanto simples
como complejos.

9
 c. Crear una clase hoja para representar con componente con una lista de métodos para componentes
tanto simples como complejos.
d. Crear una clase contenedora para representar elementos complejos incluyendo el campo matriz que
esta debe poder almacenar hijas y contenedores por lo que es importante declararlos con el tipo de
interfaz componente. Al implementar métodos de interfaz el contenedor debe delegar la mayor parte
del trabajo a las subelementos.
e. Definir los métodos para añadir y eliminar elementos hijos dentro del contenedor. Tomando en
cuenta que las operaciones se pueden declarar en la interfaz, el principio de segregación de interfaz
porque los métodos de clase hoja estará vacío, pero el cliente aún podrá tratar todos los elementos de
la misma manera incluso al componer la estructura.

7. PROS Y CONTRAS

PROS CONTRAS

Permite trabajar con estructuras de árbol complejas. Es complicado generar una sola interfaz común
para todas las clases al tener diferentes funciones.
Usa Polimorfismo y Recursión.
Generalización excesiva a la interfaz componente
Usa el Principio abierto/cerrado que permite provocando ser más difícil de entender.
introducir nuevos elementos en la aplicación sin
descomponer el código original.

8. RELACIONES CON OTROS PATRONES

Builder Chain of Iterador Visitor Flyweights

Responsibility

Crea árboles Se usa para conectar Recorre todo o parte Ejecuta una Implementa los
complejos para que la solicitud recibida del contenido del operación sobre todo nodos de las hojas
funcionen de forma por una hoja árbol. el árbol ya que compartidos en el
recursiva. mediante una cadena permite separar árbol para ahorrar
a todos los algoritmos de los memoria RAM
componentes del objetos que operan.
árbol.

Decorator Prototype

Tiene Diagramas de Clonar estructuras

estructura similar complejas en lugar
basados en la de reconstruirlas
composición desde cero.
recursiva
organizando uno o
varios objetos.

Solo tiene un
componente hijo al

10
 cual añade
responsabilidades
adicionales.

Permite que
Composite solo
recapitule los
resultados.

Extiende el
comportamiento de
un objeto específico
del árbol.

9. UN EJEMPLO APLICADO
Tenemos una clase Employee que actúa como una clase de actor de patrón composite.
CompositePatternDemo, nuestra clase de demostración usará la clase Employee para agregar una jerarquía a
nivel de departamento e imprimir todos los empleados.

11
 DECORATOR

1. PROPÓSITO
Envuelve un objeto y le provee de nuevo comportamiento.

2. PROBLEMA
La versión inicial de la biblioteca se basaba en la clase Notificador que solo contaba con unos
cuantos campos, un constructor y un único método send. El método podía aceptar un argumento de mensaje
de un cliente y enviar el mensaje a una lista de correos electrónicos que se pasaban a la clase notificadora a
través de su constructor, Los usuarios de la biblioteca esperan algo más que unas simples notificaciones por
correo. Otros querrían recibir las notificaciones por Facebook.

3. SOLUCIÓN
La herencia es estática. No se puede alterar la funcionalidad de un objeto existente durante el tiempo de
ejecución. Sólo se puede sustituir el objeto completo por otro creado a partir de una subclase diferente.
Las subclases sólo pueden tener una clase padre. En la mayoría de lenguajes, la herencia no permite a una
clase heredar comportamientos de varias clases al mismo tiempo.

12
 4. ANALOGÍA DEL MUNDO REAL
Cuando alquilamos una habitación, compramos muebles si así lo necesitamos, si vemos que está muy
vacío compramos cuadros para que se llene la habitación, todos los muebles “existen” pero no son parte de
la habitación, y se pueden remover cuando se desee.

5. APLICABILIDAD

DECORATOR

cuando necesites asignar funcionalidades adicionales a estructurar tu lógica de negocio en capas, crear un
objetos durante el tiempo de ejecución sin descomponer decorador para cada capa y componer objetos con varias
el código que utiliza esos objetos. combinaciones de esta lógica

Utiliza el patrón cuando resulte extraño o no sea posible Muchos lenguajes de programación cuentan con la
extender el comportamiento de un objeto utilizando la palabra clave final que puede utilizarse para evitar que
herencia. una clase siga extendiéndose

6. CÓMO IMPLEMENTARLO
a. El dominio de negocio puede representarse como un componente primario con varias capas
opcionales encima.
b. Decide qué métodos son comunes al componente primario y las capas opcionales
c. Crea una clase concreta de componente y define en ella el comportamiento base.
d. Crea una clase base decoradora. Debe tener un campo para almacenar una referencia a un objeto
envuelto
e. Asegúrate de que todas las clases implementan la interfaz de componente.
f. Crea decoradores concretos extendiéndose a partir de la base decoradora.
g. El código cliente debe ser responsable de crear decoradores y componerlos

7. PROS Y CONTRAS

PROS CONTRAS

Extender el comportamiento de un objeto sin crear una Resulta difícil eliminar un wrapper específico de la pila
nueva subclase. de wrappers.

Puedes añadir o eliminar responsabilidades de un objeto
durante el tiempo de ejecución.
Puedes combinar varios comportamientos envolviendo
un objeto con varios decoradores.
Es difícil implementar un decorador de tal forma que su
comportamiento no dependa del orden en la pila de
decoradores.
El código de configuración inicial de las capas pueden

13
 tener un aspecto desagradable.
Puedes dividir una clase monolítica que implementa
muchas variantes posibles de comportamiento, en varias
clases más pequeñas.

8. RELACIONES CON OTROS PATRONES

ADAPTER PROXY DECORATOR COMPOSITE PROTOTYPE STRATEGY

Cambia la Mejora un objeto

interfaz de un sin cambiar su
objeto interfaz
existente

Proporciona Proporciona la Le proporciona una

una interfaz misma interfaz interfaz mejorada.
diferente al
objeto
envuelto

Tienen estructuras similares, ambos se

basan en la composición recursiva para
organizar un número indefinido de
objetos.

Te permite clonar estructuras complejas en lugar de

reconstruirlas desde cero

Permite cambiar la Permite cambiar

piel de un objeto sus entrañas

Se basan en el principio de
composición, por el que un objeto
debe delegar parte del trabajo a otro.

9. UN EJEMPLO APLICADO
Vamos a crear una interfaz Shape y clases concretas implementando la interfaz Shape . Luego crearemos una
clase de decorador abstracta ShapeDecorator implementando la interfaz Shape y teniendo el objeto Shape
como su variable de instancia.
RedShapeDecorator es una clase concreta que implementa ShapeDecorator .
DecoratorPatternDemo , nuestra clase de demostración usará RedShapeDecorator para decorar objetos
Shape .

14
 FACADE

1. PROPÓSITO
Su propósito es proporcionar una interfaz simplificada a una biblioteca, a un framework o cualquier
otro grupo complejo de clases.

15
 2. PROBLEMA
lograr que un código trabaje con un amplio grupo de objetos que pertenezcan a una sofisticada
biblioteca. para ello primero debemos inicializar todos los objetos ,llevar un registro de dependencias
,ejecutar los métodos en el orden correcto,etc. lo que resulta en una lógica de negocios que se verá acoplada
a los detalles de implementación de las clases de terceros de forma estrecha, haciendo que esta sea difícil de
comprender y a la vez difícil de mantener.
3. SOLUCIÓN
Una fachada solo incluye las funciones importantes para el cliente y proporciona una función
limitada a comparación del trabajo con subsistemas por lo que solo resulta útil cuando tenemos que ingresar
bibliotecas sofisticadas con docenas de funciones de la cual solo necesitamos una parte pequeña.

4. ANALOGÍA DEL MUNDO REAL

llamar a una tienda y hacer un pedido por teléfono, el operador es la fachada de todos los servicios y
departamentos de la tienda siendo el que proporciona una interfaz sencilla al sistema de pedidos y demás
servicios de entrega.

5. APLICABILIDAD
Cuando se necesite una interfaz limitada pero directa a un subsistema de trabajo proporcionando un
atajo a las funciones más utilizadas de los subsistemas que encaja más con los requerimientos del cliente.
Cuando queramos estructurar subsistemas en capas reduciendo el acoplamiento entre subsistemas
exigiendoles que se comuniquen únicamente mediante fachadas.
6. CÓMO IMPLEMENTARLO
1) Comprueba si es posible proporcionar una interfaz más simple que la que está proporcionando un
subsistema existente. Estás bien encaminado si esta interfaz hace que el código cliente sea
independiente de muchas de las clases del subsistema.
2) Declara e implementa esta interfaz en una nueva clase fachada. La fachada deberá redireccionar las
llamadas desde el código cliente a los objetos adecuados del subsistema. La fachada deberá ser
responsable de inicializar el subsistema y gestionar su ciclo de vida, a no ser que el código cliente ya
lo haga.
3) Para aprovechar el patrón al máximo, haz que todo el código cliente se comunique con el subsistema
únicamente a través de la fachada. Ahora el código cliente está protegido de cualquier cambio en el
código del subsistema. Por ejemplo, cuando se actualice un subsistema a una nueva versión, sólo
tendrás que modificar el código de la fachada.
4) Si la fachada se vuelve demasiado grande, piensa en extraer parte de su comportamiento y colocarlo
dentro de una nueva clase fachada refinada.

16
 7. PROS Y CONTRAS

PROS CONTRAS

Se puede aislar el código de la complejidad del La fachada puede convertirse en un objeto

subsistema. todopoderoso al estar acoplado a todas las clases de
una aplicación.

8. RELACIONES CON OTROS PATRONES

Mediator Facade Proxy Adapter Flyweight

Define una nueva Intenta hacer que

interfaz para objetos la interfaz
existentes existente sea
utilizables

Abstract Factory puede

servir como alternativa a
Facade

. Muestra cómo crear un Muestra cómo

único objeto que crear muchos
represente un subsistema pequeños objetos
completo

Ambos intentan organizar la colaboración

entre muchas clases estrechamente
acopladas.

Ambos pueden almacenar temporalmente una

entidad compleja e inicializarla por su cuenta.

A menudo puede
transformarse en una
Singleton, ya que un
único objeto fachada es
suficiente en la mayoría
de los casos.

9. UN EJEMPLO APLICADO
Vamos a crear una interfaz Shape y clases concretas implementando la interfaz Shape . Una clase de fachada
ShapeMaker se define como el siguiente paso.
La clase ShapeMaker usa las clases concretas para delegar las llamadas de los usuarios a estas clases.
FacadePatternDemo , nuestra clase de demostración, utilizará la clase ShapeMaker para mostrar los
resultados.

17
 FLYWEIGHT

1. PROPÓSITO
Permite mantener más objetos dentro de la cantidad disponible de RAM compartiendo partes
comunes del estado entre varios objetos en lugar de mantener toda la información en los objetos.

2. PROBLEMA
Presenta una serie de objetos que contienen sus datos de forma idéntica y redundante sobre uno o
varios elementos comunes y las referenciadas por la serie de objetos iniciales.

3. SOLUCIONES

18
 Disminución del uso de Recursos: el uso de referencias es más óptimo que cada objeto tenga la
información repetida en su interior.
Protección ante el cambio: al meter la información redundante en un elemento común, un cambio
en dicha información que solo tenga que tocar un único punto y no distribuye el cambio en la información
de cada serie de objetos, siendo más propenso a error.
Almacenamiento del estado intrínseco: la cual sugiere cambiar a varios campos matrices para
almacenar referencias a un objeto flyweight específico que represente el objeto las cuales deben estar
sincronizadas para acceder a toda información usando el mismo índice.
Clase de Contexto separada: Almacena el estado extrínseco junto a la referencia al objeto,
exigiendo a la clase contenedora tener una matriz.
Inmutabilidad: Asegura que no se pueda modificar el estado, debe inicializarse una sola vez
mediante el constructor.
Fábrica flyweight: gestiona un grupo de objetos existentes. El método acepta el estado intrínseco
deseado por un cliente, busca un objeto existente que coincida con el estado y lo devuelve si lo encuentra, si
no existe crea un nuevo objeto y lo añade al grupo.

4. ANALOGÍA DEL MUNDO REAL

Una Aplicación que administra listas de reproducción, las cuales están conformados por canciones que son
compartidas por todas las listas. Además las canciones tienen secciones compartidas para mejorar la
cantidad de memoria usada

19
 5. APLICABILIDAD
● El programa debe soportar una enorme cantidad de objetos que apenas quepan en la RAM
disponible.
● Genera una cantidad enorme de objetos similares.
● Los objetos contienen estados duplicados que se pueden extraer y compartir entre varios objetos.

6. CÓMO IMPLEMENTARLO
a. Divide los campos de una clase que se convertirá en flyweight en dos partes:
● Estado intrínseco: contienen información invariable duplicada a través de varios
objetos.
● Estado extrínseco: contienen información contextual única de cada objeto.

b. Deja que los campos presenten el estado intrínseco asegurándose de que sean inmutables,
llevando únicamente el valor asignado en el constructor.

c. Repasa los métodos que usan los campos extrínsecos, para cada campo usado se introduce un
nuevo parámetro .

d. Opcional: crear una clase fábrica para gestionar el grupo de objetos, buscando uno existente
antes de crear uno nuevo. Los clientes solo solicitan objetos a través de la fábrica
describiendo el flyweight requerido pasando a intrinseco a la fábrica.

e. El cliente almacena o calcula valores del estado extrínseco para poder invocar métodos de
objetos. Por comodidad, el estado extrínseco puede moverse a una clase contexto separada
junto con el campo referenciador del flyweight.

7. PROS Y CONTRAS

PROS CONTRAS

Permite ahorrar mucha memoria RAM, siempre que Puede cambiar la RAM por ciclos CPU al calcular
el programa tenga grandes cantidades de objetos de nuevo parte de la información de contexto al
similares. invocar un método flyweight.

El código se complica mucho. Los nuevos

miembros del equipo siempre estarán preguntando
porque el estado de una entidad se separó de esa
forma.

8. RELACIONES CON OTROS PATRONES

20
 Composite Facade Singleton

Implementa los nodos de hoja Muestra cómo Reduce los estados

compartidos del árbol crear un único compartidos de kos
composite para ahorrar objeto que objetos a un unico
memoria. represente un objeto.
subsistema
completo.

Puede ser mutable.

Solo admite una

instancia

9. UN EJEMPLO APLICADO
Vamos a crear una interfaz Shape y una clase concreta Circle implementando la interfaz Shape . Una clase
de fábrica ShapeFactory se define como el siguiente paso.
ShapeFactory tiene un HashMap de Circle que tiene la clave como color del objeto Circle . Cada vez que
llega una solicitud para crear un círculo de un color particular a ShapeFactory , verifica el objeto del círculo
en su HashMap , si se encuentra el objeto de Circle , ese objeto se devuelve; de ​lo contrario, se crea un
nuevo objeto, se almacena en hashmap para uso futuro y se devuelve a cliente.
FlyWeightPatternDemo , nuestra clase de demostración, usará ShapeFactory para obtener un objeto Shape .
Pasará información ( rojo/verde/azul/negro/blanco ) a ShapeFactory para obtener el círculo del color
deseado que necesita.

21
 PROXY

1. PROPÓSITO
Envuelve un objeto para controlar el acceso al mismo.

2. PROBLEMA
Todos los clientes del objeto tendrán que ejecutar algún código de inicialización diferida.
Lamentablemente, esto seguramente generará una gran cantidad de código duplicado, Las consultas de la
información tardará demasiado tiempo.

22
 3. SOLUCIÓN
Crear una nueva clase proxy con la misma interfaz que un objeto de servicio original, Al recibir una
solicitud de un cliente, el proxy crea un objeto de servicio real y le delega todo el trabajo. El proxy se
camufla como objeto de la base de datos, sin que el cliente o el objeto real de la base de datos lo sepan.

4. ANALOGÍA DEL MUNDO REAL

Una tarjeta de crédito es un proxy de una cuenta bancaria, que, a su vez, es un proxy de un manojo
de billetes. Ambos implementan la misma interfaz, por lo que pueden utilizarse para realizar un pago.

5. APLICABILIDAD

PROXY

Proxy Virtual: Un servicio muy pesado, gastando Retrasar la inicialización del objeto a un momento en
recursos del sistema, aunque solo se lo necesite de vez que sea realmente necesario.
en cuando

Proxy de Protección: Únicamente clientes específicos Las credenciales cumplas con los criterios de validación
sean capaces de usar el servicio

Proxy Remoto: El objeto de servicio se ubica en un Pasa la solicitud del cliente por la red, gestionando todos
servidor remoto los detalles de trabajar con la red.

Proxy de Registro: Un historial de las solicitudes de un Registrar cada solicitud antes de pasar al servicio
servicio

Proxy de Caché: Guardar caché de las solicitudes de los Solicitudes recurrentes que siempre dan los mismos
clientes gestionar ciclo de vida resultados.

23
 6. CÓMO IMPLEMENTARLO
a. Convertir el proxy en una subclase de la clase servicio, de forma que herede la interfaz del servicio.
b. Crea la clase proxy. Debe tener un campo para almacenar una referencia al servicio.
c. Implementa los métodos del proxy según sus propósitos, el proxy debería delegar el trabajo a un
objeto de servicio.
d. Introducir un método de creación que decida si el cliente obtiene un proxy o un servicio real
e. Considera implementar la inicialización diferida para el objeto de servicio.

7. PROS Y CONTRAS

PROS CONTRAS

Puedes controlar el objeto de servicio sin que los El código puede complicarse ya que debes introducir
clientes lo sepan. gran cantidad de clases nuevas.

Puedes gestionar el ciclo de vida del objeto de servicio La respuesta del servicio puede retrasarse.
cuando a los clientes no les importa.

El proxy funciona incluso si el objeto de servicio no está

listo o no está disponible.

Principio de abierto/cerrado. Puedes introducir nuevos

proxies sin cambiar el servicio o los clientes.

8. RELACIONES CON OTROS PATRONES

ADAPTER DECORATOR PROXY FACADE

Proporciona una interfaz Le proporciona una Proporciona la misma

diferente al objeto interfaz mejorada interfaz
envuelto

Ambos pueden almacenar temporalmente una entidad

compleja e inicializarla por su cuenta.

Se basan en el principio de composición, por el que un

objeto debe delegar parte del trabajo a otro.

9. UN EJEMPLO APLICADO
Vamos a crear una interfaz de imagen y clases concretas que implementen la interfaz de imagen .
ProxyImage es una clase de proxy para reducir el consumo de memoria de la carga de objetos RealImage .

24
BIBLIOGRAFÍA:
● Refactoring Guru. (s.f). Flyweight. https://refactoring.guru/es/design-patterns/flyweight

● Refactoring Guru. (s.f). Composite. https://refactoring.guru/es/design-patterns/composite

● Blancarte, O. (s.f) Flyweight. Recreative Programming.

https://reactiveprogramming.io/blog/es/patrones-de-diseno/flyweight

● Ionos. (09 de Noviembre de 2020). El patrón Composite: ejemplos de soluciones para jerarquías

.
parte-todo https://www.ionos.es/digitalguide/paginas-web/desarrollo-web/patron-composite/

25