UNIVERSIDAD DE SONSONATE

FACULTAD DE INGENIERÍA Y CIENCIAS NATURALES

TEMA:
APLICACIÓN DE PATRONES DE DISEÑO PARA DEMOSTRAR SU APLICABILIDAD Y
FUNCIONALIDAD

TRABAJO DE GRADUACIÓN PRESENTADO POR:

FRANCISCO ALONSO TEPATA RAMÓN

PARA OPTAR AL GRADO ACADÉMICO DE:

INGENIERO EN SISTEMAS COMPUTACIONALES

MARZO DE 2020
SONSONATE, EL SALVADOR, CENTRO AMÉRICA.
 AUTORIDADES DE LA UNIVERSIDAD

LICDA. ANA MARÍA DE LOS ÁNGELES RODRÍGUEZ SALAZAR

RECTORA

DR. FRANCISCO CARLO ARÉVALO HERRERA

VICE-RECTOR

LIC. MAURICIO ALFREDO BERNAL HENRÍQUEZ

FISCAL

DRA. ARONETTE DÍAZ PINEDA

SECRETARIA GENERAL

ING. RUBÉN ALFREDO MENDOZA JUÁREZ

DECANO DE LA FACULTAD DE INGENIERÍA Y CIENCIAS NATURALES
 JURADO CALIFICADOR

ING. IVÁN ORLANDO ALVARADO NIÑO

PRESIDENTE

ING. MANUEL DE JESÚS URRUTIA RAMOS

PRIMER VOCAL

ING. DAVID CORTÉZ RIVERA

SEGUNDO VOCAL

ING. JORGE ALFONSO MENJÍVAR MIRÓN

ASESOR
 ÍNDICE GENERAL
ÍNDICE GENERAL...................................................................................................................i

INDICE DE ILUSTRACIONES..............................................................................................vii

INDICE DE TABLAS..............................................................................................................ix

RESUMEN..............................................................................................................................x

INTRODUCCIÓN...................................................................................................................xi

1. CAPÍTULO I. PLANTEAMIENTO DEL PROBLEMA.......................................................2

1.1. El problema de investigación....................................................................................2

1.2. Antecedentes del problema.......................................................................................2

1.3. Objetivos....................................................................................................................3

1.3.1. General...............................................................................................................3

1.3.2. Específicos..........................................................................................................3

1.4. Justificación...............................................................................................................3

1.5. Delimitación del proyecto..........................................................................................3

1.5.1 Delimitación temporal:........................................................................................3

1.5.2 Delimitación espacial:.........................................................................................3

1.5.3 Unidad de análisis:.............................................................................................4

CAPÍTULO II. MARCO DE INVESTIGACIÓN........................................................................6

1.1 Patrones de Diseño...................................................................................................6

1.2 Patrones de Diseño más utilizados...........................................................................6

1.3 Clasificación de los Patrones según The Gang of Four...........................................6

1.4 Catálogo de GoF está dividido en tres categorías....................................................6

1.5 Patrones Creacionales..............................................................................................7

1.5.1 Lista de Patrones Creacionales..........................................................................7

1.5.2 Lista de Patrones Estructurales..........................................................................7

i
 1.5.3 Lista de Patrones de Comportamiento...............................................................8

1.6 Factory Method..........................................................................................................8

1.6.1 Aplicabilidad........................................................................................................9

1.6.2 Estructura............................................................................................................9

1.6.3 Participantes.......................................................................................................9

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

1.7.1 Aplicabilidad......................................................................................................10

1.7.2 Estructura..........................................................................................................11

1.7.3 Participantes.....................................................................................................11

1.8 Builder.....................................................................................................................12

1.8.1 Aplicabilidad......................................................................................................12

1.8.2 Estructura..........................................................................................................12

1.8.3 Participantes.....................................................................................................13

1.9 Prototype.................................................................................................................13

1.9.1 Aplicabilidad......................................................................................................14

1.9.2 Estructura..........................................................................................................14

1.9.3 Participantes.....................................................................................................14

1.9.4 Colaboraciones.................................................................................................15

1.10 Singleton..............................................................................................................15

1.10.1 Aplicabilidad..................................................................................................15

1.10.2 Estructura......................................................................................................15

1.10.3 Participantes..................................................................................................16

1.10.4 Colaboraciones..............................................................................................16

1.11 Patrones Estructurales.........................................................................................17

1.12 Adapter.................................................................................................................17

ii
 1.12.1 Aplicabilidad..................................................................................................17

1.12.2 Estructura......................................................................................................18

1.12.3 Participantes..................................................................................................18

1.12.4 Colaboraciones..............................................................................................19

1.13 Bridge...................................................................................................................19

1.13.1 Aplicabilidad..................................................................................................19

1.13.2 Estructura......................................................................................................20

1.13.3 Participantes..................................................................................................20

1.13.4 Colaboraciones..............................................................................................20

1.14 Composite............................................................................................................21

1.14.1 Aplicabilidad..................................................................................................21

1.14.2 Estructura......................................................................................................21

1.14.3 Participantes..................................................................................................22

1.15 Decorator.............................................................................................................23

1.15.1 Aplicabilidad..................................................................................................23

1.15.2 Estructura......................................................................................................23

1.15.3 Participantes..................................................................................................24

1.15.4 Colaboraciones..............................................................................................24

1.16 Facade.................................................................................................................25

1.16.1 Aplicabilidad..................................................................................................25

1.16.2 Estructura......................................................................................................25

1.16.3 Participantes..................................................................................................26

1.16.4 Colaboraciones..............................................................................................26

1.17 Flyweight..............................................................................................................27

1.17.1 Aplicabilidad..................................................................................................27

iii
 1.17.2 Estructura......................................................................................................27

1.17.3 Participantes..................................................................................................28

1.17.4 Colaboraciones..............................................................................................29

1.18 Proxy....................................................................................................................29

1.18.1 Aplicabilidad..................................................................................................29

1.18.2 Estructura......................................................................................................30

1.18.3 Participantes..................................................................................................30

1.18.4 Colaboraciones..............................................................................................31

1.19 Patrones de Comportamiento..............................................................................32

1.20 Chain of Responsability.......................................................................................32

1.20.1 Aplicabilidad..................................................................................................32

1.20.2 Estructura......................................................................................................33

1.20.3 Participantes..................................................................................................33

1.20.4 Colaboraciones..............................................................................................33

1.21 Command.............................................................................................................34

1.21.1 Aplicabilidad..................................................................................................34

1.21.2 Estructura......................................................................................................35

1.21.3 Parcitipantes..................................................................................................35

1.21.4 Colaboración.................................................................................................36

1.22 Interpreter.............................................................................................................37

1.22.1 Aplicabilidad..................................................................................................37

1.22.2 Estructura......................................................................................................37

1.22.3 Participantes..................................................................................................38

1.22.4 Colaboraciones..............................................................................................38

1.23 Iterator..................................................................................................................39

iv
 1.23.1 Aplicabilidad..................................................................................................39

1.23.2 Estructura......................................................................................................39

1.23.3 Participante....................................................................................................40

1.23.4 Colaboraciones..............................................................................................40

1.24 Mediator...............................................................................................................40

1.24.1 Aplicabilidad..................................................................................................40

1.24.2 Estructura......................................................................................................41

1.24.3 Participantes..................................................................................................41

1.24.4 Colaboraciones..............................................................................................42

1.25 Memento..............................................................................................................42

1.25.1 Aplicabilidad..................................................................................................42

1.25.2 Estructura......................................................................................................42

1.25.3 Participantes..................................................................................................43

1.25.4 Colaboraciones..............................................................................................43

1.26 Observer...............................................................................................................44

1.26.1 Aplicabilidad..................................................................................................44

1.26.2 Estructura......................................................................................................44

1.26.3 Participantes..................................................................................................45

1.26.4 Colaboraciones..............................................................................................45

1.27 State.....................................................................................................................46

1.27.1 Aplicabilidad..................................................................................................46

1.27.2 Structura........................................................................................................46

1.27.3 Participantes..................................................................................................47

1.27.4 Colaboraciones..............................................................................................47

1.28 Strategy................................................................................................................48

v
 1.28.1 Aplicabilidad..................................................................................................48

1.28.2 Estructura......................................................................................................48

1.28.3 Participantes..................................................................................................49

1.28.4 Colaboraciones..............................................................................................49

1.29 Template Method.................................................................................................50

1.29.1 Aplicabilidad..................................................................................................50

1.29.2 Estructura......................................................................................................50

1.29.3 Participantes..................................................................................................51

1.29.4 Colaboraciones..............................................................................................51

1.30 Visitor...................................................................................................................51

1.30.1 Aplicabilidad..................................................................................................51

1.30.2 Estructura......................................................................................................52

1.30.3 Participantes..................................................................................................53

1.30.4 Colaboraciones..............................................................................................53

2 CAPÍTULO III. METODOLOGÍA DE LA INVESTIGACIÓN...........................................56

2.1 Tipo de Investigación..............................................................................................56

2.2 Unidad de Análisis...................................................................................................56

2.3 Variables y su medición..........................................................................................57

vi
INDICE DE ILUSTRACIONES
Ilustración 1 representación geográfica de la Universidad de Sonsonate.............................4
Ilustración 2 Diagrama de Factory Method............................................................................8
Ilustración 3 Estructura Factory Method.................................................................................9
Ilustración 4 Diagrama Abstract Factory..............................................................................10
Ilustración 5 Estructura de Abstrac Factory.........................................................................11
Ilustración 6 Diagrama Builder.............................................................................................12
Ilustración 7 Estructura Builder.............................................................................................12
Ilustración 8 Diagrama de Prototype....................................................................................13
Ilustración 9 Estructura de Prototype...................................................................................14
Ilustración 10 Diagrama de SIngleton..................................................................................15
Ilustración 11 Estructura de Singleton..................................................................................15
Ilustración 12 Estructura de Adapter....................................................................................18
Ilustración 13 Estructura de Bridge......................................................................................20
Ilustración 14 Estructura de Composite...............................................................................21
Ilustración 15 Estructura de Decorator.................................................................................23
Ilustración 16 Estructura de Facade.....................................................................................25

vii
Ilustración 17 estructura de Flyweight..................................................................................27
Ilustración 18 Estructura de Proxy........................................................................................30
Ilustración 19 Estructura de Chain of Responsability...........................................................33
Ilustración 20 Estructura de Command................................................................................35
Ilustración 21 Diagrama de Command.................................................................................36
Ilustración 22 Estructura de Interpreter................................................................................37
Ilustración 23 Estructura de Iterator.....................................................................................39
Ilustración 24 Estructura de Mediator...................................................................................41
Ilustración 25 Estructura de Memento..................................................................................42
Ilustración 26 Diagrama de Memento..................................................................................43
Ilustración 27 Estructura de Observer..................................................................................44
Ilustración 28 Diagrama de Observer...................................................................................45
Ilustración 29 Estructura de State........................................................................................46
Ilustración 30 Estructura de Strategy...................................................................................48
Ilustración 31 Estructura de Template Method.....................................................................50
Ilustración 32 Estructura de Visitor.......................................................................................52
Ilustración 33 Diagrama de Visitor........................................................................................54

viii
INDICE DE TABLAS
Tabla 1 Catalogo de Gang of Four (Patrones de Diseño)......................................................6
Tabla 2 Variables y su Medición...........................................................................................57
Tabla 3 Variables y su Medición...........................................................................................58

ix
 RESUMEN
Entre los diferentes tipos de diseño de patrones según The Gang of Four (El grupo de los
cuatro) se encuentran una variada lista de patrones muy importantes para el área de
desarrollo de muchas empresas, las TI (tecnologías de la Información) u estudiantes a
fines tecnológicos.
El objetivo de esta tesis es demostrar el uso y aplicabilidad de los patrones de diseño en
tiempo real, tiempo real debido a que los problemas surgen de manera imprevista a la
hora de hacer un cambio en algunas líneas de código o darle mantenimiento a cierto
programa o aplicación.
Se llevará a cabo una serie de pruebas con el lenguaje de programación en Java haciendo
uso de los patrones más apropiados para resolver bugs(errores) en piezas de código. Con
esto se podrá observar los las patrones más óptimos y la aplicabilidad de estos.
Como propuesta se llevará a cabo la creación de algunos patrones de diseño para la
optimización de tiempo, esfuerzo y para la comprensión de ellos por medio de un lenguaje
de programación de alto nivel como lo es Java. En dicho lenguaje se desarrollarán piezas
de código o programas para las distintas pruebas que se realizaran con los patrones de
diseño.

x
 INTRODUCCIÓN
Los patrones diseño hasta el día de hoy siguen siendo muy importantes ya que con ellos
se puede optimizar tiempo y trabajo, ya que los patrones de diseño brindan respuestas,
soluciones a problemas técnicos de la programación orientada a objetos, el código luce
más profesional, en fin, se tienen muchas ventajas al aplicar los patrones de diseño. Estos
patrones de diseño están categorizados de la siguiente forma: Creacionales, estructurales
y de comportamiento cada Patrón de Diseño se compone de una estructura de clases e
interfaces que le permiten encajar en cualquier tipo de proyecto en el que se implemente
programación orientada a objetos. Actualmente no hay personas dedicadas al área de
desarrollo que implementen estas herramientas por lo cual es muy poco el conocimiento
que se obtiene en la Universidad de Sonsonate.
Por lo antes mencionado se ve la necesidad de aplicar Patrones de Diseño que favorezca
a todo aquel que da sus primeros pasos en la programación como el que ya es un experto.
La presente investigación tiene como objetivo la realización de los patrones de diseño para
lo cual se obtiene información del libro [ CITATION Eri94 \l 3082 ]. Para después analizar
los datos recolectados de cada Patrón de Diseño, es importante la realización de
diferentes pruebas experimentales para la obtención de información adecuada para los
Patrones de Diseño.
La implementación de los patrones de diseño es importante debido a que dota al software
de un nivel de calidad y rendimiento, actualmente no se toma en cuenta su aplicabilidad en
materias de desarrollo de software, su uso puede ayudar a quienes trabajan o estudian
carreras afines tecnológicas.
xi
A continuación, se presenta una breve descripción de los capítulos y su contenido:
Capítulo 1. Planteamiento del Problema. Este capítulo muestra el problema de
investigación, antecedentes y situación actual en cuanto a los Patrones de Diseño,
aspectos generales, objetivo general y específicos, justificación y delimitación del proyecto

xii
 CAPÍTULO I.
PLANTEAMIENTO DEL PROBLEMA

1
 1. CAPÍTULO I. PLANTEAMIENTO DEL PROBLEMA

1. El problema de investigación
Una de las problemáticas que surgen es que muchos estudiantes y/o profesionales
ante un problema técnico de programación, no encuentran una solución óptima o
tardan demasiado en concebir alguna solución, debido a que no tienen una
preparación específica sobre este tipo de tema. Por lo cual llegan a implementar
soluciones no tan eficientes o técnicas para los problemas comunes de
programación orientada a objetos.
Actualmente no se habla mucho de los patrones de diseño, sin embargo, tiene una
gran importancia en el funcionamiento y rendimiento de las aplicaciones.

2. Antecedentes del problema

El tema abordado en esta investigación es importante en el contexto del desarrollo
de software, puesto que, aplicar patrones de diseño es considerado una buena
práctica que apoya el aumento de calidad ya que un patrón de diseño es una
solución a un problema recurrente en el diseño de software, por ello es importante
hacer énfasis en esta temática ya que se está tomando en cuenta muy poco en la
carrera de Ingeniería en Sistemas de la Universidad de Sonsonate.
Por lo cual es necesario brindar información concisa y precisa y de cómo aplicarlos
en software mediante el uso de cualquier lenguaje de programación, pero para
efectos de este trabajo se va presentar en el lenguaje de programación en Java
aunque los conceptos sean fácilmente extrapolado a otros lenguajes de
programación.

2
3. Objetivos
1. General
Implementar el tema de patrones de diseño en la Universidad de Sonsonate en
la carrera de Ingeniería en Sistemas.

2. Específicos
 Analizar los patrones de diseño en la programación orientada a objetos.
 Documentar la información de los patrones de diseño.
 Identificar situaciones o procesos en donde se puedan aplicar los
patrones de diseño.
 Aplicar los patrones de diseño en la programación orientada a objetos.

4. Justificación
Los patrones de diseño son muy importantes ya que brindan soluciones eficientes
a problemas de programación orientada a objetos, minimizan tiempo y esfuerzo a
la hora de solucionar problemas técnicos de codificación, ayudan a tener un
software con mejor rendimiento debido a que se usaran soluciones ampliamente
conocidas y probadas.
Debido al desconocimiento acerca de los patrones de diseño y de su aplicación
muchos desarrolladores no pueden resolver problemas de forma concisa y
eficiente en la programación orientada a objetos, ya que estos necesitan saber el
conocimiento para aplicar los patrones de diseño.

5. Delimitación del proyecto

La aplicación de patrones de diseño se enfocará en 10 patrones los cuales serán
elegidos del libro “The Gang of Four” dependiendo de su importancia.

3
 1.5.1 Delimitación temporal:
La investigación se realizará durante los meses de marzo a octubre del 2020

1.5.2 Delimitación espacial:

Se realizará en la Universidad de Sonsonate (USO) especialmente en la carrera de
Ingeniería en Sistemas.

1.5.3 Unidad de análisis:

Se realizará en el ciclo 02 del año 2020

Ilustración 1 representación geográfica de la Universidad de Sonsonate

4
CAPÍTULO ll. MARCO DE LA INVESTIGACÍON

5
 CAPÍTULO II. MARCO DE INVESTIGACIÓN
1.1 Patrones de Diseño
Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, y luego,
describe el núcleo de la solución a ese problema, de tal manera que se puede utilizar esta
solución un millón de veces, sin tener que hacerlo de la misma manera dos veces
[ CITATION Chr78 \l 3082 ].

1.2 Patrones de Diseño más utilizados

Patrones Gang of Four (GoF)

1.3 Clasificación de los Patrones según The Gang of Four

 Propósito
 Refleja lo que hace un patrón
 Se divide en Patrones de Creación, Estructura y Comportamiento
 Alcance
 Especifica si el patrón se aplica principalmente a clases u objetos
 Patrones de Clase y objeto

1.4 Catálogo de GoF está dividido en tres categorías

Tabla 1 Catalogo de Gang of Four (Patrones de Diseño)

Propósito    
  Creación Estructural Comportamiento
Interpretar Template
Herencia Factory Method Adapter
Method
    Chain of Responsability
  Adapter Command
Abstract
Iterator
Ámbito Factory Bridge
Composición Builder Composite Memento
Prototype Decorator Observer
Singleton Facade State
  Flyweight Strategy
  Proxy Visitor
6
1.5 Patrones Creacionales
Los patrones de diseño creativo abstraen el proceso de instalación. Ayudan a hacer un
sistema independiente de cómo se crean, componen y representan sus objetos. Un patrón
creativo de clase utiliza la herencia para variar la clase que es instanciada, mientras que
un patrón creativo de objeto delegara la instalación a otro objeto.
Hay dos temas recurrentes en estos patrones. En primer lugar, encapsulan el
conocimiento sobre que clases concretas utiliza el sistema. En segundo lugar, ocultan
cómo se crean y se juntan las instancias de estas clases. Todo lo que el sistema sabe
sobre los objetos son sus interfaces definidas por clases abstractas.[ CITATION Eri94 \l
3082 ]

1.5.1 Lista de Patrones Creacionales

1. Factory Method
2. Abstract Factory
3. Builder
4. Prototype
5. Singleton

1.5.2 Lista de Patrones Estructurales

6. Adapter
7. Bridge
8. Composite
9. Decorator
10. Facade
11. Flyweight
12. Proxy

7
1.5.3 Lista de Patrones de Comportamiento
13. Interpreter
14. Template Method
15. Chain of Responsability
16. Command
17. Iterator
18. Mediator
19. Memento
20. Observer
21. State
22. Strategy
23. Visitor

1.6 Factory Method

Define una interfaz para crear un objeto, pero dejar que las subclases decidan que clase
instanciar. El método de fabrica permite que una clase difiera la instanciación a las
subclases, también conocido como: Constructor Virtual [ CITATION Eri94 \l 3082 ]

Ilustración 2 Diagrama de Factory Method

8
1.6.1 Aplicabilidad
 Usar el patrón del Método de Fábrica cuando:
 Una clase no puede anticipar la clase de objetos que debe crear.
 Una clase quiere que sus subclases especifiquen los objetos que crea.
 Delegan la responsabilidad a una de las varias subclases de ayudantes, y quieres
localizar el conocimiento de qué subclase de ayudantes es la delegada.

1.6.2 Estructura

Ilustración 3 Estructura Factory Method

1.6.3 Participantes
Producto (Documento)
 define la interfaz de los objetos que el método de la fábrica crea.
ConcreteProduct (MyDocument)
 implementa la interfaz del producto.
Creator (Aplicación)
 declara el método de la fábrica, que devuelve un objeto de tipo Producto. El
creador también puede definir una implementación por defecto del método de
fabrica que devuelve un objeto de tipo ConcreteProdut por defecto.
 puede llamar al método de la fábrica para crear un objeto del producto
ConcreteCreator (MyAplicación)
 anula el método de la fábrica para devolver una instancia de un producto de
hormigón.
9
1.7 Abstract Factory
Proporcionar una interfaz para crear familias de objetos relacionados o dependientes sin
especificar sus clases concretas.

Ilustración 4 Diagrama Abstract Factory

1.7.1 Aplicabilidad
Usar el patrón de Fábrica de abstractos cuando:
 Un sistema debe ser independiente de la forma en que sus productos son creados,
compuestos y representados
 Un sistema debe estar configurado con una de las múltiples familias de productos
 Una familia de objetos de productos relacionados está diseñada para ser utilizada
conjuntamente, y es necesario hacer cumplir esta restricción.
 Se quiere proporcionar una biblioteca de clases de productos, y se quiere revelar
solo sus interfaces, no sus implementaciones.

10
1.7.2 Estructura

Ilustración 5 Estructura de Abstrac Factory

1.7.3 Participantes
AbstractFactory (widegetFactory)
 declara una interfaz para las operaciones que crean objetos de productos
abstractos.
ConcreteFactory (MotifWidgetFactory, PMWidgetFactory)
 Implementa las operaciones para crear objetos de productos concretos
AbstractProduct (Window, ScrollBar)
 Declara una interfaz para un tipo de objeto de produto
ConcreteProduct (MotifWindow, MotifSceollBar)
 Define un objeto de producto a ser creado por la correspondiente fábrica de
hormigon
 Implementa la interfaz de AbstractProduct
Cliente
 Utiliza solo interfaces declaradas por las clases AbstractFactory y AbstractProduct

11
1.8 Builder
Separar la construcción de un objeto complejo de su representación, de modo que el
mismo proceso de construcción pueda crear diferentes representaciones.

Ilustración 6 Diagrama Builder

1.8.1 Aplicabilidad
 Use el patrón del Constructor cuando:
 El algoritmo para crear un objeto complejo debe ser independiente de las partes
que componen el objeto y de cómo están ensambladas.
 El proceso de construcción debe permitir diferentes representaciones para el objeto
que se construye.

1.8.2 Estructura

Ilustración 7 Estructura Builder

12
1.8.3 Participantes
Constructor (TextConverter)
 Especifica una interfaz abstracta para crear partes de un objeto Producto
ConcreteBuilder (ASCIIConverter, TeXConverter, TextWidgetConverter)
 Construye y ensambla partes del producto implementando la interfaz Builder
 Define y lleva la cuenta de la representación que crea.
 Proporciona una interfaz para recuperar el producto (por ejemplo, GetASCIIText,
GetTextWIdger).
Director (RTFReader)
 Construye un objeto usando la interfaz del constructor.
Producto (ASCIIText, TeXText, TextWIdget)
 Representa el complejo objeto en construcción. ConcreteBuilder construye la
representación interna del producto y define el proceso por el cual se ensambla.
 Incluye clases que definen las partes constituyentes, incluyendo interfaces para
ensamblar las partes en el resultado final.

1.9 Prototype
Especificar los tipos de objetos a crear usando una instancia prototípica, y crear nuevos
objetos copiando este prototipo.

Ilustración 8 Diagrama de Prototype

13
1.9.1 Aplicabilidad
Utilizar el patrón del prototipo cuando un sistema debe ser independiente de la forma en
que sus productos son creados, compuestos y representados; y
 Cuando las clases a instanciar se especifican en tiempo de ejecución, por ejemplo,
por carga dinámica; o
 Para evitar la construcción de una jerarquía de clase de fábricas que sea paralela a
la jerarquía de clase de los productos; o
 Cuando los casos de una clase pueden tener una de las pocas combinaciones
diferentes de estado. Puede ser más conveniente instalar un numero
correspondiente de prototipos y clonarlos en lugar de instanciar la clase
manualmente, cada vez con el estado apropiado

1.9.2 Estructura

Ilustración 9 Estructura de Prototype

1.9.3 Participantes
Prototipo (Grafico)
 Declara una interfaz para la clonación en sí misma.
ConcretePrototype (Staff, WholeNote, HalfNote)
 Implementa una operación para la clonación en sí misma
Cliente (GraphicTool)
 Crea un nuevo objeto pidiendo a un prototipo que se clone a sí mismo.

14
1.9.4 Colaboraciones
Un cliente pide a un prototipo que se clone a sí mismo.

1.10 Singleton
Asegúrate de que una clase solo tiene una instancia, y proporciona un punto de acceso
global a la misma.

Ilustración 10 Diagrama de SIngleton

1.10.1 Aplicabilidad
Use el patrón Singleton cuando
 Deba hacer exactamente una instancia de una clase, y debe ser accesible a los
clientes desde un punto de acceso conocido.
 Cuando la única instancia debe ser extensible por subclasificación, y los clientes
deben utilizar una instancia extendida sin modificar su código.

1.10.2 Estructura

Ilustración 11 Estructura de Singleton

15
1.10.3 Participantes
Singleton
 Define una operación de instancia que permite a los clientes acceder a su instancia
única. La instancia es una operación de clase (es decir, un método de clase en
Smalltalk y una función de miembro estático en C++)
 Puede ser responsable de crear su propia instancia única

1.10.4 Colaboraciones
 Los clientes acceden a una instancia de Singleton únicamente a través de la
operación de la instancia de Singleton

16
1.11 Patrones Estructurales
Los patrones estructurales se ocupan de la forma en que las clases y los objetos se
componen para formar estructuras más grandes. Los patrones de clases estructurales
utilizan la herencia para componer interfaces o implementación. Como un ejemplo simple,
considere como la herencia múltiple mezcla dos o más clases en una sola, considere
como la herencia combina las propiedades de sus clases superiores. Este patrón es
particularmente útil para hacer que las bibliotecas de clases desarrolladas
independientemente funcionen juntas. [ CITATION Eri94 \l 3082 ]

1.12 Adapter

Convertir la interfaz de una clase en otra interfaz que los clientes esperan. El adaptador
permite que las clases trabajen juntas que de otra manera no podrían debido a interfaces
incompatibles, también conocido como Envoltura

1.12.1 Aplicabilidad
Utilice el patrón del adaptador cuando:
 Quieres usar una clase existente, y su interfaz no coincide con la que necesitas.
 Quieres crear una clase reutilizable que coopere con clases no relacionadas o
imprevistas, es decir, clases que no necesariamente tienen interfaces compatibles.
 (solo el adaptador de objetos) es necesario utilizar varias soluciones existentes,
pero no es practico adaptar su interfaz subclasificando cada una de ellas. Un
adaptador de objetos puede adaptar la interfaz de su clase superior.

17
1.12.2 Estructura
Un adaptador de clase utiliza la herencia múltiple para adaptar una interfaz a otra:

Ilustración 12 Estructura de Adapter

Un adaptador de objetos se basa en la composición del objeto:

1.12.3 Participantes
Objetivo (Forma)
 Define la interfaz específica del dominio que utiliza el cliente
Cliente (DraqingEditor)
 Colabora con los objetos que se ajustan a la interfaz del Objetivo
Adaptee (TexttView)
 Define una interfaz existente que necesita ser adaptada.
Adaptador (TextShape)
 Adapta la interfaz de Adaptee a la interfaz de Target

18
1.12.4 Colaboraciones
Los clientes llaman a las operaciones en una instancia del adaptador. A su vez, el
adaptador llama a las operaciones el Adaptador que llevan a cabo la solicitud.

1.13 Bridge
Desvincular una abstracción de su aplicación para que ambas puedan variar
independientemente, también conocido como Mango/Cuerpo (Handle/Cuerpo)

1.13.1 Aplicabilidad
Use el patrón del Puente cuando
 quieres evitar una unión permanente entre una abstracción y su aplicación. Este
podría ser el caso, por ejemplo, cuando la implementación debe ser seleccionada o
cambiada en tiempo de ejecución.
 Tanto las abstracciones como sus implementaciones deben ser extensibles
mediante subclasificación. En este caso, la pauta del Puente permite combinar las
diferentes abstracciones e implementaciones y extenderlas independientemente.
 Los cambios en la implementación de una abstracción no deberían tener ningún
impacto en los clientes; es decir, su código no debería tener que ser recompilado.
 (C++) quieres ocultar la implementación de una abstracción completamente a los
clientes. En C++ la representación de una clase es visible en la interfaz de la clase.
 tienes una proliferación de clases como se muestra anteriormente en el primer
diagrama de Motivación. Tal jerarquía de clases indica la necesidad de dividir un
objeto en dos partes.
 Rumbaugh utiliza el término "generalizaciones anidadas" para referirse a tales
jerarquías de clase, que desea compartir una implementación entre múltiples
objetos (tal vez usando el conteo de referencias), y este hecho debe ser ocultado al
cliente.

19
1.13.2 Estructura

Ilustración 13 Estructura de Bridge

1.13.3 Participantes
Abstracción (Window)
 define la interfaz de la abstracción.
 mantiene una referencia a un objeto de tipo Implementador.
RefinedAbstraction (IconWindow)
 Amplía la interfaz definida por la Abstracción.
mplementador (WindowImp)
 define la interfaz para las clases de implementación. Esta interfaz no tiene que
corresponder exactamente a la interfaz de la Abstracción; de hecho, las dos
interfaces pueden ser bastante diferentes. Típicamente, la interfaz de Implementor
proporciona sólo operaciones primitivas, y Abstracción define operaciones de nivel
superior basadas en estas primitivas.
ConcreteImplementor (XWindowImp, PMWindowImp)
 implementa la interfaz del Implementador y define su aplicación concreta.

1.13.4 Colaboraciones
 La abstracción reenvía las solicitudes de los clientes a su objeto ejecutor.

20
1.14 Composite
Componer objetos en estructuras de árbol para representar jerarquías parciales o totales.
La composición permite tratar los objetos individuales y las composiciones de objetos de
manera uniforme.

1.14.1 Aplicabilidad
 Use el patrón compuesto cuando
 quieres representar jerarquías parciales de objetos.
 quieres que los clientes sean capaces de ignorar la diferencia entre las
composiciones de los objetos y los objetos individuales. Los clientes tratarán todos
los objetos de la estructura compuesta de manera uniforme

1.14.2 Estructura

Ilustración 14 Estructura de Composite

Una típica estructura de objeto compuesto podría verse así:

21
1.14.3 Participantes
Component (Gráfico)
 declara la interfaz para los objetos de la composición.
 implementa un comportamiento por defecto para la interfaz común a todas las
clases, según corresponda.
 declara una interfaz para acceder y gestionar sus componentes hijos.
 (opcional) define una interfaz para acceder al padre de un componente en la
estructura recursiva, y la implementa si es apropiado.
Leaf (Rectángulo, Línea, Texto, etc.)
 representa los objetos de la hoja en la composición. Una hoja no tiene hijos.
 define el comportamiento de los objetos primitivos en la composición.
 Composite (Imagen)
 define el comportamiento de los componentes que tienen hijos.
 almacena los componentes que tienen hijos.
 implementa operaciones relacionadas con los niños en la interfaz de los
componentes.
Client
 manipula los objetos de la composición a través de la interfaz de Componentes.

22
1.15 Decorator
Asignar responsabilidades adicionales a un objeto de forma dinámica. Los decoradores
proporcionan una alternativa flexible a la subclasificación para ampliar la funcionalidad,
también se conoce como: Wrapper

1.15.1 Aplicabilidad
Usar el decorador:
 para añadir responsabilidades a los objetos individuales de forma dinámica y
transparente, es decir, sin afectar a otros objetos.
 para las responsabilidades que pueden ser retiradas.
 cuando la extensión por subclasificación no es práctica. A veces un gran número de
extensiones independientes son posibles y producirían una explosión de subclases
para apoyar cada combinación. O una definición de clase puede estar oculta o no
disponible para la subclasificación.

1.15.2 Estructura

Ilustración 15 Estructura de Decorator

23
1.15.3 Participantes
Component (VisualComponent)
 Define la interfaz para los objetos que pueden tener responsabilidades añadidas
dinámicamente.
ConcreteComponent (TextView)
 define un objeto al que se pueden asignar responsabilidades adicionales.
Decorator
 mantiene una referencia a un objeto de Componente y define una interfaz que se
ajusta a la interfaz de Componente.
ConcreteDecorator (BorderDecorator, ScrollDecorator)
 añade responsabilidades al componente.

1.15.4 Colaboraciones
 El decorator envía las solicitudes a su objeto componente. Opcionalmente, puede
realizar operaciones adicionales antes y después de enviar la solicitud.

24
1.16 Facade
Proporcionar una interfaz unificada a un conjunto de interfaces en un subsistema. Fachada
define una interfaz de nivel superior que facilita el uso del subsistema.

1.16.1 Aplicabilidad
Use el patrón de la Fachada cuando
 quieres proporcionar una interfaz simple a un subsistema complejo. Los
subsistemas a menudo se vuelven más complejos a medida que evolucionan. La
mayoría de los patrones, cuando se aplican, dan como resultado más y más
pequeñas clases. Esto hace que el subsistema sea más reutilizable y más fácil de
personalizar, pero también se vuelve más difícil de usar para los clientes que no
necesitan personalizarlo. Una fachada puede proporcionar una simple vista
predeterminada del subsistema que es lo suficientemente buena para la mayoría de
los clientes. Sólo los clientes que necesiten más personalización tendrán que mirar
más allá de la fachada.
 Hay muchas dependencias entre los clientes y las clases de implementación de una
abstracción. Introducir una fachada para desacoplar el subsistema de los clientes y
otros subsistemas, promoviendo así la independencia y la portabilidad del
subsistema.
 quieres poner en capas a tus subsistemas. Usar una fachada para definir un punto
de entrada a cada nivel de subsistema. Si los subsistemas son dependientes,
entonces puedes simplificar las dependencias entre ellos haciendo que se
comuniquen entre sí únicamente a través de sus fachadas.

1.16.2 Estructura

Ilustración 16 Estructura de Facade 25

1.16.3 Participantes
Facade (Compiler)
 sabe qué clases de subsistemas son responsables de una solicitud.
 delega las solicitudes de los clientes a los objetos apropiados del subsistema.
subsystem classes (Scanner, Parser, ProgramNode, etc.)
 implementa la funcionalidad del subsistema.
 maneja el trabajo asignado por el objeto Fachada.
 no tienen conocimiento de la fachada; es decir, no guardan ninguna referencia a la
misma.

1.16.4 Colaboraciones
 Los clientes se comunican con el subsistema enviando solicitudes a Fachada, que
las reenvía al objeto u objetos del subsistema apropiado. Aunque los objetos del
subsistema realizan el trabajo real, la fachada puede tener que hacer un trabajo
propio para traducir su interfaz a las interfaces del subsistema.
 Los clientes que utilizan la fachada no tienen que acceder directamente a los
objetos del subsistema.

26
1.17 Flyweight
Usar el intercambio para apoyar eficientemente a un gran número de objetos de grano
fino.

1.17.1 Aplicabilidad
 La efectividad del patrón de peso mosca depende en gran medida de cómo y dónde
se usa.
 Aplique el patrón de peso mosca cuando todo lo siguiente sea cierto:
 Una aplicación utiliza un gran número de objetos.
 Los costos de almacenamiento son altos debido a la gran cantidad de objetos.
 La mayor parte del estado de los objetos puede hacerse extrínseco.
 Muchos grupos de objetos pueden ser reemplazados por relativamente pocos
objetos compartidos una vez que se elimina el estado extrínseco.
 La aplicación no depende de la identidad del objeto. Como los objetos de peso
mosca pueden ser compartidos, las pruebas de identidad serán válidas para los
objetos conceptualmente distintos.

1.17.2 Estructura

Ilustración 17 estructura de Flyweight 27

El siguiente diagrama de objetos muestra cómo se comparten los pesos voladores:

1.17.3 Participantes
Flyweight
 declara una interfaz a través de la cual los pesos voladores pueden recibir y actuar
en estado extrínseco.
ConcreteFlyweight (Character)
 implementa la interfaz del peso mosca y añade almacenamiento para el estado
intrínseco, si lo hay. Un objeto ConcreteFlyweight debe ser compartible. Cualquier
estado que almacene debe ser intrínseco, es decir, debe ser independiente del
contexto del objeto ConcreteFlyweight.
UnsharedConcreteFlyweight (Row, Column)
 No todas las subclases de peso mosca necesitan ser compartidas. La interfaz de
Peso mosca permite compartir; no lo impone. Es común que los objetos de
Flyweight no compartidos tengan objetos de peso mosca en algún nivel de la
estructura de objetos de peso mosca (como tienen las clases de Fila y Columna).
FlyweightFactory
 crea y maneja objetos de peso mosca.
 se asegura de que los pesos mosca se compartan adecuadamente. Cuando un
cliente solicita un Flyweight, el objeto FlyweightFactory suministra una instancia
existente o crea una, si no existe ninguna.

28
Client
 mantiene una referencia al peso de las moscas.
 calcula o almacena el estado extrínseco del peso mosca.

1.17.4 Colaboraciones
 La afirmación de que un peso de mosca debe funcionar debe caracterizarse como
intrínseco o extrínseco. El estado intrínseco se almacena en el ConcreteFlyweight
object; el estado extrínseco es almacenado o computado por los objetos del Cliente.
Los clientes pasan este estado al peso mosca cuando invocan sus operaciones.
 Los clientes no deben instanciar a ConcreteFlyweights directamente. Los clientes
deben obtener los objetos ConcreteFlyweight exclusivamente del objeto
FlyweightFactory para asegurarse de que son compartidos correctamente.

1.18 Proxy
Proporcionar un sustituto o un marcador de posición para otro objeto para controlar el
acceso a él, también conocido como: Surrogate

1.18.1 Aplicabilidad
 El proxy es aplicable siempre que se necesite una referencia más versátil o
sofisticada a un objeto que un simple puntero. Aquí hay varias situaciones comunes
en las que el patrón Proxy es aplicable:
 Un proxy remoto proporciona un representante local para un objeto en un espacio
de dirección diferente
 Un proxy virtual crea objetos caros a pedido. El ImageProxy descrito en la
Motivación es un ejemplo de tal proxy.
 Un proxy de protección controla el acceso al objeto original. Los proxys de
protección son útiles cuando los objetos deben tener diferentes derechos de
acceso.

29
  Una referencia inteligente es un sustituto de un puntero desnudo que realiza
acciones adicionales cuando se accede a un objeto. Los usos típicos incluyen:
 contar el número de referencias al objeto real para que pueda ser liberado
automáticamente cuando no haya más referencias (también llamados punteros
inteligentes) cargando un objeto persistente en la memoria cuando se hace una
referencia por primera vez.
 O comprobando que el objeto real está bloqueado antes de que se acceda a él para
asegurar que ningún otro objeto puede cambiarlo.

1.18.2 Estructura

Ilustración 18 Estructura de Proxy

Aquí hay un posible diagrama de objeto de una estructura proxy en tiempo de ejecución:

1.18.3 Participantes
Proxy (ImageProxy)
 mantiene una referencia que permite al apoderado acceder al sujeto real. El proxy
puede referirse a un sujeto si las interfaces del sujeto y del sujeto son las mismas.
 proporciona una interfaz idéntica a la del sujeto para que un proxy pueda sustituir al
sujeto real.

30
  controla el acceso al sujeto real y puede ser responsable de crearlo y borrarlo.
 otras responsabilidades dependen del tipo de proxy:
 Los proxies remotos son responsables de codificar una solicitud y sus
argumentos y de enviar la solicitud codificada al sujeto real en un espacio de
dirección diferente.
 los proxies virtuales pueden almacenar en caché información adicional sobre
el sujeto real para poder posponer el acceso a él. Por ejemplo, el
ImageProxy de la Motivación almacena en caché la extensión de la imagen
real.
 los proxies de protección comprueban que la persona que llama tiene los
permisos de acceso necesarios para realizar una solicitud.

Subject (Graphic)
 define la interfaz común para el RealSubject y el Proxy para que un Proxy pueda
ser usado en cualquier lugar donde se espere un RealSubject.
RealSubject (Image)
 define el objeto real que el representante representa.

1.18.4 Colaboraciones
 El apoderado reenvía las solicitudes a RealSubject cuando es apropiado,
dependiendo del tipo de apoderado.

31
1.19 Patrones de Comportamiento
Los patrones de comportamiento están relacionados con los algoritmos y la asignación de
responsabilidades entre los objetos. Los patrones de comportamiento no sólo describen
los patrones de los objetos o clases, sino también los patrones de comunicación entre
ellos. Estos patrones caracterizan un flujo de control completo que es difícil de seguir en
tiempo de ejecución. Cambian el enfoque del flujo de control para permitirle concentrarse
sólo en la forma en que los objetos están interconectados.
Los patrones de clase de comportamiento utilizan la herencia para distribuir el
comportamiento entre las clases. Este capítulo incluye dos de estos patrones. Template
Method es el más simple y común de los dos. El método de Template es una definición
abstracta de un algoritmo. Define el algoritmo paso a paso. Cada paso invoca una
operación abstracta o una operación primitiva. Una subclase desarrolla el algoritmo
definiendo las operaciones abstractas. El otro patrón de clase de comportamiento es
Interpreter que representa una gramática como una jerarquía de clases e implementa un
intérprete como una operación en instancias de estas clases.[ CITATION Eri94 \l 3082 ]

1.20 Chain of Responsability

Evita acoplar el emisor de una petición a su receptor dando a más de un objeto la
oportunidad de manejar la petición. Encadene los objetos receptores y pase la solicitud a
lo largo de la cadena hasta que un objeto la maneje.

1.20.1 Aplicabilidad
 Utilice la cadena de responsabilidad cuando
 más de un objeto puede manejar una solicitud, y el manejador no sabe a priori. El
manejador debe ser determinado automáticamente.
 quieres emitir una solicitud a uno de varios objetos sin especificar el receptor
explícitamente.
 el conjunto de objetos que pueden manejar una solicitud debe ser especificado
dinámicamente.

32
1.20.2 Estructura

Ilustración 19 Estructura de Chain of Responsability

Una estructura de objeto típica podría verse así:

1.20.3 Participantes
Handler (HelpHandler)
 define una interfaz para la gestión de las solicitudes.
 (opcional) implementa el enlace sucesor.
ConcreteHandler (PrintButton, PrintDialog)
 maneja las solicitudes de las que es responsable.
 puede acceder a su sucesor.
 si el ConcreteHandler puede manejar la solicitud, lo hace; de lo contrario reenvía la
solicitud a su sucesor.
Client
 inicia la solicitud a un objeto de ConcreteHandler en la cadena.

33
1.20.4 Colaboraciones
 Cuando un cliente emite un pedido, éste se propaga a lo largo de la cadena hasta
que un objeto ConcreteHandler se hace responsable de su manejo.

1.21 Command
Encapsular una solicitud como un objeto, lo que le permite parametrizar clientes con
diferentes solicitudes, solicitudes de cola o de registro, y operaciones de soporte, también
conocido como Action, Transaction

1.21.1 Aplicabilidad
Usa el patrón de Comando cuando quieras
 parametrizar los objetos por una acción a realizar, como lo hicieron los objetos
MenuItem anteriores. Esta parametrización puede expresarse en un lenguaje de
procedimiento con una función de callback, es decir, una función que se registra en
algún lugar para ser llamada posteriormente. Los comandos son un sustituto
orientado a los objetos para las llamadas de retorno.
 especificar, poner en cola y ejecutar las solicitudes en diferentes momentos. Un
objeto de comando puede tener una vida independiente de la solicitud original. Si el
receptor de una solicitud puede ser representado de una manera independiente del
espacio de dirección, entonces puede transferir un objeto de comando para la
solicitud a un proceso diferente y cumplir la solicitud allí.
 apoyar deshacer. La operación Ejecutar del comando puede almacenar el estado
para revertir sus efectos en el propio comando. La interfaz del comando debe tener
una operación Unexecute añadida que invierta los efectos de una llamada previa a
Execute. Los comandos ejecutados se almacenan en una lista de historial. Se
puede deshacer y rehacer a nivel ilimitado recorriendo esta lista hacia atrás y hacia
delante llamando a Unexecute y a Execute, respectivamente.
 soportan cambios de registro para que puedan ser reaplicados en caso de una
caída del sistema. Aumentando la interfaz de comandos con operaciones de carga
y almacenamiento, se puede mantener un registro persistente de los cambios.

34
 Recuperarse de un fallo implica recargar los comandos registrados del disco y
volver a ejecutarlos con la operación Excute.
 estructurar un sistema alrededor de operaciones de alto nivel construidas sobre
operaciones primitivas. Tal estructura es común en los sistemas de información que
soportan transacciones. Una transacción encapsula un conjunto de cambios en los
datos. El patrón de Comando ofrece una forma de modelar las transacciones. Los
comandos tienen una interfaz común, que permite invocar todas las transacciones
de la misma manera. El patrón también facilita la ampliación del sistema con
nuevas transacciones.

1.21.2 Estructura

Ilustración 20 Estructura de Command

1.21.3 Parcitipantes
Command
 declara una interfaz para ejecutar una operación.
ConcreteCommand (PasteCommand, OpenCommand)
 define una unión entre un objeto Receptor y una acción.
 implementa Ejecutar invocando la(s) operación(es) correspondiente(s) en el
Receptor.
Client (Application)
 crea un objeto ConcreteCommand y establece su receptor.
Invoker (MenuItem)

35
  pide a la orden que lleve a cabo la petición.
Receiver (Document, Application)
 sabe cómo realizar las operaciones asociadas a la ejecución de una solicitud.
Cualquier clase puede servir de receptor.

1.21.4 Colaboración
 El cliente crea un objeto ConcreteCommand y especifica su receptor.
 Un objeto invocador almacena el objeto ConcreteCommand.
 El invocador emite una petición llamando a Ejecutar en el comando. Cuando los
comandos se pueden deshacer, ConcreteCommand almacena el estado para
deshacer el comando antes de invocar Execute.
 El objeto ConcreteCommand invoca operaciones en su receptor para llevar a cabo
la petición.

El siguiente diagrama muestra las interacciones entre estos objetos e ilustra cómo
Command desacopla el invocador del receptor (y la petición que éste realiza).

Ilustración 21 Diagrama de Command

36
1.22 Interpreter
Dado un idioma, definir una representación para su gramática junto con un intérprete que
utiliza la representación para interpretar frases en el idioma

1.22.1 Aplicabilidad
 Utilice el patrón del intérprete cuando haya un idioma que interpretar, y puede
representar declaraciones en el idioma como árboles de sintaxis abstractos. El
patrón del intérprete funciona mejor cuando
 la gramática es simple. Para las gramáticas complejas, la jerarquía de clase para la
gramática se vuelve grande e inmanejable. Herramientas como los
parsergenerators son una mejor alternativa en estos casos. Pueden interpretar las
expresiones textuales sin construir árboles de sintaxis abstractos, lo que puede
ahorrar espacio y posiblemente tiempo.
 La eficiencia no es una preocupación crítica. Los intérpretes más eficientes
generalmente no se implementan interpretando directamente los árboles de parse
sino que primero los traducen a otra forma. Por ejemplo, las expresiones regulares
se transforman a menudo en máquinas de estado. Pero incluso entonces, el
traductor puede ser implementado por el patrón de Interpretación, ese patrón sigue
siendo aplicable.

1.22.2 Estructura

37
1.22.3 Participantes
AbstractExpression (RegularExpression)
 declara una operación de interpretación abstracta que es común a todos los nodos
del árbol de sintaxis abstracta.
TerminalExpression (LiteralExpression)
 implementa una operación de Interpretación asociada a los símbolos terminales en
la gramática.
 se requiere una instancia para cada símbolo terminal de una frase.
NonterminalExpression
(AlternationExpression,RepetitionExpression,SequenceExpression)
 se requiere una clase de este tipo para cada regla R ::= R1 R2 ... Rn en la
gramática.
 mantiene variables de instancia de tipo AbstractExpression para cada uno de los
símbolos R1 a Rn.
 implementa una operación de Interpretación para los símbolos no terminales en la
gramática. Interpretando típicamente se llama a sí mismo recursivamente en las
variables que representan R1 a Rn
Context
 contiene información que es global para el intérprete.
Client
 construye (o se le da) un árbol de sintaxis abstracta que representa una oración
particular en el idioma que la gramática define. El árbol de sintaxis abstracta se
ensambla a partir de instancias de las clases de expresión no terminal y expresión
terminal.
 invoca la operación Interpret.
38
1.22.4 Colaboraciones
 El cliente construye (o se le da) la frase como un sintaxis abstracto de instancias de
expresión no terminal y de expresión terminal. Entonces el cliente inicializa el
contexto e invoca la Interpretación.
 Cada nodo de NonterminalExpression define Interpret en términos de Interpret en
cada subexpresión. La operación Interpret de cada TerminalExpression define el
caso base en la recursión.
 Las operaciones Interpret en cada nodo utilizan el contexto tostado y acceden al
estado del intérprete.

1.23 Iterator
Proporcionar una forma de acceder a los elementos de un objeto agregado en forma
secuencial sin exponer su representación subyacente, también conocido como: Cursor

1.23.1 Aplicabilidad
 Usar el patrón Iterator
 para acceder al contenido de un objeto agregado sin exponer su representación
interna.
 para soportar múltiples travesías de objetos agregados.
 para proporcionar una interfaz uniforme para atravesar diferentes estructuras de
agregados (es decir, para soportar la iteración polimórfica).

1.23.2 Estructura

39
1.23.3 Participante
Iterator
 define una interfaz para acceder y atravesar elementos.
ConcreteIterator
 implementa la interfaz Iterator.
 lleva la cuenta de la posición actual en la travesía del agregado.
Aggregate
 define una interfaz para crear un objeto Iterator.
ConcreteAggregate
 implementa la interfaz de creación del Iterator para devolver una instancia del
propio ConcreteIterator.

1.23.4 Colaboraciones
 Un ConcreteIterator sigue la pista del objeto actual en el agregado y puede calcular
el objeto siguiente en la travesia

1.24 Mediator
Define un objeto que encapsula la forma en que un conjunto de objetos interactúa. El
mediador promueve el acoplamiento suelto evitando que los objetos se refieran a otros
explícitamente, y permite variar su interacción de forma independiente.

40
1.24.1 Aplicabilidad
 Utilice el patrón del Mediador cuando
 un conjunto de objetos se comunica de forma bien definida pero compleja. Las
interdependencias resultantes no están estructuradas y son difíciles de entender.
 La reutilización de un objeto es difícil porque se refiere y se comunica con muchos
otros objetos.
 un comportamiento que está distribuido entre varias clases debería ser
personalizable sin muchas subclases.

1.24.2 Estructura

Ilustración 24 Estructura de Mediator

Una estructura de objeto típica podría verse así:

1.24.3 Participantes
Mediador (DialogDirector)
 define una interfaz para comunicarse con los objetos del colega.
41
ConcreteMediator (FontDialogDirector)
 implementa un comportamiento cooperativo coordinando los objetos de los colegas.
 conoce y mantiene a sus colegas.
Colleague classes (ListBox, EntryField)
 cada clase de colegas conoce su objeto mediador.
 cada colega se comunica con su mediador siempre que de otra manera se hubiera
comunicado con otro colega.

1.24.4 Colaboraciones
 Los Colleagues envían y reciben solicitudes de un objeto mediador. Themediator
implementa el comportamiento cooperativo encauzando las solicitudes entre los
colleagues apropiados.

1.25 Memento
Sin violar la encapsulación, capturar y externalizar el estado sinterno de un objeto para
que el objeto pueda ser restaurado a este estado más tarde, también conocido como
Token.

1.25.1 Aplicabilidad
 Use el patrón de Memento cuando
 una instantánea de (alguna porción de) el estado de un objeto debe ser guardada
para que pueda ser restaurada a ese estado más tarde, y
 una interfaz directa para obtener el estado expondría los detalles de la
implementación y rompería el encapsulamiento del objeto.

1.25.2 Estructura

42
1.25.3 Participantes
Memento (SolverState)
 almacena el estado interno del objeto del Creador. El recuerdo puede almacenar
tanto o tan poco del estado interno del originador como sea necesario a discreción
del mismo.
 protege contra el acceso de otros objetos que no sean el originador. Los recuerdos
tienen efectivamente dos interfaces. Caretaker ve una estrecha interfaz con el
Memento- sólo puede pasar el memento a otros objetos. Originator, en cambio, ve
una interfaz amplia, una que le permite acceder a todos los datos necesarios para
restaurarse a su estado anterior. Lo ideal sería que sólo el originator que produjo el
memento pudiera acceder al estado interno del mismo.
Originator (ConstraintSolver)
 crea un memento que contiene una instantánea de su estado interno actual.
 utiliza el memento para restaurar su estado interno.
Caretaker (undo mechanism)
 es responsable de la safekeeping del recuerdo.
 Nunca opera o examina el contenido de un memento.

1.25.4 Colaboraciones
 Un caretaker solicita un recuerdo de un originator, lo retiene durante un tiempo y se
lo devuelve al originator, como ilustra el siguiente diagrama de interacción:

43
  Ilustración
A veces 26 Diagramano
el caretaker de Memento
le pasa el memento al originator, porque el originator puede
que nunca necesite volver a un estado anterior.
 Los mementos son pasivos. Sólo el originator que creó un memento asignará o
recuperará su estado.

1.26 Observer
Definir una dependencia de uno a muchos entre los objetos para que cuando un objeto
cambie de estado, todos sus dependientes sean notificados y actualizados
automáticamente, también es conocido como: Dependents, publish-Subscribe

1.26.1 Aplicabilidad
 Utilice el patrón del Observador en cualquiera de las siguientes situaciones:
 Cuando una abstracción tiene dos aspectos, uno dependiente del otro. Encapsular
estos aspectos en objetos separados permite variar y reutilizarlos
independientemente.
 Cuando un cambio en un objeto requiere cambiar otros, y no se sabe cuántos
objetos necesitan ser cambiados.
 Cuando un objeto debe ser capaz de notificar a otros objetos sin hacer
suposiciones sobre quiénes son estos objetos. En otras palabras, no quieres que
estos objetos estén bien acoplados.

44
1.26.2 Estructura

Ilustración 27 Estructura de Observer

1.26.3 Participantes
Subject
 conoce a sus observers. Cualquier número de objetos observers puede observar a
un sujeto.
 proporciona una interfaz para acoplar y desacoplar los objetos observers.
Observer
 define una interfaz de actualización para los objetos que deben ser notificados de
los cambios en un tema.
ConcreteSubject
 almacena el estado de interés de los objetos de ConcreteObserver.
 envía una notificación a sus Observers cuando su estado cambia.
ConcreteObserver
 mantiene una referencia a un objeto de ConcreteSubject.
 almacena un estado que debe ser consistente con el del sujeto.
 implementa la interfaz de actualización del Observer para mantener su estado
consistente con el del sujeto.

1.26.4 Colaboraciones
 ConcreteSubject notifica a sus observers cuando se produce un cambio que podría
hacer que el estado de sus observers sea incompatible con el suyo.

45
  Después de ser informado de un cambio en el concrete subject, un
objetoConcreteObserver puede consultar al sujeto para obtener información.
ConcreteObserver utiliza esta información para conciliar su estado con el del sujeto.
El siguiente diagrama de interacción ilustra la colaboración entre un sujeto y dos
observers:

Ilustración 28 Diagrama de Observer

Obsérvese cómo el objeto Observer que inicia la solicitud de cambio aplaza su
actualización hasta que recibe una notificación del sujeto. El sujeto no siempre llama a la
Notify. Puede ser llamado por un observer o por otro tipo de objeto completamente. En la
sección de Implementación se discuten algunas variaciones comunes.

1.27 State
Permitir que un objeto altere su comportamiento cuando su estado interno cambie. El
objeto aparecerá para cambiar su clase, también es conocido como: Objects for States

1.27.1 Aplicabilidad
Utilice la pauta del Estado en cualquiera de los siguientes casos:
 El comportamiento de un objeto depende de su estado, y debe cambiar su
comportamiento en tiempo de ejecución dependiendo de ese estado.
 Las operaciones tienen grandes declaraciones condicionales multipartes que
dependen del estado del objeto. Este estado suele estar representado por una o
más constantes numeradas. A menudo, varias operaciones contienen esta misma
estructura condicional. El patrón de estado pone cada rama del condicional en una
clase separada. Esto permite tratar el estado del objeto como un objeto en su
propio derecho que puede variar independientemente de otros objetos.

46
1.27.2 Structura

Ilustración 29 Estructura de State

1.27.3 Participantes
Context (TCPConnection)
 define la interfaz de interés para los clientes.
 mantiene una instancia de una subclase de ConcreteState que define el estado
actual.
State (TCPState)
 define una interfaz para encapsular el comportamiento asociado al estado
aparticular del Contexto.
ConcreteState subclasses (TCPEstablished, TCPListen, TCPClosed)
 cada subclase implementa un comportamiento asociado a un estado del contexto.

1.27.4 Colaboraciones
 El contexto delega las peticiones específicas de estado al actual ObjetoEstado
Concreto.
 El contexto puede pasar como un argumento para el Estado objeto de la solicitud.
Esto permite al Estado objeto acceder al contexto si es necesario.
 El contexto es la interfaz principal para los clientes. Los clientes pueden configurar
acontext con los objetos State. Una vez configurado un contexto, sus clientes no
tienen que tratar directamente con los objetos de Estado.

47
  Tanto el contexto como las subclases de ConcreteState pueden decidir qué estados
superan a otros y bajo qué circunstancias.

1.28 Strategy
Definir una familia de algoritmos, encapsular cada uno, y hacerlos intercambiables. La
estrategia permite que el algoritmo varíe independientemente de los clientes que lo
utilizan, también es conocido como Policy

1.28.1 Aplicabilidad
Utilice el patrón de la Estrategia cuando
 muchas clases relacionadas sólo difieren en su comportamiento. Las estrategias
proveen una forma de configurar una clase con uno de los muchos
comportamientos.
 necesitas diferentes variantes de un algoritmo. Por ejemplo, puedes definir
algoritmos que reflejen diferentes equilibrios espacio/tiempo. Las estrategias
pueden usarse cuando estas variantes se implementan como una jerarquía de
clases de algoritmos
 un algoritmo utiliza datos que los clientes no deberían conocer. Utilice el patrón de
la Estrategia para evitar exponer estructuras de datos complejas y específicas del
algoritmo.
 una clase define muchos comportamientos, y estos aparecen como afirmaciones
multicondicionales en sus operaciones. En lugar de muchos condicionales, mueve
las ramas condicionales relacionadas a su propia clase de Estrategia.

48
1.28.2 Estructura

Ilustración 30 Estructura de Strategy

1.28.3 Participantes
Strategy (Compositor)
 declara una interfaz común a todos los algoritmos soportados. Context utiliza esta
interfaz para llamar al algoritmo definido por una ConcreteStrategy.
ConcreteStrategy (SimpleCompositor, TeXCompositor,ArrayCompositor)
 implementa el algoritmo usando la interfaz de Estrategia.
Context (Composition)
 está configurado con un objeto de ConcreteStrategy.
 Mantiene una referencia a un objeto de Strategy.puede definir una interfaz que
permite a la Strategy acceder a sus datos.

1.28.4 Colaboraciones
 La estrategia y el contexto interactúan para implementar el algoritmo elegido. El
contexto puede pasar todos los datos requeridos por el algoritmo a la estrategia
cuando el algoritmo es llamado. Alternativamente, el contexto puede pasarse como
argumento a las operaciones de la estrategia. Esto permite a la estrategia llamar al
contexto según sea necesario.

49
  Un contexto reenvía las peticiones de sus clientes a su estrategia. Los clientes
suelen crear y pasar un objeto de Estrategia Concreta al contexto; a partir de
entonces, los clientes interactúan con el contexto exclusivamente. A menudo hay
una familia de clases de Estrategia Concreta para que el cliente elija.

1.29 Template Method

Definir el esqueleto de un algoritmo en una operación, difiriendo algunos pasos a
subclases. El método de plantillas permite a las subclases redefinir los pasos de un
algoritmo sin cambiar la estructura del mismo.

1.29.1 Aplicabilidad
Se debe utilizar el patrón del método de la plantilla
 para implementar las partes invariantes de un algoritmo una vez y dejar que las
subclases implementen el comportamiento que puede variar.
 cuando el comportamiento común entre las subclases debe ser factorizado y
localizado en una clase común para evitar la duplicación de código Este es un buen
ejemplo de "refactorización para generalizar". Primero se identifican las diferencias
en el código existente y luego se separan las diferencias en nuevas operaciones.
Finalmente, se reemplaza el código que difiere con un método de plantilla que llama
a una de estas nuevas operaciones.
 para controlar las extensiones de las subclases. Se puede definir un método de
plantilla que llame a operaciones "hook" (véase Consecuencias) en puntos
específicos, permitiendo así extensiones sólo en esos puntos.

50
1.29.2 Estructura

Ilustración 31 Estructura de Template Method

1.29.3 Participantes
AbstractClass (Application)
 define operaciones primitivas abstractas que las subclases concretas definen para
implementar los pasos de un algoritmo.
 implementa un método de plantilla que define el esqueleto de un algoritmo. El
método de plantilla llama operaciones primitivas, así como operaciones definidas en
AbstractClass o las de otros objetos.
ConcreteClass (MyApplication)
 implementa las operaciones primitivas para llevar a cabo los pasos específicos de
subclase del algoritmo.

1.29.4 Colaboraciones
 ConcreteClass se basa en AbstractClass para implementar los pasos invariables
del algoritmo.

1.30 Visitor
Representan una operación a realizar en los elementos de una estructura de objeto. El
visitante permite definir una nueva operación sin cambiar las clases de los elementos
sobre los que opera.
51
1.30.1 Aplicabilidad
Use el patrón del Visitante cuando
 una estructura de objeto contiene muchas clases de objetos con diferentes
interfaces, y usted quiere realizar operaciones en estos objetos que dependen de
sus clases concretas.
 muchas operaciones distintas y no relacionadas deben ser realizadas en objetos en
una estructura de objeto, y usted quiere evitar "contaminar" sus clases con estas
operaciones. Visitor te permite mantener juntas las operaciones relacionadas
definiéndolas en una clase. Cuando la estructura de objeto es compartida por
muchas aplicaciones, utilice Visitor para poner las operaciones en sólo aquellas
aplicaciones que las necesitan.
 las clases que definen la estructura de objeto raramente cambian, pero a menudo
quieres definir nuevas operaciones sobre la estructura. Cambiar las clases de la
estructura de los objetos requiere redefinir la interfaz para todos los visitantes, lo
cual es potencialmente costoso. Si las clases de estructura de objeto cambian a
menudo, entonces es probablemente mejor definir las operaciones en esas clases.

1.30.2 Estructura

52

Ilustración 32 Estructura de Visitor

1.30.3 Participantes
Visitor (NodeVisitor)
 declara una operación de Visit para cada clase de elemento de ConcreteElement en
la estructura del objeto. El nombre y la firma de la operación identifica la clase que
envía la solicitud de visit al visitor. Eso le permite al visitante determinar la clase
concreta del elemento que está siendo visitado. Luego el visitor puede acceder al
elemento directamente a través de su interfaz particular.
ConcreteVisitor (TypeCheckingVisitor)
 implementa cada operación declarada por el Visitor. Cada operación implementa un
fragmento del algoritmo definido para la clase de objeto correspondiente en la
estructura.
ConcreteVisitor
 proporciona el contexto para el algoritmo y almacena su estado local. Este estado a
menudo acumula los resultados durante el recorrido de la estructura.
Element (Node)
 define una operación de aceptación que toma un visitor como argumento.
ConcreteElement (AssignmentNode,VariableRefNode)
 implementa una operación de aceptación que toma a un visitor como argumento.
ObjectStructure (Program)
 puede enumerar sus elementos.

53
  puede proporcionar una interfaz de alto nivel para permitir al visitante visitar sus
elementos.
 puede ser un compuesto o una colección como una lista o un conjunto.

1.30.4 Colaboraciones
 Un cliente que utiliza el patrón del Visitor debe crear un ConcreteVisitorobject y
luego atravesar la estructura del objeto, visitando cada elemento con el visitor.
 Cuando un elemento es visitado, llama a la operación Visitor que corresponde a su
clase. El elemento se suministra como argumento a esta operación para permitir al
visitor acceder a su estado, si es necesario.
El siguiente diagrama de interacción ilustra las colaboraciones entre una estructura de
objeto, un visitor y dos elementos:

Ilustración 33 Diagrama de Visitor

54
CAPÍTULO III. METODOLOGÍA DE LA INVESTIGACIÓN

55
2 CAPÍTULO III. METODOLOGÍA DE LA INVESTIGACIÓN
2.1 Tipo de Investigación
La investigación que se desarrolló en el presente documento es de tipo descriptivo. En el
cual se recolecto información del libro Patterns Design de The Gang of Four (GoF). Para
que este contribuya a la solución de la necesidad que existe de este manual.

Según el libro Proceso de Investigación Científica, la investigación descriptiva “comprende

la descripción, registro, análisis e interpretación de la naturaleza actual, y la composición o
proceso de los fenómenos. El enfoque se hace sobre conclusiones dominantes o sobre
grupos de personas, grupo o cosas, se conduce o funciona en presente”.[CITATION
Mar17 \p 46 \l 3082 ]
Los estudios descriptivos buscan especificar las propiedades importantes de personas,
grupos, -comunidades o cualquier otro fenómeno que sea sometido a análisis. Miden y
evalúan diversos aspectos, dimensiones o componentes del fenómeno o fenómenos a
investigar. Desde el punto de vista científico, describir es medir. Esto es, en un estudio
descriptivo se selecciona una serie de cuestiones y se mide cada una de ellas
independientemente, para así -y valga la redundancia- describir lo que se investiga.
[ CITATION Her97 \l 3082 ]

2.2 Unidad de Análisis

La unidad de análisis son los Patrones de Diseño según el Libro The Gang of Four (GoF).

56
2.3 Variables y su medición
Tabla 2 Variables y su Medición

Unidad de variables indicadores Instrumento de Técnica a

análisis medición aplicar

Tiempo,
uso de memoria
funcionabilidad utilizada por Lista de cotejo Observación
patrón

Ejecución del
Patrones de Proceso,
diseño The Eficacia Rendimiento de Lista de cotejo Observación
Gang of Four los recursos
utilizados por los
patrones
Precisión y
exactitud de los
Datos y
Fiabilidad Representatividad Lista de cotejo Observación
para el
Programador

Tabla 3 Variables y su Medición

Fuente: Propia

Variables Definición Conceptual Definición Operacional

Conjunto de características
Funcionalidad que hacen que algo sea
practico y utilitario
Miden el nivel de ejecución
del proceso se concentra
Se refiere a la aplicabilidad
del patrón a la hora de
ejecutarlo
Miden el rendimiento de los
57
Eficacia en el cómo se hicieron las procesos utilizados
cosas. Tienen que ver con
la productividad
Probabilidad de que una Probabilidad de un
Fiabilidad cosa funcione bien o sea funcionamiento correcto sin
segura fallo alguno de un
determinado periodo de
tiempo

58