Audios

FACULTAD DE INGENIERÍA
ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS
Integrantes:
 Aguilar Rodríguez, Wilmer
 Flores Quezada, Oliver
 Paredes Ventura, Deivy
 Saldaña de la Cruz, Jorge
 Vaca Pastor, Arnold
 Vargas Zavaleta, Erick
Curso:
Simulación de Sistemas
Docente:
Ing. Camilo Suarez
Titulo:
Trabajo de Investigación – Patrones de Diseño
Ciclo:
VIII
UNIVERSIDAD NACIONAL DE TRUJILLO
PATRONES DE DISEÑO
INDICE
Contenido
1. Patrones tipo creacionales .................................................................................................. 3
1.1. Patrón Singleton .......................................................................................................... 3
1.2. Patrón Factory ............................................................................................................. 3
1.2.1. Patrón Simple Factory ......................................................................................... 4
1.2.2. Patrón Factory Method ....................................................................................... 5
1.2.3. Patrón Abstract Factory ...................................................................................... 5
1.3. Patrón Builder .............................................................................................................. 5
1.4. Patrón Prototype ......................................................................................................... 6
1.5. Patrón Object Pool ....................................................................................................... 7
2. Patrones tipo comportacionales......................................................................................... 8
2.1 Patrón Chain of Responsability .................................................................................. 8
2.2 Patrón Command ....................................................................................................... 10
2.3 Patrón Iterator ........................................................................................................... 11
2.4 Patrón Iterator ...............................................................Error! Bookmark not defined.
2.5 Patrón Observer......................................................................................................... 13
2.6 Patrón Mediator ......................................................................................................... 14
2.7 Patrón Memento ........................................................................................................ 15
2.8 Patrón State ................................................................................................................ 16
2.9 Patrón Strategy .......................................................................................................... 16
2.10 Patrón Template Method .......................................................................................... 17
2.11 Patrón Null Object ..................................................................................................... 17
2.12 Patrón Visitor ............................................................................................................. 17
3. Patrones tipo estructurales............................................................................................... 18
3.1 Patrón Adapter........................................................................................................... 18
3.2 Patrón Proxy .............................................................................................................. 18
3.3 Patrón Decorator ....................................................................................................... 19
3.4 Patrón Bridge ............................................................................................................. 20
3.5 Patrón Composite ...................................................................................................... 21
3.6 Patrón Facade ............................................................................................................ 22
3.7 Patrón Flyweight ....................................................................................................... 23
UNIVERSIDAD NACIONAL DE TRUJILLO 2

PATRONES DE DISEÑO
PATRONES DE DISEÑO
1. Patrones tipo creacionales
1.1.Patrón Singleton
A) Definición
Es un patrón de diseño que permite restringir la creación de objetos pertenecientes a una
clase o el valor de un tipo a un único objeto.
Su intención consiste en garantizar que una clase solo tenga una instancia y proporcionar
un punto de acceso global a ella.
El patrón singleton se implementa creando en nuestra clase un método que crea una
instancia del objeto solo si todavía no existe alguna. Para asegurar que la clase no puede ser
instanciada nuevamente se regula el alcance del constructor (con modificadores de acceso
como protegido o privado).
La instrumentación del patrón puede ser delicada en programas con múltiples hilos de
ejecución. Si dos hilos de ejecución intentan crear la instancia al mismo tiempo y esta no
existe todavía, solo uno de ellos debe lograr crear el objeto. La solución clásica para este
problema es utilizar exclusión mutua en el método de creación de la clase que implementa
el patrón.
El patrón singleton provee una única instancia global gracias a que:
 La propia clase es responsable de crear la única instancia.

 Permite el acceso global a dicha instancia mediante un método de clase.
 Declara el constructor de clase como privado para que no sea instanciable
directamente.
 Al estar internamente autoreferenciada, en lenguajes como Java, el recolector de
basura no actúa.
B) Esquema UML
C) Situaciones de uso
Las situaciones más habituales de aplicación de este patrón son aquellas en las que dicha
clase controla el acceso a un recurso físico único (como puede ser el ratón o un archivo
abierto en modo exclusivo) o cuando cierto tipo de datos debe estar disponible para todos
los demás objetos de la aplicación.
1.2.Patrón Factory

PATRONES DE DISEÑO
A) Definición
En diseño de software, el patrón de diseño Factory Method consiste en utilizar una clase
constructora (al estilo del Abstract Factory) abstracta con unos cuantos métodos definidos
y otro(s) abstracto(s): el dedicado a la construcción de objetos de un subtipo de un tipo
determinado. Es una simplificación del Abstract Factory, en la que la clase abstracta tiene
métodos concretos que usan algunos de los abstractos; según usemos una u otra hija de esta
clase abstracta, tendremos uno u otro comportamiento.
B) Esquema UML
Supongamos que tiene dos tipos diferentes de televisores: uno con pantalla LED y otro con
pantalla LCD. Si alguno de estos comienza a funcionar mal, llamará a un técnico de TV para
solicitar una visita a su residencia. El reparador debe preguntar primero qué tipo de
televisor no funciona. Según su aporte, llevará la información requerida instrumentos con
él.
1.2.1. Patrón Simple Factory

Con Simple Factory, intentamos abstraer los detalles de creación del producto de nuestra
persona que llama. Lo único que sabe nuestra persona que llama, al llamar a un método
estático y pasarle el parámetro deseado, es que devuelve un objeto del tipo de TV. Pero cómo
se crea la televisión, el código del cliente no lo sabe. En realidad, no les importa cómo creas
ese producto. Solo me importa ver los televisores LED de Sony, no cómo Sony los fabrica.
Entonces, cada vez que vea, hay posibilidades de crear muchas implementaciones de un
producto, vaya a la fábrica Simple. Pero por favor no tome esto como una bala de plata.
Intente comprender la justificación comercial y luego aplique el patrón; puede ser

PATRONES DE DISEÑO
provocativo usar Simple factory para requisitos empresariales, pero puede suceder que vea
el problema en un ámbito pequeño, pero en un ámbito más amplio su decisión perjudica el
diseño, lea el a continuación para ver cómo un simple cambio en los requisitos comerciales
puede dañar el diseño.
1.2.2. Patrón Factory Method

Con el Factory Method, no solo abstraemos la creación de productos, sino que damos un
paso más allá. Aquí, también abstraemos la fábrica que produce la TV. Entonces, los
beneficios son que podemos controlar la creación y gestión del producto (es decir, TV). Si
examina el código anterior, puede ver que abstraemos el televisor con la interfaz ITV, y en
la fábrica de Resumen, creamos un método de plantilla que controla el ciclo de vida de la TV,
crea cálculos de TV y costos de envío, y los hacemos abstractos para que sean hijos de la
fábrica abstracta puede cambiarlos en consecuencia.
Podemos decir que el método Factory abstrae al creador de la persona que llama. Es un nivel
más abstracto que Simple factory.
1.2.3. Patrón Abstract Factory

El patrón Abstract Factory nos permite crear, mediante una interfaz, conjuntos o familias
de objetos (denominados productos) que dependen mutuamente y todo esto sin especificar
cuál es el objeto concreto.
1.3.Patrón Builder
A) Definición
Como Patrón de diseño, el patrón builder (Constructor) es usado para permitir la creación
de una variedad de objetos complejos desde un objeto fuente (Producto), el objeto fuente
se compone de una variedad de partes que contribuyen individualmente a la creación de
cada objeto complejo a través de un conjunto de llamadas a interfaces comunes de la clase
Abstract Builder.
El patrón builder es creacional.
A menudo, el patrón builder construye el patrón Composite, un patrón estructural.
Intención: Abstrae el proceso de creación de un objeto complejo, centralizando dicho
proceso en un único punto, de tal forma que el mismo proceso de construcción pueda crear
representaciones diferentes.
B) Esquema UML

PATRONES DE DISEÑO
Para crear una computadora, se ensamblan diferentes partes dependiendo del pedido
recibido por el cliente
(por ejemplo, un cliente puede exigir un disco duro de 500 GB con un procesador Intel; otro
cliente puede elegir un 250
GB de disco duro con un procesador AMD).
A veces necesitamos convertir un formato de texto a otro formato de texto (por ejemplo,
RTF a texto ASCII).
1.4.Patrón Prototype
A) Definición
El patrón prototipo proporciona un método alternativo para crear instancias de nuevos
objetos copiando o clonando
una instancia de una existente. La creación de una nueva instancia, en un escenario del
mundo real, normalmente se trata como un
Operación costosa. Este patrón nos ayuda a lidiar con este problema. Nuestro enfoque aquí
es reducir el gasto de
Este proceso de creación de una nueva instancia.
B) Esquema UML

PATRONES DE DISEÑO
Supongamos que tenemos una copia maestra de un documento valioso. Queremos hacer
algún cambio para obtener una sensación diferente. Podemos hacer una fotocopia de este
documento y luego tratar de editar nuestros cambios.
Supongamos que hemos hecho una solicitud. La próxima vez que queremos crear una
aplicación similar con algunos pequeños cambios, debemos comenzar con una copia de
nuestra aplicación de copia maestra y realizar los cambios. No vamos a comenzar desde
cero.
1.5.Patrón Object Pool

A) Definición
Este es un patrón muy utilizado cuando se requiere trabajar con una
gran cantidad de objetos, los cuales son computacionalmente caros de
crear, este patrón tiene una gran ventaja en escenarios donde nuestro
programa requiere dichos objetos por un tiempo muy corto y que
luego de su uso son desechados. La ventaja que brinda este patrón es
que nos permite reutilizar los objetos con el fin de evitar la tarea de

PATRONES DE DISEÑO
crearlos cada vez que nuestra aplicación los requiere, manteniendo

así un almacén de objetos creados previamente para ser utilizados.
B) Esquema UML
C) Situaciones de Uso
Mediante la implementación del patrón de diseño Object Pool
desarrollaremos una aplicación multi hilos que controlará muchos
procesos de forma simultánea. Dichos procesos estarán controlados
por un Object Pool que limitará el número de proceso que pueden ser
ejecutados a la vez, con la finalidad de no agotar los recursos del
servidor y procesar de forma simultanea el número adecuado de
proceso que no afecten el rendimiento, dejando el resto de procesos
en una cola de espera que serán procesados una vez que llegue su
turno.
2. Patrones tipo comportacionales

2.1 Patrón Chain of Responsability
A) Definición
El patrón de diseño Cadena de responsabilidad (Chain of
Responsability) es un patrón que se distingue por su versatilidad,
permitiendo resolver problemas donde no estamos muy seguros de
qué objeto deberá procesar una solicitud concreta; este patrón de
diseño resuelve problemas fácilmente donde la herencia no puede.

PATRONES DE DISEÑO
Apoyándose de una estructura en forma de cadena donde una

secuencia de objetos tratan de atender una petición.
B) Esquema UML
Se utiliza cuando:
 Las peticiones emitidas por un objeto deben ser atendidas
por distintos objetos receptores.
 No se sabe a priori cual es el objeto que me puede resolver el
problema.
 Cuando un pedido debe ser manejado por varios objetos.
 El conjunto de objetos que pueden tratar una petición debería
ser especificado dinámicamente.
La motivación detrás de este patrón es crear un sistema que pueda

servir a diversas solicitudes de manera jerárquica. En otras palabras,
si un objeto que es parte de un sistema no sabe cómo responder a
una solicitud, la pasa a lo largo del árbol de objetos. Como el nombre
lo implica, cada objeto de dicho árbol puede tomar la
responsabilidad y atender la solicitud.
Un ejemplo típico podría ser el lanzar un trabajo de impresión. El

cliente no sabe siquiera qué impresoras están instaladas en el
sistema, símplemente lanza el trabajo a la cadena de objetos que
representan a las impresoras. Cada uno de ellos lo deja pasar, hasta
que alguno, finalmente lo ejecuta. Hay un desacoplamiento evidente

PATRONES DE DISEÑO
entre el objeto que lanza el trabajo (el cliente) y el que lo realiza

(impresora).
2.2 Patrón Command

A) Definición
El patrón de diseño Command nos permite ejecutar operaciones sin
conocer los detalles de la implementación de la misma. Las
operaciones son conocidas como comandos y cada operación es
implementada como una clase independiente que realiza una acción
muy concreta, para lo cual, puede o no recibir parámetros para
realizar su tarea. Una de las ventajas que ofrece este patrón es la de
poder crear cuántos comandos requerimos y encapsularlos bajo una
interface de ejecución.
B) Esquema UML
 Se necesiten colas o registros de mensajes.
 Se deba tener la posibilidad de deshacer las operaciones
realizadas.
 Se necesite uniformidad al invocar las acciones.
 Se quiera facilitar la parametrización de las acciones a
realizar.

PATRONES DE DISEÑO
 Se quiera independizar el momento de petición del de

ejecución.
 El parámetro de una orden puede ser otra orden a ejecutar.
 Se busque desarrollar sistemas utilizando órdenes de alto
nivel que se construyen con operaciones sencillas
(primitivas).
 Se necesite sencillez al extender el sistema con nuevas
acciones.
Lo que permite el patrón Command es desacoplar al objeto que

invoca a una operación de aquél que tiene el conocimiento necesario
para realizarla. Esto nos otorga muchísima flexibilidad: podemos
hacer, por ejemplo, que una aplicación ejecute tanto un elemento de
menú como un botón para hacer una determinada acción. Además,
podemos cambiar dinámicamente los objetos Command.
2.3 Patrón Iterator

A) Definición
Este patrón de diseño permite recorrer una estructura de datos sin
que sea necesario conocer la estructura interna de la misma. Es
especialmente útil cuando trabajamos con estructuras de datos
complejas, ya que nos permite recorrer sus elementos mediante un
Iterator, el Iterator es una interface que proporciona los métodos
necesarios para recorrer los elementos de la estructura de datos, los
métodos más comunes son:
 hasNext: Método que regresa un booleano para indicar si

existen más elementos en la estructura por recorrer. True si
existen más y false si hemos llegado al final y no hay más
elementos por recorrer.
 next: Regresa el siguiente elemento de la estructura de datos.

PATRONES DE DISEÑO
B) Esquema UML
 Una clase necesita acceder al contenido de una colección sin

llegar a ser dependiente de la clase que es utilizada para
implementar la colección, es decir sin tener que exponer su
representación interna.
 Una clase necesita un modo uniforme de acceder al contenido
de varias colecciones.
 Cuando se necesita soportar múltiples recorridos de una
colección.
Este patrón debe ser utilizado cuando se requiera una forma

estándar de recorrer una colección, es decir, cuando no es necesario
que un cliente sepa la estructura interna de una clase. Un cliente no
siempre necesita saber si debe recorrer un List o un Set o un Queue
y, menos que menos, que clase concreta está recorriendo.
El ejemplo más importante de este patrón está en el Java Framework
Collection: las colecciones en el paquete java.util siguen el patrón
Iterator.
La causa de porque Java utiliza este patrón es muy simple. En la

versión 1.6 Java posee alrededor de 50 colecciones. Y cada una de
ellas es un caso de estudio: cada una funciona de manera distinta a la
otra, con algoritmos muy distintos, por ejemplo: hay trees, binary
trees, arrays, ring buffers, hashes, hash maps, array lists, sets, etc. Si
nosotros como clientes de Java tendríamos que aprender cómo se
debe recorrer una colección en Java, sería realmente muy molesto.
Pero si todas las colecciones se recorren de la misma forma estándar,

PATRONES DE DISEÑO
y además, cada colección sabe cuál es la mejor manera de recorrerla,

entonces sería un gran avance que, de hecho, lo es.
2.4 Patrón Observer
A) Definición
En este patrón, hay muchos observadores (objetos) que observan un sujeto
particular (objeto).
Los observadores están básicamente interesados y quieren que se les notifique
cuando se realice un cambio dentro de ese tema.
Entonces, se registran en ese tema. Cuando pierden interés en el tema,
simplemente anulan el registro.
del sujeto. A veces, este modelo también se conoce como el modelo de editor-
suscriptor.
B) Esquema UML
Este patrón tiene un uso muy concreto: varios objetos necesitan ser notificados
de un evento y cada uno de ellos deciden cómo reaccionar cuando este evento
se produzca.
Un caso típico es la Bolsa de Comercio, donde se trabaja con las acciones de las
empresas. Imaginemos que muchas empresas están monitoreando las acciones
una empresa X. Posiblemente si estas acciones bajan, algunas personas estén
interesadas en vender acciones, otras en comprar, otras quizás no hagan nada y
la empresa X quizás tome alguna decisión por su cuenta. Todos reaccionan

PATRONES DE DISEÑO
distinto ante el mismo evento. Esta es la idea de este patrón y son estos casos
donde debe ser utilizado.
2.5 Patrón Mediator
A) Definición
Un mediador es quien asume la responsabilidad de la comunicación entre un
grupo de objetos. los
El mediador actúa como un intermediario que puede rastrear la comunicación
entre dos objetos. Los otros objetos
en el sistema también son conscientes de este mediador y saben que si necesitan
comunicarse entre
ellos mismos, necesitan pasar por el mediador. La ventaja de utilizar dicho
mediador es que podemos
reducir las interconexiones directas entre los objetos y, por lo tanto, disminuir
el acoplamiento.
B) Esquema UML

PATRONES DE DISEÑO
Cuando un conjunto grande de objetos se comunica de una forma bien definida,
pero compleja.
Cuando se reutilizar un objeto se hace difícil porque se relaciona con muchos
objetos.
Cuando las clases son difíciles de reutilizar porque su función básica esta
entrelazada con relaciones de dependencia.
2.6 Patrón Memento
A) Definición
Este patrón de diseño permite capturar y exportar el estado interno de un objeto
para que luego se pueda restaurar, sin romper la encapsulación.
Su finalidad es almacenar el estado de un objeto (o del sistema completo) en un
momento dado, de manera que se pueda restaurar posteriormente si fuese
necesario. Para ello se mantiene almacenado el estado del objeto para un
instante de tiempo en una clase independiente de aquella a la que pertenece el

PATRONES DE DISEÑO
objeto (pero sin romper la encapsulación), de forma que ese recuerdo permita
que el objeto sea modificado y pueda volver a su estado anterior.
Hoy en día, muchos aplicativos permiten el "deshacer" y "rehacer" de manera

muy sencilla. Para ciertos aplicativos es casi una obligación tener estas
funciones y sería impensado el hecho que no las posean. Sin embargo, cuando
queremos llevar esto a código puede resultar complejo de implementar. Este
patrón intenta mostrar una solución a este problema.
B) Esquema UML
Este patrón debe ser utilizado cuando se necesite salvar el estado de un objeto
y tener disponible los distintos estados históricos que se necesiten. Por ello
mismo, este patrón es muy intuitivo para darse cuando debe ser utilizado.
Hoy en día una gran variedad de aplicaciones posee las opciones de "deshacer"
y "rehacer". Por ejemplo, las herramientas de Microsoft Office como Word,
Power Point, etc. Es imposible pensar que ciertas herramientas no tengan esta
opción, como el Photoshop. También IDEs de programación como Eclipse
utilizan una opción de historial local. Una solución para este problema es el
patrón Memento.
2.7 Patrón State

A) Definición
B) Esquema UML
2.8 Patrón Strategy

PATRONES DE DISEÑO
A) Definición
B) Esquema UML
2.9 Patrón Template Method

A) Definición
B) Esquema UML
2.10 Patrón Null Object

A) Definición
B) Esquema UML
2.11 Patrón Visitor

A) Definición
Este patrón nos ayuda a agregar nuevas funcionalidades a una estructura de
objeto existente de tal manera que la antigua la estructura no se ve afectada
por estos cambios. Entonces, podemos seguir el principio de abrir / cerrar
aquí (es decir, extensión permitida pero modificación no permitida para
entidades como clase, función, módulos, etc.).
B) Esquema UML
El patrón visitante es aplicable, por ejemplo, cuando varias clases de objetos
con interfaces diferentes y se desean realizar operaciones que dependen de
sus clases concretas. También cuando se necesitan diversas operaciones

PATRONES DE DISEÑO
sobre objetos de una jerarquía y no se desea recargar las clases con estas
operaciones.
Es de mucha utilidad cuando las clases de la jerarquía no cambian, pero se
añaden con frecuencia operaciones a la estructura.
Si la jerarquía cambia no es aplicable, ya que cada vez que agrega nuevas
clases que deben ser visitadas, hay que añadir una operación “visita”
abstracta a la clase abstracta del visitante, y debe agregar una aplicación de
dicha categoría a cada Visitante concreto que se haya escrito.
3. Patrones tipo estructurales
3.1 Patrón Adapter
A) Definición
El patrón adaptador se utiliza para transformar una interfaz en otra, de tal
modo que una clase que no pueda utilizar la primera haga uso de ella a
través de la segunda.
B) Esquema UML
Es recomendable utilizar el patrón adaptador cuando:
- Se desea usar 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, que las clases no tienen necesariamente
interfaces compatibe
3.2 Patrón Proxy

A) Definición
El patrón Proxy es un patrón estructural que tiene
como propósito proporcionar un subrogado o intermediario de un objeto
para controlar su acceso.

PATRONES DE DISEÑO
B) Esquema UML
El patrón proxy se usa cuando se necesita una referencia a un objeto más

flexible o sofisticado 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 (como la
clase ImagenProxy en el ejemplo de motivación).
- proxy de protección: controla el acceso al objeto original (ejemplo
de proxy de protección)
- proxy de referencia inteligente: sustituto de un puntero que lleva a
cabo operaciones adicionales cuando se accede a un objeto
3.3 Patrón Decorator

A) Definición
Este principio principal de este patrón dice que no podemos modificar las
funcionalidades existentes pero podemos extender ellos. En otras palabras,
este patrón está abierto para extensión pero cerrado para modificación. El
concepto central se aplica cuando queremos agregar algunas
funcionalidades específicas a algún objeto específico en lugar de toda la
clase.

PATRONES DE DISEÑO
B) Esquema UML
- Añadir responsabilidades a objetos individuales de forma dinámica y
transparente
- Responsabilidades de un objeto pueden ser retiradas
- Cuando la extensión mediante la herencia no es viable
- Hay una necesidad de extender la funcionalidad de una clase, pero no
hay razones para extenderlo a través de la herencia.
- Existe la necesidad de extender dinámicamente la funcionalidad de un
objeto y quizás quitar la funcionalidad extendida.
3.4 Patrón Bridge

A) Definición
En este patrón, la clase abstracta se separa de la clase de implementación y
proporcionamos una interfaz de puente entre ellas. Esta interfaz nos ayuda
a hacer que las funcionalidades de clase concretas sean independientes de
la clase de implementador de interfaz. Podemos alterar estructuralmente
estos diferentes tipos de clases sin afectarnos entre nosotros.

PATRONES DE DISEÑO
B) Esquema UML
- El patrón es extremadamente útil cuando nuestra clase y sus
funcionalidades asociadas pueden cambiar a intervalos frecuentes.
- Aquí eliminamos el enlace concreto entre una abstracción y la
implementación correspondiente. Como resultado, ambas jerarquías
(abstracción y sus implementaciones) pueden extenderse a través de
clases secundarias.
- Ambas jerarquías pueden crecer de forma independiente. Aquí, si
hacemos algún cambio en los métodos de abstracción, no tienen un
impacto en el método del implementador (es decir, fillWithColor ()).
3.5 Patrón Composite

A) Definición
Este patrón puede mostrar una jerarquía parcial completa entre los
objetos. Un cliente puede tratar un objeto compuesto como un solo objeto.
En la programación orientada a objetos, hacemos un objeto compuesto
cuando tenemos muchos objetos con funcionalidades comunes. Esta
relación también se denomina relación "has-a" entre objetos.

PATRONES DE DISEÑO
B) Esquema UML
- El patrón es ideal para representar la jerarquía de parte y todo entre
los objetos.
- Aquí el cliente puede tratar la composición de los objetos como un solo
objeto.
- Los clientes pueden agregar nuevos tipos de componentes fácilmente.
- Si nos vemos obligados a mantener el orden de los niños (por ejemplo,
analizar árboles como componentes), debemos tener especial cuidado
para mantener ese orden.
3.6 Patrón Facade

A) Definición
Es uno de esos patrones que admite acoplamiento flojo. Aquí enfatizamos
la abstracción y ocultamos los detalles complejos al exponer una interfaz
simple.

PATRONES DE DISEÑO
B) Esquema UML
- Utilizamos el patrón Facade para representar una interfaz simple en
lugar de un subsistema complejo.
- Aquí promovemos un acoplamiento débil entre los subsistemas, por lo
que, de esta manera, los estamos haciendo portátiles.
- Ya mencionamos que separamos los subsistemas de los clientes
mediante una interfaz simple. Con este modelo, no solo hacemos que el
sistema sea más fácil de usar, sino que también reducimos la cantidad
de objetos con los que los clientes deben lidiar.
- Realmente no hay ninguna desventaja importante asociada con este
patrón. Por otro lado, también ha demostrado su utilidad en bibliotecas
como jQuery.
3.7 Patrón Flyweight

A) Definición
Un Flyweight es un objeto a través del cual tratamos de minimizar el uso de
memoria compartiendo datos tanto como sea posible. Aquí se usan dos
términos comunes: estado intrínseco y estado extrínseco. La primera
categoría (intrínseca) se puede almacenar en el peso mosca y se puede
compartir. El otro depende del contexto del peso mosca y no se puede
compartir. Los objetos del cliente deben pasar el estado extrínseco al peso
mosca.

PATRONES DE DISEÑO
B) Esquema UML
- La minimización del almacenamiento es una de las principales
preocupaciones aquí. Si podemos tener más pesos mosca para
compartir, podemos ahorrar más memoria.
- Si podemos calcular estados extrínsecos en lugar de almacenarlos,
podemos ahorrar una cantidad significativa de memoria.
- A veces, en una estructura de árbol, para compartir nodos de hoja,
combinamos este patrón con un patrón compuesto.
- Una interfaz flyweight puede o no permitir compartir. En algunos
casos, podemos tener objetos de peso mosca no compartidos, que a su
vez pueden tener objetos de peso mosca concretos de niños.
- En términos simples: los datos intrínsecos hacen que la instancia sea
única, mientras que los datos extrínsecos se pasan como argumentos.

Audios

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Audios

Încărcat de

Drepturi de autor:

Formate disponibile

FACULTAD DE INGENIERÍA

ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS

UNIVERSIDAD NACIONAL DE TRUJILLO 2

 La propia clase es responsable de crear la única instancia.

UNIVERSIDAD NACIONAL DE TRUJILLO 3

1.2.1. Patrón Simple Factory

UNIVERSIDAD NACIONAL DE TRUJILLO 4

1.2.2. Patrón Factory Method

1.2.3. Patrón Abstract Factory

UNIVERSIDAD NACIONAL DE TRUJILLO 5

UNIVERSIDAD NACIONAL DE TRUJILLO 6

1.5.Patrón Object Pool

UNIVERSIDAD NACIONAL DE TRUJILLO 7

crearlos cada vez que nuestra aplicación los requiere, manteniendo

2. Patrones tipo comportacionales

UNIVERSIDAD NACIONAL DE TRUJILLO 8

Apoyándose de una estructura en forma de cadena donde una

La motivación detrás de este patrón es crear un sistema que pueda

Un ejemplo típico podría ser el lanzar un trabajo de impresión. El

UNIVERSIDAD NACIONAL DE TRUJILLO 9

entre el objeto que lanza el trabajo (el cliente) y el que lo realiza

2.2 Patrón Command

UNIVERSIDAD NACIONAL DE TRUJILLO 10

 Se quiera independizar el momento de petición del de

Lo que permite el patrón Command es desacoplar al objeto que

2.3 Patrón Iterator

 hasNext: Método que regresa un booleano para indicar si

UNIVERSIDAD NACIONAL DE TRUJILLO 11

 Una clase necesita acceder al contenido de una colección sin

Este patrón debe ser utilizado cuando se requiera una forma

La causa de porque Java utiliza este patrón es muy simple. En la

UNIVERSIDAD NACIONAL DE TRUJILLO 12

y además, cada colección sabe cuál es la mejor manera de recorrerla,

2.4 Patrón Observer

UNIVERSIDAD NACIONAL DE TRUJILLO 13

2.5 Patrón Mediator

UNIVERSIDAD NACIONAL DE TRUJILLO 14

2.6 Patrón Memento

UNIVERSIDAD NACIONAL DE TRUJILLO 15

Hoy en día, muchos aplicativos permiten el "deshacer" y "rehacer" de manera

2.7 Patrón State

2.8 Patrón Strategy

UNIVERSIDAD NACIONAL DE TRUJILLO 16

2.9 Patrón Template Method

2.10 Patrón Null Object

2.11 Patrón Visitor

UNIVERSIDAD NACIONAL DE TRUJILLO 17

3.2 Patrón Proxy

UNIVERSIDAD NACIONAL DE TRUJILLO 18

El patrón proxy se usa cuando se necesita una referencia a un objeto más

3.3 Patrón Decorator

UNIVERSIDAD NACIONAL DE TRUJILLO 19

3.4 Patrón Bridge

UNIVERSIDAD NACIONAL DE TRUJILLO 20

3.5 Patrón Composite

UNIVERSIDAD NACIONAL DE TRUJILLO 21

3.6 Patrón Facade

UNIVERSIDAD NACIONAL DE TRUJILLO 22

3.7 Patrón Flyweight

UNIVERSIDAD NACIONAL DE TRUJILLO 23

UNIVERSIDAD NACIONAL DE TRUJILLO 24

S-ar putea să vă placă și