Patrones

Patrones de desarrollo: Gang of Four (GoF)
Sergio Peralta
Octubre 2019.
Politécnico GranColombiano.
Bogotá.
Ing. De Software II
ii
Abstract
Lo patrones de desarrollo nos permiten a los desarrolladores de software hallar una solución a un
problema que tengamos al momento de programar, son patrones documentados que tienen un
problema específico al que hallaron solución con este procedimiento, existen varios tipos de
patrones, sin embargo nos centraremos en los que son orientados a Desarrollo Web, más
específicamente en los Patrones Gof. Que permite la solución a problemas en las clases de un
programa o permite la reutilización de diseños y arquitecturas software que han tenido éxito
capturando la experiencia y haciéndola accesible a los no expertos. Y se destacarán 3 tipos de
patrones, los Patrones de creación, los Patrones estructurales y los Patrones de comportamiento.
Patrones de Desarrollo
Tabla de Contenidos iii
Patrones de creación ..........................................................Error! Bookmark not defined.

Abstract Factory ............................................................ Error! Bookmark not defined.
Builder............................................................................................................................. 2
Factory Method ............................................................................................................... 2
Prototype ......................................................................................................................... 3
Singleton ......................................................................................................................... 4
Patrones estructurales.......................................................................................................... 5
Adapter ............................................................................................................................ 5
Bridge. ............................................................................................................................. 5
Composite. ...................................................................................................................... 6
Decorator......................................................................................................................... 7
Facade ............................................................................................................................. 7
Flyweight. ....................................................................................................................... 8
Proxy ............................................................................................................................... 9
Patrones de comportamiento. .............................................................................................. 9
Chain of Responsibility................................................................................................... 9
Command ...................................................................................................................... 10
Interpreter ...................................................................................................................... 11
Iterator ........................................................................................................................... 11
Mediator ........................................................................................................................ 12
Memento ....................................................................................................................... 13
Observer ........................................................................................................................ 14
State............................................................................................................................... 14
Strategy ......................................................................................................................... 15
Template Method .......................................................................................................... 16
Visitor ........................................................................................................................... 17
Resultados y discusión. ..................................................................................................... 18
Lista de figuras iv
Figura 1. Diagrama de clases, Abstract Factory. ........................................................................... 1

Figura 2. Diagrama de clases, Builder. .......................................................................................... 2
Figura 3. Diagrama de clases, Factory Method. ............................................................................ 3
Figura 4. Diagrama de clases, Prototype. .....................................Error! Bookmark not defined.
Figura 5. Fragmento de código Java de implementación Singleton. ........... Error! Bookmark not
defined.
Figura 6. Diagrama de clases, Adapter. ......................................................................................... 5
Figura 7. Diagrama de clases, Composite. ..................................................................................... 6
Figura 8. Diagrama de clases, Decorator. . ................................................................................... 7
Figura 9. Diagrama de clases, Facade. .......................................................................................... 8
Figura 10. Diagrama de clases, Flyweight. .................................................................................... 8
Figura 11. Diagrama de clases, Proxy............................................................................................ 9
Figura 12. Diagrama de clases, Chain of Responsibility.............................................................. 10
Figura 13. Diagrama de clases, Command ................................................................................... 10
Figura 14. Diagrama de clases, Interpreter.................................................................................. 11
Figura 15. Diagrama de clases, Iterator. ...................................................................................... 12
Figura 16. Diagrama de clases, Mediator. ................................................................................... 13
Figura 17. Diagrama de clases, Memento. ................................................................................... 13
Figura 18. Diagrama de clases, State. .........................................1Error! Bookmark not defined.
Figura 19. Diagrama de clases, Strategy. ..................................................................................... 15
Figura 20. Diagrama de clases, Template Method. ...................................................................... 16
Figura 22. Diagrama de clases, Visitor. ....................................................................................... 17
1
Patrones de Creación:
Tratan de la inicialización y configuración de clases y objetos
Abstract Factory:
Busca agrupar un conjunto de clases que tiene un funcionamiento en común
llamadas familias, las cuales son creadas mediante un Factory.
El problema que intenta solucionar este patrón es el de crear diferentes familias de
objetos. Y está aconsejado cuando se prevé la inclusión de nuevas familias de productos,
pero puede resultar contraproducente cuando se añaden nuevos productos o cambian los
existentes, puesto que afectaría a todas las familias creadas.
decorator
2
Builder:
Es usado para permitir la creación de una variedad de objetos complejos desde un
objeto fuente. Separa la construcción de un objeto complejo de su representación, de
forma que el mismo proceso de construcción pueda crear diferentes representaciones.
Un único proceso de construcción debe ser capaz de construir distintos objetos
complejos, abstrayéndonos de los detalles particulares de cada uno de los tipos. La
solución será crear un constructor que permita construir todos los tipos de objetos,
ayudándose de constructores concretos encargados de la creación de cada tipo en
particular. Un objeto director será el encargado de coordinar y ofrecer los resultados.
Figura 2. Diagrama de clases, Builder
Factory Method:
Define una interfaz para crear un objeto, pero deja que sean las subclases quienes
decidan qué clase instanciar. Permite que una clase delegue en sus subclases la creación
de objetos.
3
Una clase no puede anticipar el tipo de objetos que debe crear, ya que la jerarquía
de clases que tiene requiere que deba delegar la responsabilidad a una subclase.
Figura 3. Diagrama de clases, Factory Method
Prototype:
Especifica los tipos de objetos a crear por medio de una instancia prototípica, y
crear nuevos objetos copiando este prototipo.
Modo de clonar un objeto cuya creación normal supone un alto coste. En este
caso veremos cómo hacer una caché de objetos creados mediante acceso simulado a base
de datos.
4
Figura 4. Diagrama de clases, Prototype
Singleton:
Garantiza que una clase sólo tenga una instancia, y proporciona un punto de
acceso global a ella, es un patrón de diseño que permite restringir la creación de objetos
pertenecientes a una clase o el valor de un tipo a un único objeto.
Su intención consiste en garantizar que una clase solo tenga una instancia y
proporcionar un punto de acceso global a ella. Asegurar que una clase no pueda ser
instanciada nuevamente.
Figura 5. Fragmento de código Java de implementación Singleton

5
Patrones estructurales
Tratan de desacoplar interfaz e implementación de clases y objetos.
Adapter:
Convierte la interfaz de una clase en otra distinta que es la que esperan los
clientes. Permiten que cooperen clases que de otra manera no podrían por tener interfaces
incompatibles.
Convierte la interfaz de una clase en otra interfaz que el cliente espera. El
adaptador permite a las clases trabajar juntas, lo que de otra manera no podría hacerse
debido a sus interfaces incompatibles.
Figura 6. Diagrama de clases, Adapter
Bridge:
Desvincula una abstracción de su implementación, de manera que ambas puedan
variar de forma independiente.
Cuando una clase varía a menudo, las características de la programación orientada
a objetos se vuelven muy útiles debido a que los cambios en el código de un programa
pueden hacerse fácilmente con un mínimo conocimiento previo sobre el programa.
6
El patrón bridge se confunde a menudo con el patrón adapter. De hecho, el patrón
bridge a menudo se implementa utilizando el patrón de adapter.
Composite:
Combina objetos en estructuras de árbol para representar jerarquías de parte-todo.
Permite que los clientes traten de manera uniforme a los objetos individuales y a los
compuestos.
Esto simplifica el tratamiento de los objetos creados, ya que al poseer todos ellos
una interfaz común, se tratan todos de la misma manera. Dependiendo de la
implementación, pueden aplicarse procedimientos al total o una de las partes de la
estructura compuesta como si de un nodo final se tratara, aunque dicha parte esté
compuesta a su vez de muchas otras.
Figura 7. Diagrama de clases, Composite
7
Decorator:
Añade dinámicamente nuevas responsabilidades a un objeto, proporcionando una
alternativa flexible a la herencia para extender la funcionalidad.
Extiende la funcionalidad de un objeto en forma dinámica, proporcionando una
alternativa flexible a la creación de subclases.
Figura 8. Diagrama de clases, Decorator
Facade:
Proporciona una interfaz unificada para un conjunto de interfaces de un
subsistema. Define una interfaz de alto nivel que hace que el subsistema sea más fácil de
usar. Busca reducir al mínimo la comunicación y dependencias entre subsistemas,
simplificando la complejidad al cliente.
8
Figura 9. Diagrama de clases, Facade
Flyweight:
Usa el compartimiento para permitir un gran número de objetos de grano fino de
forma eficiente.
Un objeto flyweight es un objeto compartido que puede ser utilizado en múltiples
contextos simultáneamente. Este objeto actúa como un objeto independiente en cada
contexto, flyweight no puede hacer suposiciones sobre el contexto en el que opera. El
concepto clave aquí es la distinción entre el estado intrínseco y extrínseco.
Figura 10. Diagrama de clases, Flyweight
9
Proxy:
Proporciona un sustituto o representante de otro objeto para controlar el acceso a
éste.
El patrón Proxy nos dice que construyamos una nueva clase proxy con la misma
interfaz que tiene la clase original. Luego en vez de utilizar la clase original, utilizamos la
clase proxy en todos los clientes que antes usaban la clase original. La clase proxy agrega
la funcionalidad deseada y luego delega el acceso a la clase original.
Figura 11. Diagrama de clases, Proxy
Patrones de comportamiento
Tratan de las interacciones dinámicas entre sociedades de clases y objetos
Chain of Responsibility:
Evita acoplar el emisor de una petición a su receptor, al dar a más de un objeto la
posibilidad de responder a la petición. Crea una cadena con los objetos receptores y pasa
la petición a través de la cadena hasta que esta sea tratada por algún objeto. Cualquiera de
los objetos receptores puede responder a la petición en función de un criterio establecido.
10
Se utiliza, por ejemplo, cuando en función del estado del sistema las peticiones
emitidas por un objeto deben ser atendidas por distintos objetos receptores.
Figura 12. Diagrama de clases, Chain of Responsibility
Command:
Encapsula una petición en un objeto, permitiendo así parametrizar a los clientes
con distintas peticiones, encolar o llevar un registro de las peticiones y poder deshacer la
operaciones.
Solicita una operación a un objeto sin conocer realmente el contenido de esta
operación, ni el receptor real de la misma. Para ello se encapsula la petición como un
objeto, con lo que además facilita la parametrización de los métodos.
Figura 13. Diagrama de clases, Command

11
Interpreter:
Dado un lenguaje, define una representación de su gramática junto con un
intérprete que usa dicha representación para interpretar las sentencias del lenguaje.
Se usa para definir un lenguaje para representar expresiones regulares que
representen cadenas a buscar dentro de otras cadenas. Además, en general, para definir un
lenguaje que permita representar las distintas instancias de una familia de problemas.
Figura 14. Diagrama de clases, Interpreter
Iterator:
Proporciona un modo de acceder secuencialmente a los elementos de un objeto
agregado sin exponer su representación interna.
El patrón Iterador es un mecanismo de acceso a los elementos que constituyen
una estructura de datos para la utilización de estos sin exponer su estructura interna.
12
El patrón surge del deseo de acceder a los elementos de un contenedor de objetos
(por ejemplo, una lista) sin exponer su representación interna. Además, es posible que se
necesite más de una forma de recorrer la estructura siendo para ello necesario crear
modificaciones en la clase.
Figura 15. Diagrama de clases, Iterator
Mediator:
Define un objeto que encapsula cómo interactúan un conjunto de objetos.
Promueve un bajo acoplamiento al evitar que los objetos se refieran unos a otros
explícitamente, y permite variar la interacción entre ellos de forma independiente.
Es un patrón de comportamiento que permite crear interacciones entre objetos
reduciendo un excesivo acoplamiento.
El patrón mediador define un objeto que encapsula cómo un conjunto de objetos
interactúan. Este patrón de diseño está considerado como un patrón de comportamiento
debido al hecho de que puede alterar el comportamiento del programa en ejecución.
13
Figura 16. Diagrama de clases, Mediator
Memento:
Representa y externaliza el estado interno de un objeto sin violar la
encapsulación, de forma que éste puede volver a dicho estado más tarde.
Almacena el estado de un objeto en un momento dado de manera que se pueda
restaurar en ese punto de manera sencilla. Para ello se mantiene almacenado el estado del
objeto para un instante de tiempo en una clase independiente de aquella a la que
pertenece el objeto, de forma que ese recuerdo permita que el objeto sea modificado y
pueda volver a su estado anterior.
Figura 17. Diagrama de clases, Memento
14
Observer:
Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un
objeto cambia de estado se notifica y actualizan automáticamente todos los objetos.
Se trata de un patrón de comportamiento (existen de tres tipos: creación,
estructurales y de comportamiento), por lo que está relacionado con algoritmos de
funcionamiento y asignación de responsabilidades a clases y objetos
State:
Permite que un objeto modifique su comportamiento cada vez que cambia su
estado interno. Parecerá que cambia la clase del objeto.
Figura 18. Diagrama de clases, State
15
Strategy:
Define una familia de algoritmos, encapsula uno de ellos y los hace
intercambiables. Permite que un algoritmo varíe independientemente de los clientes que
lo usan.
El caso de uso más común es el de cambiar el comportamiento de una clase en
tiempo de ejecución, es decir, poder elegir qué algoritmo, entre un subconjunto posible,
es el que hay que aplicar en ese momento.
Para ello se crean objetos que representan las distintas estrategias existentes para
el comportamiento definido, y un objeto de contexto cuyo comportamiento varía en base
a las distintas estrategias. Es muy importante que los algoritmos definidos en cada
estrategia sean totalmente independientes.
Figura 19. Diagrama de clases, Strategy
16
Template Method:
Define en una operación el esqueleto de un algoritmo, delegando en las subclases
algunos de sus pasos. Permite que las subclases redefinan ciertos pasos del algoritmo sin
cambiar su estructura.
Permite redefinir ciertos pasos seguros de un algoritmo sin cambiar la estructura
del algoritmo. Dejar que las subclases que se implementan (a través del método
primordial) tengan un comportamiento que puede variar y evitar duplicación en el
código: la estructura general de flujo de trabajo, está implementada una vez en el
algoritmo de clase abstracta, y variaciones necesarias son implementadas en cada de las
subclases.
Figura 20. Diagrama de clases, Template Method
17
Visitor:
Representa una operación sobre los elementos de una estructura de objetos.
Permite definir una nueva operación sin cambiar las clases de los elementos sobre los que
opera.
Permite definir una operación sobre objetos de una jerarquía de clases sin
modificar las clases sobre las que opera. Representa una operación que se realiza sobre
los elementos que conforman la estructura de un objeto.
Figura 21. Diagrama de clases, Visitor
18
Resultados y discusión.
Desde el punto de vista en mi experiencia al realizar la investigación del
documento me pude dar cuenta de todos los patrones que pueden existir, no solo
para la programación como tal, si no, para la arquitectura de un software por
ejemplo. Además de que cada tipo de patrón está buscando la solución a un
problema en específico, que ya solucionó en el pasado, los patrones son bastante
útiles para poder agilizar, optimizar, y brindar posibilidades de éxito a un producto
de software.

Patrones

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Patrones

Cargado por

Copyright:

Formatos disponibles

Patrones de desarrollo: Gang of Four (GoF)

capturando la experiencia y haciéndola accesible a los no expertos. Y se destacarán 3 tipos de

Patrones de creación ..........................................................Error! Bookmark not defined.

Figura 1. Diagrama de clases, Abstract Factory. ........................................................................... 1

Tratan de la inicialización y configuración de clases y objetos

Busca agrupar un conjunto de clases que tiene un funcionamiento en común

llamadas familias, las cuales son creadas mediante un Factory.

El problema que intenta solucionar este patrón es el de crear diferentes familias de

objetos. Y está aconsejado cuando se prevé la inclusión de nuevas familias de productos,

existentes, puesto que afectaría a todas las familias creadas.

Es usado para permitir la creación de una variedad de objetos complejos desde un

objeto fuente. Separa la construcción de un objeto complejo de su representación, de

forma que el mismo proceso de construcción pueda crear diferentes representaciones.

Un único proceso de construcción debe ser capaz de construir distintos objetos

complejos, abstrayéndonos de los detalles particulares de cada uno de los tipos. La

ayudándose de constructores concretos encargados de la creación de cada tipo en

particular. Un objeto director será el encargado de coordinar y ofrecer los resultados.

Figura 2. Diagrama de clases, Builder

Figura 3. Diagrama de clases, Factory Method

crear nuevos objetos copiando este prototipo.

Figura 4. Diagrama de clases, Prototype

pertenecientes a una clase o el valor de un tipo a un único objeto.

Figura 5. Fragmento de código Java de implementación Singleton

Tratan de desacoplar interfaz e implementación de clases y objetos.

Convierte la interfaz de una clase en otra interfaz que el cliente espera. El

debido a sus interfaces incompatibles.

Figura 6. Diagrama de clases, Adapter

Desvincula una abstracción de su implementación, de manera que ambas puedan

variar de forma independiente.

Cuando una clase varía a menudo, las características de la programación orientada

pueden hacerse fácilmente con un mínimo conocimiento previo sobre el programa.

El patrón bridge se confunde a menudo con el patrón adapter. De hecho, el patrón

bridge a menudo se implementa utilizando el patrón de adapter.

Combina objetos en estructuras de árbol para representar jerarquías de parte-todo.

una interfaz común, se tratan todos de la misma manera. Dependiendo de la

implementación, pueden aplicarse procedimientos al total o una de las partes de la

compuesta a su vez de muchas otras.

Figura 7. Diagrama de clases, Composite

Añade dinámicamente nuevas responsabilidades a un objeto, proporcionando una

alternativa flexible a la herencia para extender la funcionalidad.

Extiende la funcionalidad de un objeto en forma dinámica, proporcionando una

alternativa flexible a la creación de subclases.

Figura 8. Diagrama de clases, Decorator

Proporciona una interfaz unificada para un conjunto de interfaces de un

usar. Busca reducir al mínimo la comunicación y dependencias entre subsistemas,

simplificando la complejidad al cliente.

Figura 9. Diagrama de clases, Facade

Usa el compartimiento para permitir un gran número de objetos de grano fino de

Un objeto flyweight es un objeto compartido que puede ser utilizado en múltiples

contextos simultáneamente. Este objeto actúa como un objeto independiente en cada

contexto, flyweight no puede hacer suposiciones sobre el contexto en el que opera. El

concepto clave aquí es la distinción entre el estado intrínseco y extrínseco.

Figura 10. Diagrama de clases, Flyweight

Proporciona un sustituto o representante de otro objeto para controlar el acceso a

la funcionalidad deseada y luego delega el acceso a la clase original.

Figura 11. Diagrama de clases, Proxy

Tratan de las interacciones dinámicas entre sociedades de clases y objetos

Evita acoplar el emisor de una petición a su receptor, al dar a más de un objeto la

los objetos receptores puede responder a la petición en función de un criterio establecido.

Figura 12. Diagrama de clases, Chain of Responsibility

Encapsula una petición en un objeto, permitiendo así parametrizar a los clientes

Solicita una operación a un objeto sin conocer realmente el contenido de esta

operación, ni el receptor real de la misma. Para ello se encapsula la petición como un

objeto, con lo que además facilita la parametrización de los métodos.