“MADRE DE DIOS CAPITAL DE LA BIODIVERISDAD DEL PERU”

FACULTAD DE INGENIERIA

INGENIERIA DE SISTEMAS
E INFORMATICA

 DOCENTE: ING. LUIS A. HOLGADO APAZA

 CURSO: DESARROLLO AVANZADO DE

SOLUCIONES EN SOFTWARE LIBRE

 ALUMNO: JEFFERSON MORALES ZAVALETA

 MONOGRAFIA: PATRONES DE DISEÑO

SEMESTRE : 2018-I

“Ingeniería de Sistemas e Informática

Desafiando al Tiempo y Construyendo el Futuro”
 ÍNDICE DE CONTENIDOS

1. Definiciones…………………………..………………………………………..…..3
2. Características de un Patrón…...………………………………….…………...4
3. Objetivos…………………...……………………………………………………....4
4. Anti-Patrones………………………………………………………………….…...5
5. Categorías de Patrón…..……………………………………………..................5
6. Clasificación de los Patrones………………………………………………......5
6.1. Patrones Creacionales…….……………………………………….…..6
6.2. Patrones Estructurales...….…………………………………….……10
6.2.1. Otros Patrones Estructurales………….………………….12
6.3. Patrones de Comportamiento…….…………………………….......14
6.3.1. Otros Patrones de Comportamiento……………………..17
6.4. Otros Patrones de Diseño…...…….…………………………….......20
7. Referencias Bibliográficas……………………………………………………..22
8. Índice de Ilustraciones………………………………………………………….23
9. Índice de Tablas………………………………………………………………….24
 PATRONES DE DISEÑO

1) DEFINICIONES

(Alexander, 1980) define que:

“Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno,
para luego describir la solución a ese problema, de tal manera que esa solución
pueda ser usada más de un millón de veces sin pensarlo o hacerlo siquiera dos
veces de la misma forma”

(Erich Gamma, 1994) para describir en un caso práctico, afirma que:

Los patrones de diseño son descripciones de clases cuyas instancias colaboran

entre sí. Cada patrón es adecuado para ser adaptado a un cierto tipo de problema.

En general un patrón de diseño es un esquema de solución que se aplica a un tipo

de problema.

(Hernández, 2017) comenta que:

“Los patrones de diseño, son unos diseños básicos de clases e interfaces, aplicables a
cualquier lenguaje orientado a objetos (c++, c#, java, php, javascript, aunque este último,
lo de los objetos es muy especial), para solucionar ciertos tipos de problemas.”

(Sourcemaking, 2017) menciona que:

“Un patrón de diseño es una solución general repetible a un problema común en el diseño
de software. Un patrón de diseño no es un diseño terminado que se puede transformar
directamente en código. Es una descripción o plantilla de cómo resolver un problema que
se puede utilizar en muchas situaciones diferentes.”

(Tedeschi, 2018) declara que:

“Los patrones de diseño brindan una solución ya probada y documentada a problemas de

desarrollo de software que están sujetos a contextos similares. Debemos tener presente
los siguientes elementos de un patrón: su nombre, el problema (cuando aplicar un patrón),
la solución (descripción abstracta del problema) y las consecuencias (costos y
beneficios).”

(Wikipedia, 2018) resume que:

“Los patrones de diseño son técnicas para resolver problemas comunes en el desarrollo
de software. Un patrón de diseño resulta ser una solución a un problema de diseño.”
2) CARACTERISTICAS DE UN PATRON

(Otroblogmas, 2009) define que son tres:

Contexto: situación en la que se presenta el problema de diseño.

Problema: descripción del problema a resolver, y enumeración de las fuerzas a

equilibrar (requisitos no funcionales como eficiencia, portabilidad,
cambiabilidad).

Solución: conjunto de medidas que se han de tomar, como crear alguna clase,
atributo o método, nuevos comportamientos entre clases.

(Informaticos, 2018) lo relaciona con:

Algunas propiedades no funcionales como:

 Reutilización
 Facilidad de modificación
 Facilidad de comprensión
 Robustez
 Eficiencia
 Facilidad de uso

(Canarias, 2012) menciona que:

Otras características principales de un patrón:

 Resuelve un problema: Soluciones, no principios o estrategias abstractas.

 Describir una relación: No describen módulos, sino estructuras y mecanismos.
 La solución no es fácil de hallar o es obvia.

3) OBJETIVOS

(Wikipedia, 2018) nos dice que:

Los patrones de diseño pretenden:

Proporcionar catálogos de elementos reusables en el diseño de sistemas software.

Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y
solucionados anteriormente.
Formalizar un vocabulario común entre diseñadores.
Estandarizar el modo en que se realiza el diseño.
Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando
conocimiento ya existente.
Asimismo, no pretenden:

Imponer ciertas alternativas de diseño frente a otras.

Eliminar la creatividad inherente al proceso de diseño.

 No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el

mismo problema o similar que soluciona el patrón, siempre teniendo en cuenta
que en un caso particular puede no ser aplicable. "Abusar o forzar el uso de los
patrones puede ser un error".

4) ANTIPATRONES

(Otroblogmas, 2009) llega a la conclusión que:

“Son unos patrones de diseño que siempre dan una mala solución al problema.”

(Sourcemaking, 2018) comenta que:

“El Anti-patrón es una forma literaria que describe una solución común a un problema
que genera consecuencias decididamente negativas.”

5) CATEGORIAS DE PATRONES

(Wikipedia, 2018) dice también que según la escala o nivel de abstracción se pueden
clasificar en:

Patrones de arquitectura: Aquellos que expresan un esquema organizativo

estructural fundamental para sistemas de software.

Patrones de diseño: Aquellos que expresan esquemas para definir estructuras de

diseño (o sus relaciones) con las que construir sistemas de software.

Dialectos: Patrones de bajo nivel específicos para un lenguaje de programación o

entorno concreto.

6) CLASIFICACION DE LOS PATRONES

(Canarias, 2012) en su diapositiva de SlideShare menciona que:

Los patrones de diseño pueden clasificarse según el tipo de problema que solucionan:

Patrones Creacionales: Resuelven problemas relacionados con la creación de instancias

de objetos.

Patrones Estructurales: Se centran en problemas relacionados con la forma de

estructurar clases.
Patrones de comportamiento: Permiten resolver problemas relacionados con el
comportamiento de la aplicación, normalmente en tiempo de ejecución.

Tabla 1: Clasificación de los Patrones de Diseño en Java

De Creación Estructurales De Comportamiento

 Interpreter
 Factory  Adapter
Clase  Template
Method (De clases)
Method

 Chain of
Responsibility
 Adapter
 Comand
 Abstract  Brigde
 Iterator
Factory  Composite
 Mediator
Objeto  Builder  Decorator
 Memento
 Prototype  Facade
 Observer
 Singleton  Flyweight
 State
 Proxy
 Strategy
 Visitor

6.1) PATRONES CREACIONALES

A) ABSTRACT FACTORY: Proporciona una interfaz para crear familias de objetos o

que dependen entre sí, sin especificar sus clases concretas.

(SlideShare, 2012) afirma:

El patrón se puede aplicar cuando:

Un sistema deba ser independiente de cómo son creados, compuestos y

representados los objetos.

Un sistema deba ser configurado con una de múltiples familias de objetos.

Se quiere proporcionar una librería de objetos y sólo se quiere revelar sus

interfaces, sin revelar la implementación.
 Ilustración 1:Abstract Factory

Ilustración 1: Abstract Factory Copyright 2012 por SlideShare

B) BUILDER: 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.

(SlideShare, 2012) afirma:

El patrón se puede aplicar cuando:

El algoritmo para crear un objeto complejo debe ser independiente de las partes
que componen el objeto y cómo estos están ensamblados.

El proceso de construcción debe permitir diferentes representaciones para el

objeto construido.

Ilustración 2: Builder

Ilustración 2: Builder Copyright 2012 por SlideShare

C) 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.

(SlideShare, 2012) afirma:

El patrón se puede aplicar cuando:

Una clase no puede anticipar el tipo de objeto que ésta debe crear.

Una clase delega la responsabilidad de crear los objetos a clases ayudantes.

Ilustración 3: Factory Method

Ilustración 3: Factory Method Copyright 2012 por SlideShare

D) PROTOTYPE: Especifica los tipos de objetos a crear por medio de una instancia
prototípica, y crea nuevos objetos mediante clonación basados en una plantilla de objetos
existentes.

(SlideShare, 2012) afirma:

Este patrón puede ser utilizado cuando:

La composición, creación y representación de los objetos debe desacoplarse de un

sistema.

Las clases que se creen se especifican en tiempo de ejecución.

Para un objeto existen un numero limitado de combinaciones de estado.

Se requiere objetos o estructuras de objetos sean idénticos o se parezcan mucho a

otros objetos o estructuras existentes.

La creación inicial de cada objeto es una operación costosa.

Ilustración 4: Prototype

Ilustración 4: Prototype Copyright 2012 por SlideShare

E) SINGLETON: Garantiza que una clase sólo tenga una instancia, y proporciona un
punto de acceso global a ella.

(SlideShare, 2012) afirma:

El patrón puede utilizarse cuando:

Deba existir exactamente una instancia de una clase y ésta deba ser accesible por
los clientes desde un lugar bien conocido.

Ilustración 5: Singleton

Ilustración 5: Singleton Copyright 2012 por SlideShare

6.2) PATRONES ESTRUCTURALES

A) DECORATOR: Añade dinámicamente nuevas responsabilidades a un objeto,

proporcionando una alternativa flexible a la herencia para extender la funcionalidad.

(SlideShare, 2012) afirma:

El patrón puede usarse cuando:

Se desea añadir responsabilidades individuales a los objetos, dinámicamente y

transparentemente, sin afectar otros objetos.

Cuando la extensión por medio de subclases sea impráctica (demasiadas clases

para cada tipo de combinación).

Ilustración 6: Decorator

Ilustración 6: Decorator Copyright 2012 por SlideShare

B) 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.

(SlideShare, 2012) afirma:

El patrón puede ser usado cuando:

Se desea proporcionar una interfaz simple a un subsistema complejo.

Se desea disminuir la dependencia entre el cliente y la implementación de una

abstracción.

Se desea disminuir la dependencia entre subsistemas.

 Ilustración 7: Facade

Ilustración 7: Facade Copyright 2012 por SlideShare

C) BRIDGE: Desvincula una abstracción de su implementación, de manera que ambas

puedan variar de forma independiente.

(SlideShare, 2012) afirma:

Este patrón puede ser utilizado cuando:

Las abstracciones e implementaciones no deben ser dependientes en tiempo de

compilación.

Los cambios en la implementación no deberían tener impacto en los clientes

Los detalles de la implementación se deben ocultar al cliente.

Ilustración 8: Bridge

Ilustración 8: Bridge Copyright 2012 por SlideShare

6.2.1) OTROS PATRONES ESTRUCTURALES

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.

Ilustración 9: Adapter

Ilustración 9: Adapter Copyright 2012 por SlideShare

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.

Ilustración 10: Composite

Ilustración 10: Composite Copyright 2012 por SlideShare

FLYWEIGHT: Usa el compartimiento para manejar un gran número de objetos de alta
granularidad de forma eficiente.

Ilustración 11: Flyweight

Ilustración 11: Flyweight Copyright 2012 por SlideShare

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

a éste.

Ilustración 12: Proxy

Ilustración 12: Proxy Copyright 2012 por SlideShare

6.3) PATRONES DE COMPORTAMIENTO

A) 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.

(SlideShare, 2012) afirma:

Este patrón puede ser utilizado cuando:

Se necesita consistencia entre clases relacionadas, pero con independencia.

Los cambios de estado en uno o más objetos deben dar lugar a comportamiento
en otros objetos.

Ilustración 13: Observer

Ilustración 13: Observer Copyright 2012 por SlideShare

B) STATE: Permite que un objeto modifique su comportamiento cada vez que cambia
su estado interno. Parecerá que cambia la clase del objeto. Se utiliza cuando el
comportamiento de un objeto cambia dependiendo del estado del mismo.

Ejemplo: una alarma puede tener diferentes estados: desactivada, activada, en

configuración, etc. En este caso se puede definir una interfaz Estado_Alarma, y luego
definir los diferentes estados.

(SlideShare, 2012) afirma:

El patrón puede ser utilizado cuando:

Se permite a un objeto alterar su comportamiento según el estado interno en que

se encuentre.
 Ilustración 14: State

Ilustración 14: State Copyright 2012 por SlideShare

C) 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.

Su finalidad es almacenar el estado de un objeto (o del sistema completo) en un momento

dado de manera que se pueda restaurar en ese punto de manera sencilla.

(SlideShare, 2012) afirma:

Este patrón puede ser utilizado cuando:

El estado interno de un objeto debe ser guardado y restaurado en un momento

posterior.

El estado interno no se puede exponer mediante interfaces sin exponer la

implementación.

Ilustración 15: Memento

Ilustración 152: Memento Copyright 2012 por SlideShare

D) STRATEGY: Permite mantener un conjunto de algoritmos de entre los cuales el
objeto cliente puede elegir aquel que le conviene e intercambiarlo dinámicamente según
sus necesidades.

(SlideShare, 2012) afirma:

Este patrón puede ser utilizado cuando:

La única diferencia entre muchas clases relacionadas es su comportamiento.

Se requieren múltiples versiones de un algoritmo.

El comportamiento de una clase debe ser definido en tiempo de ejecución.

Ilustración 163: Strategy

Ilustración 16: Strategy Copyright 2012 por SlideShare

E) 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.

(SlideShare, 2012) afirma:

Este patrón puede ser utilizado cuando:

El comportamiento común entre subclases debe estar localizado en una clase

común.

Las clases padre deben ser capaces de invocar de manera uniforme en el

comportamiento de sus subclases.
 Ilustración 17: Template Method

Ilustración 17: Template Method Copyright 2012 por SlideShare

6.3.1) OTROS PATRONES DE COMPORTAMIENTO

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.

Ilustración 18: Chain Responsibility

Ilustración 18: Chain Responsibility Copyright 2012 por SlideShare

ITERATOR: Proporciona un modo de acceder secuencialmente a los elementos de un
objeto agregado sin exponer su representación interna.

Ilustración 19: Iterator

Ilustración 19: Iterator Copyright 2012 por SlideShare

COMAND: 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 las operaciones.

Ilustración 20: Comand

Ilustración 20: Comand Copyright 2012 por SlideShare

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.

Ilustración 21: Comand

Ilustración 21: Comand Copyright 2012 por SlideShare

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.

Ilustración 22: Mediator

Ilustración 22: Mediator Copyright 2012 por SlideShare

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.

Ilustración 23: Visitor

Ilustración 23: Visitor Copyright 2012 por SlideShare

6.4) OTROS PATRONES DE DISEÑO

MVC

(Alvarez, 2014) nos dice en su blog que:

Es una propuesta de diseño de software utilizada para implementar sistemas donde se

requiere el uso de interfaces de usuario. Surge de la necesidad de crear software más
robusto con un ciclo de vida más adecuado, donde se potencie la facilidad de
mantenimiento, reutilización del código y la separación de conceptos.

(Largo, 2016) menciona que:

Este patrón permite separar una aplicación en 3 capas (Modelo, Vista, Controlador), una
forma de organizar y de hacer escalable un proyecto.

EJEMPLO PRACTICO

(Largo, 2016) menciona un ejemplo:

El usuario quiere ver los clientes con apellido Álvarez, la petición va al controlador y el
se encarga de utilizar el modelo adecuado y devolver ese modelo a la vista.

Si te das cuenta en ningún momento interactúan directamente la vista con el modelo, esto
también mantiene la seguridad en una aplicación.
ESTRUCTURA DE UN PROYECTO

Ilustración 24: Estructura de un Proyecto MVC

Ilustración 25: Estructura de un Proyecto MVC Copyright 2016 por Ecodeup

DAO

(Largo, 2016) afirma que:

“Este patrón es netamente el acceso a los datos, que básicamente tiene que ver con la
gestión de diversas fuentes de datos y además abstrae la forma de acceder a ellos.”

EJEMPLO PRACTICO

(Largo, 2016) hace una suposición como:

Imagínate que tienes un sistema montado en producción con una base de datos MySQL
y de pronto lo debes cambiar a PostgreSQL o a cualquier otro motor de base de datos.

Eso puede ser un verdadero problema.

(Largo, 2016) afirma que:

Este patrón precisamente lo soluciona, al tener una aplicación que no esté ligada al acceso
a datos, que si por ejemplo la parte de la vista pide encontrar los clientes con compras
mensuales mayores $ 200, el DAO se encargue de traer esos datos independientemente si
está en un archivo o en una base de datos.
ESTRUCTURA DE UN PROYECTO

Ilustración 25: Estructura de un Proyecto DAO

Ilustración 26: Estructura de un Proyecto DAO Copyright 2016 por Ecodeup

7) REFERENCIAS BIBLIOGRÁFICAS

 Alexander, C. (1980). A Pattern Language. Gustavo Gili.

 Alvarez, M. A. (Enero de 2014). Obtenido de
https://desarrolloweb.com/articulos/que-es-mvc.html
 Canarias, I. (Octubre de 2012). Obtenido de
https://es.slideshare.net/ikercanarias/patrones-de-diseo-de-software-14836338
 Canarias, I. (Octubre de 2012). Obtenido de
https://es.slideshare.net/ikercanarias/patrones-de-diseo-de-software-14836338
 Erich Gamma, R. H. (1994). Design Patterns. Addison-Wesley.
 Hernández, L. d. (2017). https://programarfacil.com/blog/programacion/los-
patrones-de-diseno/.
 Informaticos, D. d. (2018). http://www.lsi.us.es/docencia/get.php?id=594.
 Largo, E. (Noviembre de 2016). Obtenido de
https://www.ecodeup.com/patrones-de-diseno-en-java-mvc-dao-y-dto/
 Otroblogmas. (2009). Obtenido de http://otroblogmas.com/patrones-de-diseno-
introduccion/
 Otroblogmas. (Noviembre de 2009). Obtenido de
http://otroblogmas.com/patrones-de-diseno-introduccion/
  SlideShare. (2012). Obtenido de https://es.slideshare.net/ikercanarias/patrones-
de-diseo-de-software-14836338
 Sourcemaking. (2017). Obtenido de https://sourcemaking.com/design_patterns
 Sourcemaking. (2018). Obtenido de https://sourcemaking.com/antipatterns
 Tedeschi, N. (2018). https://msdn.microsoft.com/es-
es/library/bb972240.aspx#XSLTsection122121120120.
 Wikipedia. (2018). Obtenido de
https://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o
 Wikipedia. (2018). Obtenido de
https://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o
 Wikipedia. (Junio de 2018). Obtenido de
https://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o
 Wikipedia. (18 de Junio de 2018).
https://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o.

8) INDICE DE ILUSTRACIONES

Ilustración 1: Abstract Factory…………………………………………………………7

Ilustración 2: Builder…………………………………………………………………...7
Ilustración 3: Factory Method…………………………………………….....................8
Ilustración 4: Prototype…………………………………………………………………9
Ilustración 5: Singleton…………………………………………………………………9
Ilustración 6: Decorator……………………………………………………………….10
Ilustración 7: Facade…………………………………………………………………..11
Ilustración 8: Bridge…………………………………………………………………..11
Ilustración 9: Adapter…………………………………………………………………12
Ilustración 10: Composite……………………………………………………………..12
Ilustración 11: Flyweight……………………………………………………………...13
Ilustración 12: Proxy…………………………………………………………………..13
Ilustración 13: Observer……………………………………………………………….14
Ilustración 14: State…………………………………………………………………...15
Ilustración 15: Memento………………………………………………………………15
Ilustración 16: Strategy………………………………………………………………..16
Ilustración 17: Template Method……………………………………………………..17
Ilustración 18: Chain of Responsibility……………………………………………….17
Ilustración 19: Iterator………………………………………………………………...18
Ilustración 20: Comand……………………………………………………………….18
Ilustración 21: Interpreter……………………………………………………………..19
Ilustración 22: Mediator……………………………………………………………….19
Ilustración 23: Visitor…………………………………………………………………20
Ilustración 24: Estructura de un Proyecto MVC………………………………………21
Ilustración 25: Estructura de un Proyecto DAO………………………………………22

9) INDICE DE TABLAS

Tabla 2: Clasificación de los Patrones de Diseño en Java………………………………6