Patrones GOF de diseño de Software

Amador Acosta, Lucy Analí, usuario@correo.com

Fernández Sangay, Jhon Freddy, usuario@correo.com
Huaccha Inciso, Leidy Thalia, usuario@correo.com
Rojas Llanos, Juan Carlos, jrojasl13@unc.edu.pe

Trabajo de investigación con el fin de:

Conocer metodologías y herramientas afines al modelado y desarrollo de software.

Docente: Malpica Rodríguez Manuel Enrique, Doctor (PhD) (c)

Universidad Nacional de Cajamarca

Facultad de Ingeniería
Ingeniería de Sistemas
Cajamarca
2019
 I. TABLA DE CONTENIDO
II. ABSTRACT ......................................................................................................................... 5

I. INTRODUCCIÓN .................................................................................................................... 6

III. CÓMO ESCOGER Y UTILIZAR UN PATRÓN DE DISEÑO PARA RESOLVER UN

PROBLEMA. ................................................................................................................................... 8

IV. CLASIFICACIÓN DE LOS PATRONES GoF (gang a Four) [Gamma] ............................ 9

V. INTRODUCCION A LOS PATRONES DE CONSTRUCCION ..................................... 10

Presentación ............................................................................................................................... 10

Problemas ligados a la creación de objetos ................................................................................ 10

Problemática ........................................................................................................................... 10

Soluciones propuestas por los patrones de construcción ........................................................ 10

A. EL PATRON ABSTRACT FACTORY ............................................................................ 11

1. Descripción ...................................................................................................................... 11

a) Ejemplo .................................................................................................................... 11

b) Estructura ................................................................................................................. 12

c) Dominios de uso ....................................................................................................... 13

B. EL PATRON BUILDER .................................................................................................... 14

1. Descripción ...................................................................................................................... 14

a) Ejemplo .................................................................................................................... 14

b) Estructura ................................................................................................................. 15

c) Dominios de uso ....................................................................................................... 16

C. EL PATRON FACTORY METHOD ................................................................................ 17

1. Descripción ...................................................................................................................... 17

a) Ejemplo .................................................................................................................... 17

b) Estructura ................................................................................................................. 18
 c) Dominios de uso ....................................................................................................... 19

D. EL PATRON PROTOTYPE .............................................................................................. 20

1. Descripción ...................................................................................................................... 20

a) Ejemplo .................................................................................................................... 20

b) Estructura ................................................................................................................. 21

c) Dominios de uso ....................................................................................................... 22

E. EL PATRON SINGLETON............................................................................................... 23

1. Descripción ...................................................................................................................... 23

a) Ejemplo .................................................................................................................... 23

b) Estructura ................................................................................................................. 23

c) Dominios de uso ....................................................................................................... 24

VII. INTRODUCCION A LOS PATRONES DE ESTRUCTURACION ................................ 25

Presentación ............................................................................................................................... 25

Problemas ligados a la creación de objetos ................................ Error! Bookmark not defined.

Problemática ........................................................................... Error! Bookmark not defined.

Soluciones propuestas por los patrones de construcción ........ Error! Bookmark not defined.

A. EL PATRON ADAPTER................................................................................................... 26

VIII. Bibliografía......................................................................................................................... 36
 LISTA DE TABLAS

Tabla A: Clasificación de los patrones GoF ..................................................................................................................... 9

LISTA DE FIGURAS
Ilustración A-1: Estructura del patrón Abstract Factory ............................................................................................... 11
Ilustración A-2: Estructura del patrón Abstract Factory ............................................................................................... 12
Ilustración B-1: El patrón Builder aplicado a la generación de documentación ........................................................... 14
Ilustración B-2: Estructura del patrón Builder .............................................................................................................. 15
Ilustración B-3: Diagrama de secuencia del patrón Builder ......................................................................................... 16
Ilustración C-1: El patrón Factory Method aplicado a los clientes y sus pedidos ......................................................... 17
Ilustración C-2: Estructura del patrón Factory Method ................................................................................................ 18
Ilustración D-1: El patrón Prototype aplicado a la creación de documentación de contenido variable ....................... 20
Ilustración D-2: Estructura del patrón Prototype ......................................................................................................... 21
Patrones GOF de diseño de Software 5

II. ABSTRACT Commented [A1]: No utilices traductores automáticos en

línea, pues no tienen la capacidad de interpretar términos
académicos y científicos. Es buena idea asesorarse de un
traductor profesional.
Patrones GOF de diseño de Software 6

I. INTRODUCCIÓN Commented [A2]: La mayoría de capítulos enumerados en

esta plantilla hacen parte de una monografía estándar, pero
Todos hemos encontrado un problema de algún tipo y pensamos en silencio: me pregunto cambiarán dependiendo del enfoque de cada trabajo de grado
o tesis, así como de la metodología dirigida por el asesor. Por
si alguien ha desarrollado una solución para esto... La respuesta es casi siempre sí. El problema lo tanto, podrás conservar, reemplazar o modificar títulos y
subtítulos.
es encontrarla; luego, estar seguro de que en verdad se ajusta al problema en cuestión.
El diseño orientado a objetos es difícil y el diseño de software orientado a objetos
reutilizable lo es aún más. Los diseñadores expertos no resuelven los problemas desde sus
principios; reutilizan soluciones que han funcionado en el pasado1. Commented [A3]: Si no vas a utilizar esta nota al pie,
elimínala. Si vas a utilizar la segunda nota al pie o
Un patrón de diseño consiste en un diagrama de objetos que forma una solución a un subsiguientes, insértalas así:

problema conocido y frecuente. Referencias > Insertar nota al pie (Word lleva la numeración
automática)
Los patrones responden a problemas de diseño de aplicaciones en el marco de la
programación orientada a objetos. Se trata de soluciones conocidas y probadas cuyo diseño
proviene de la experiencia de los programadores. No existe un aspecto teórico en los patrones, en
particular no existe una formalización (a diferencia de los algoritmos).
Los patrones de diseño están basados en las buenas prácticas de la programación orientada
a objetos.
Los patrones se introducen en 1995 con el libro del llamado "GoF", de Gang of Four
(en referencia a la "banda de los cuatro" autores), llamado "Design Patterns -
Elements of Reusable Object-Oriented Software" escrito por Erich Gamma, Richard
Helm, Ralph Johnson y John Vlissides. [1, p. 12].

1
Se encuentran patrones de clases y objetos de comunicación recurrentes en muchos sistemas OO. Estos patrones
resuelven problemas de diseño específicos y hacen el diseño flexible y reusable.
Patrones GOF de diseño de Software 7

II. DESCRIPCIÓN DE LOS PATRONES DE DISEÑO.

Patrones GOF de diseño de Software 8

III. CÓMO ESCOGER Y UTILIZAR UN PATRÓN DE DISEÑO PARA RESOLVER

UN PROBLEMA.
Patrones GOF de diseño de Software 9

IV. CLASIFICACIÓN DE LOS PATRONES GoF (gang a Four) [Gamma]

Estos patrones son diversas respuestas a problemas conocidos de la programación orientada a
objetos.
Propósito
Ámbito Construcción Estructuración Comportamiento
Clase  FACTORY  ADAPTER  INTERPRETE
METHOD  TEMPLATE
METHOD
Objeto  ABSTRACT  ADAPTER  CHAIN OF
FACTORY  BRIDGE RESPONSIBILITY
 BUILDER  COMPOSITE  COMAND
 PROTOTYPE  DECORATOR  ITERATOR
 SINGLETON  FACADE  MEDIATOR
 FLYWEIGHT  MEMENTO
 PROXY  OBSERVER
 STATE
 STRATEGY
 VISITOR
Tabla A: Clasificación de los patrones GoF
Patrones GOF de diseño de Software 10

V. INTRODUCCION A LOS PATRONES DE CONSTRUCCION

Presentación
Los patrones de construcción tienen la vocación de abstraer los mecanismos de
creación de objetos. Un sistema que utilice estos patrones se vuelve independiente de la
forma en que se crean los objetos, en particular, de los mecanismos de instanciación de las
clases concretas.
Problemas ligados a la creación de objetos
Problemática
En la mayoría de lenguajes OO, la creación de objetos se realiza gracias al
mecanismo de instanciación, que consiste en crear un nuevo objeto mediante la
llamada al operador new configurado para una clase. Tal objeto es, por consiguiente,
una instancia de esta clase.
Los lenguajes de programación más utilizados a día de hoy, como Java, C++
o C#, utilizan el mecanismo del operador new.
objeto = new Clase();
La dificultad es todavía mayor cuando hay que construir objetos compuestos
cuyos componentes pueden instanciarse mediante clases diferentes. Por ejemplo, un
conjunto de documentos puede estar formado por documentos PDF, RTF o HTML.
El cliente debe conocer todas las clases posibles de los componentes y de las
composiciones. Cada modificación en el conjunto de las clases se vuelve
complicada de gestionar.
Soluciones propuestas por los patrones de construcción
Los patrones Abstract Factory, Builder, Factory Method y Prototype
proporcionan una solución para parametrizar la creación de objetos. En el caso de
los patrones Abstract Factory, Builder y Prototype, se utiliza un objeto como
parámetro del sistema. Este objeto se encarga de realizar la instanciación de las
clases. De este modo, cualquier modificación en la jerarquía de las clases sólo
implica modificaciones en este objeto. [1, p. 19]
Patrones GOF de diseño de Software 11

A. EL PATRON ABSTRACT FACTORY

1. Descripción
El objetivo del patrón Abstract Factory es la creación de objetos agrupados
en familias sin tener que conocer las clases concretas destinadas a la creación de
estos objetos.
a) Ejemplo

Ilustración A-1: Estructura del patrón Abstract Factory

Patrones GOF de diseño de Software 12

b) Estructura
(1) Diagrama de Clases

Ilustración A-2: Estructura del patrón Abstract Factory

(2) Participantes
 FábricaAbstracta (FábricaVehículo) es una interfaz que define
las firmas de los métodos que crean los distintos productos.
 FábricaConcreta1, FábricaConcreta2
(FábricaVehículoElectricidad, FábricaVehículoGasolina) son
las clases concretas que implementan los métodos que crean los
productos para cada familia de producto. Conociendo la familia
Patrones GOF de diseño de Software 13

y el producto, son capaces de crear una instancia del producto

para esta familia.
 ProductoAbstractoA y ProductoAbstractoB (Scooter y
Automóvil) son las clases abstractas de los productos
independientemente de su familia. Las familias se introducen en
las subclases concretas.
 Cliente es la clase que utiliza la interfaz de FábricaAbstracta.
(3) Colaboraciones
La clase Cliente utiliza una instancia de una de las fábricas
concretas para crear sus productos a partir de la interfaz
FábricaAbstracta.
Normalmente sólo es necesario crear una instancia de cada
fábrica concreta, que puede compartirse por varios clientes.
c) Dominios de uso
 Un sistema que utiliza productos necesita ser independiente de la
forma en que se crean y agrupan estos productos.
 Un sistema está configurado según varias familias de productos que
pueden evolucionar.
Patrones GOF de diseño de Software 14

B. EL PATRON BUILDER
1. Descripción
El objetivo del patrón Builder es abstraer la construcción de objetos
complejos de su implementación, de modo que un cliente pueda crear objetos
complejos sin tener que preocuparse de las diferencias en su implantación.
a) Ejemplo

Ilustración B-1: El patrón Builder aplicado a la generación de documentación

Patrones GOF de diseño de Software 15

b) Estructura
(1) Diagrama de Clases

Ilustración B-2: Estructura del patrón Builder

(2) Participantes
 ConstructorAbstracto (ConstructorDocumentaciónVehículo)
es la clase que define la firma de los métodos que construyen las
distintas partes del producto, así como la firma del método que
permite obtener el producto, una vez construido.
 ConstructorConcreto
(ConstructorDocumentaciónVehículoHtml y
ConstructorDocumentaciónVehículoPdf) es la clase concreta
que implementa los métodos del constructor abstracto.
 Producto (Documentación) es la clase que define el producto.
Puede ser abstracta y poseer varias subclases concretas
(DocumentaciónHtml y DocumentaciónPdf) en caso de
implementaciones diferentes.
 Director es la clase encargada de construir el producto a partir
de la interfaz del constructor abstracto.
Patrones GOF de diseño de Software 16

(3) Colaboraciones
El cliente crea un constructor concreto y un director. El
director construye, bajo demanda del cliente, invocando al
constructor y reenvía el resultado al cliente.

Ilustración B-3: Diagrama de secuencia del patrón Builder

c) Dominios de uso
 Un cliente necesita construir objetos complejos sin conocer su
implementación.
 Un cliente necesita construir objetos complejos que tienen varias
representaciones o implementaciones.
Patrones GOF de diseño de Software 17

C. EL PATRON FACTORY METHOD

1. Descripción
El objetivo del patrón Factory Method es proveer un método abstracto de
creación de un objeto delegando en las subclases concretas su creación efectiva.
a) Ejemplo

Ilustración C-1: El patrón Factory Method aplicado a los clientes y sus pedidos
Patrones GOF de diseño de Software 18

b) Estructura
(1) Diagrama de Clases

Ilustración C-2: Estructura del patrón Factory Method

(2) Participantes
 CreadorAbstracto (Cliente) es una clase abstracta que
implementa la firma del método de fabricación y los métodos que
invocan al método de fabricación.
 CreadorConcreto (ClienteContado, ClienteCrédito) es una clase
concreta que implementa el método de fabricación. Pueden
existir varios creadores concretos.
 Producto (Pedido) es una clase abstracta que describe las
propiedades comunes de los productos.
 ProductoConcreto (PedidoContado, PedidoCrédito) es una
clase concreta que describe completamente un producto.
(3) Colaboraciones
Los métodos concretos de la clase CreadorAbstracto se basan
en la implementación del método de fabricación en las subclases.
Patrones GOF de diseño de Software 19

Esta implementación crea una instancia de la subclase

adecuada de Producto.
c) Dominios de uso
 Una clase que sólo conoce los objetos con los que tiene relaciones.
 Una clase quiere transmitir a sus subclases las elecciones de
instanciación aprovechando un mecanismo de polimorfismo.
Patrones GOF de diseño de Software 20

D. EL PATRON PROTOTYPE
1. Descripción
El objetivo de este patrón es la creación de nuevos objetos mediante
duplicación de objetos existentes llamados prototipos que disponen de la capacidad
de clonación.
a) Ejemplo

Ilustración D-1: El patrón Prototype aplicado a la creación de documentación de contenido variable

Patrones GOF de diseño de Software 21

b) Estructura
(1) Diagrama de Clases

Ilustración D-2: Estructura del patrón Prototype

(2) Participantes
 Cliente (Documentación, DocumentaciónCliente,
DocumentaciónEnBlanco) es una clase compuesta por un
conjunto de objetos llamados prototipos, instancias de la clase
abstracta Prototype. La clase Cliente necesita duplicar estos
prototipos sin tener por qué conocer ni la estructura interna del
Prototype ni su jerarquía de subclases.
 Prototype (Documento) es una clase abstracta de objetos
capaces de duplicarse a sí mismos. Incluye la firma del método
"duplica".
 PrototypeConcreto1 y PrototypeConcreto2 (OrdenDePedido,
SolicitudMatriculación, CertificadoCesión) son las subclases
Patrones GOF de diseño de Software 22

concretas de Prototype que definen completamente un prototipo

e implementan el método duplica.
(3) Colaboraciones
El cliente solicita a uno o varios prototipos que se dupliquen
a sí mismos.
c) Dominios de uso
 Un sistema de objetos debe crear instancias sin conocer la jerarquía de
clases que las describe.
 Un sistema de objetos debe crear instancias de clases dinámicamente.
 El sistema de objetos debe permanecer simple y no incluir una jerarquía
paralela de clases de fabricación.
Patrones GOF de diseño de Software 23

E. EL PATRON SINGLETON
1. Descripción
El patrón Singleton tiene como objetivo asegurar que una clase sólo posee
una instancia y proporcionar un método de clase único que devuelva esta instancia.
En ciertos casos es útil gestionar clases que posean una única instancia. En
el marco de los patrones de construcción, podemos citar el caso de una fábrica de
productos (patrón Abstract Factory) del que sólo es necesario crear una instancia.
a) Ejemplo

Ilustración E-1: El patrón Singleton aplicado a la clase DocumentaciónEnBlanco

b) Estructura
(1) Diagrama de Clases

Ilustración E-2: Estructura del patrón Singleton

(2) Participantes
El único participante es la clase Singleton, que ofrece acceso
a la instancia única mediante el método de clase Instance.
Por otro lado, la clase Singleton posee un mecanismo que
asegura que sólo puede existir una única instancia. Este mecanismo
bloquea la creación de otras instancias.
Patrones GOF de diseño de Software 24

(3) Colaboraciones
Cada cliente de la clase Singleton accede a la instancia única
mediante el método de clase Instance. No puede crear nuevas
instancias utilizando el operador habitual de instanciación (operador
new), que está bloqueado.
c) Dominios de uso
 Sólo debe existir una única instancia de una clase.
 Esta instancia sólo debe estar accesible mediante un método de clase.
El uso del patrón Singleton ofrece a su vez la posibilidad de dejar de
utilizar variables globales.
Patrones GOF de diseño de Software 25

VII. INTRODUCCION A LOS PATRONES DE ESTRUCTURACION

Presentación
El objetivo de los patrones de estructuración es facilitar la independencia de la
interfaz de un objeto o de un conjunto de objetos respecto de su implementación. En el caso
de un conjunto de objetos, se trata también de hacer que esta interfaz sea independiente de
la jerarquía de clases y de la composición de los objetos.
Proporcionando interfaces, los patrones de estructuración encapsulan la
composición de objetos, aumentan el nivel de abstracción del sistema de forma similar a
como los patrones de creación encapsulan la creación de objetos. Los patrones de
estructuración ponen de relieve las interfaces.
La encapsulación de la composición no se realiza estructurando el objeto en sí
mismo sino transfiriendo esta estructuración a un segundo objeto. Éste queda íntimamente
ligado al primero. Esta transferencia de estructuración significa que el primer objeto posee
la interfaz de cara a los clientes y administra la relación con el segundo objeto que gestiona
la composición y no tiene ninguna interfaz con los clientes externos.
Esta realización ofrece otra mejora que es la flexibilidad en la composición, la cual
puede modificarse de manera dinámica.
Composición estática y dinámica
Todos los patrones de estructuración están basados en el uso de uno o varios objetos
que determinan la estructuración. La siguiente lista describe la función que cumple este
objeto en cada patrón.
 Adapter: adapta un objeto existente.
 Bridge: implementa un objeto.
 Composite: organiza la composición jerárquica de un objeto.
 Decorator: se sustituye el objeto existente agregándole nuevas funcionalidades.
 Facade: se sustituye un conjunto de objetos existentes confiriéndoles una interfaz
unificada.
 Flyweight: está destinado a la compartición y guarda un estado independiente de
los objetos que lo referencian.
 Proxy: se sustituye el objeto existente otorgando un comportamiento adaptado a
necesidades de optimización o de protección.
Patrones GOF de diseño de Software 26

A. EL PATRON ADAPTER
1. Descripción
El objetivo del patrón Adapter es convertir la interfaz de una clase existente
en la interfaz esperada por los clientes también existentes de modo que puedan
trabajar de manera conjunta. Se trata de conferir a una clase existente una nueva
interfaz para responder a las necesidades de los clientes.
2. Ejemplo

Ilustración A-1: El patrón Adapter aplicado a un componente de documentos PDF

Patrones GOF de diseño de Software 27

a) Estructura

(1) Diagrama de Clases

Ilustración A-2: Estructura del patrón Adapter

(2) Participantes
 Interfaz (Documento) incluye la firma de los métodos del objeto.
 Cliente (ServidorWeb) interactúa con los objetos respondiendo a
la interfaz Interfaz.
 Adaptador (DocumentoPdf) implementa los métodos de la
interfaz Interfaz invocando a los métodos del objeto adaptado.
 Adaptado (ComponentePdf) incluye el objeto cuya interfaz ha
sido adaptada para corresponder a la interfaz Interfaz.
(3) Colaboraciones
El cliente invoca el método solicitud del adaptador que, en
consecuencia, interactúa con el objeto adaptado invocando el método
realiza.
Patrones GOF de diseño de Software 28

Ilustración A-3: Diagrama de secuencia del patrón Adapter

b) Dominios de uso
 Para integrar en el sistema un objeto cuya interfaz no se corresponde con
la interfaz requerida en el interior de este sistema.
 Para proveer interfaces múltiples a un objeto en su etapa de diseño.
Patrones GOF de diseño de Software 29

EL PATRON BRIDGE
Descripción
Ejemplo
Estructura
Diagrama de Clases
Participantes
Colaboraciones
Dominios de uso
Ejemplos en Java
EL PATRON COMPOSITE
Descripción
Ejemplo
Estructura
Diagrama de Clases
Participantes
Colaboraciones
Dominios de uso
Ejemplos en Java
EL PATRON DECORATOR
Descripción
Ejemplo
Estructura
Diagrama de Clases
Participantes
Colaboraciones
Dominios de uso
Ejemplos en Java
EL PATRON FACADE
Descripción
Ejemplo
Estructura
Patrones GOF de diseño de Software 30

Diagrama de Clases
Participantes
Colaboraciones
Dominios de uso
Ejemplos en Java
EL PATRON FLYWEIGHT
Descripción
Ejemplo
Estructura
Diagrama de Clases
Participantes
Colaboraciones
Dominios de uso
Ejemplos en Java
EL PATRON PROXY
Descripción
Ejemplo
Estructura
Diagrama de Clases
Participantes
Colaboraciones
Dominios de uso
Ejemplos en Java
Patrones GOF de diseño de Software 31

INTRODUCCION A LOS PATRONES DE COMPORTAMIENTO

Presentación
Problemas ligados a la creación de objetos
Problemática
Soluciones propuestas por los patrones de comportamiento
EL PATRON CHAIN OF RESPONSIBILITY
Descripción
Ejemplo
Estructura
Diagrama de Clases
Participantes
Colaboraciones
Dominios de uso
Ejemplos en Java
EL PATRON COMAND
Descripción
Ejemplo
Estructura
Diagrama de Clases
Participantes
Colaboraciones
Dominios de uso
Ejemplos en Java
EL PATRON INTERPRETE
Descripción
Ejemplo
Estructura
Diagrama de Clases
Participantes
Colaboraciones
Dominios de uso
Patrones GOF de diseño de Software 32

Ejemplos en Java
EL PATRON ITERATOR
Descripción
Ejemplo
Estructura
Diagrama de Clases
Participantes
Colaboraciones
Dominios de uso
Ejemplos en Java
EL PATRON MEDIATOR
Descripción
Ejemplo
Estructura
Diagrama de Clases
Participantes
Colaboraciones
Dominios de uso
Ejemplos en Java
EL PATRON MEMENTO
Descripción
Ejemplo
Estructura
Diagrama de Clases
Participantes
Colaboraciones
Dominios de uso
Ejemplos en Java
EL PATRON OBSERVER
Descripción
Ejemplo
Patrones GOF de diseño de Software 33

Estructura
Diagrama de Clases
Participantes
Colaboraciones
Dominios de uso
Ejemplos en Java
EL PATRON STATE
Descripción
Ejemplo
Estructura
Diagrama de Clases
Participantes
Colaboraciones
Dominios de uso
Ejemplos en Java
EL PATRON STRATEGY
Descripción
Ejemplo
Estructura
Diagrama de Clases
Participantes
Colaboraciones
Dominios de uso
Ejemplos en Java
EL PATRON TEMPLATE METHOD
Descripción
Ejemplo
Estructura
Diagrama de Clases
Participantes
Colaboraciones
Patrones GOF de diseño de Software 34

Dominios de uso
Ejemplos en Java
EL PATRON VISITOR
Descripción
Ejemplo
Estructura
Diagrama de Clases
Participantes
Colaboraciones
Dominios de uso
Ejemplos en Java
Patrones GOF de diseño de Software 35

XI. CONCLUSIONES

Son las interpretaciones finales que recopilan los datos de la investigación, describe lo que se
obtuvo, qué se logró y cuáles son los resultados. Guardan relación directa con lo que se mencionó
en el planteamiento del problema. Pueden confirmar las hipótesis.
Patrones GOF de diseño de Software 36

VIII. Bibliografía

[1] L. Debrauwer, Patrones de diseño en Java. Los 23 modelos de diseño y sus soluciones
ilustradas en UML 2 y Java, 987-2-7460-8051-5 ed., E. ENI, Ed., Barcelona: ENI, 2013.