Patrones de Diseño - Creacionales

Diseño y Construcción de Software
Patrones de Diseño Creacionales
Mg. Ing. Efrain Bautista Ubillús

[email protected] | [email protected]
UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software

Agenda
1. Clasificación de Patrones de Diseño

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

Elementos Esenciales de un Patrón
• Nombre
o Determina una terminología común para referirse al patrón.
• Descripción del problema

o Cuál es el propósito.
o Cuál es el contexto y las precondiciones para su uso.
• Descripción de la solución
o Aspectos dinámicos y estáticos.
o Participantes, relaciones, responsabilidades y colaboraciones.
• Consecuencias
o Cuáles son las ventajas de su uso, el costo y las alternativas existentes.

Descripción de los Patrones de Diseño
• Nombre y clasificación • Colaboraciones
• Propósito • Consecuencias
• También conocido como • Implementación
• Motivación • Código de ejemplo
• Aplicabilidad • Usos conocidos
• Estructura • Patrones relacionados
• Participantes

Clasificación de Patrones - Gang of Four

Relación entre los Patrones de Diseño

Principios del Diseño Orientado a Objetos
• Programe para una interfaz, no para una

implementación.
• Favorecer la composición de objetos frente a la

herencia de clases.

Según [Gamma et al, 94]
• Alcance, los clasifica de acuerdo a su existencia:
o Clases, basados en la definición de clases y sus relaciones con
otras subclases.
o Objetos, basados en las relaciones entre objetos en tiempo de
ejecución.
• Propósito, los clasifica de acuerdo a su intención:

o Creacionales, describen como crear objetos.
o Estructurales, describen como componer clases u objetos.
o Comportamiento, describen como interactúan y cumplen con sus
responsabilidades.

Patrones Creacionales
• Abstraen el proceso de
creación de objetos.
• Ayudan a crear sistemas

independientes de cómo los
objetos son creados,
compuestos y representados.

• Dos tipos:
o Clase: usa herencia para variar la clase
que es instanciada.
o Objeto: delega instanciación a otro objeto.
• Se encapsula:
o Qué clases concretas usa el sistema.
o Cómo se crean las instancias de esa clase.

Patrón Singleton
• Propósito
o Asegurar que una clase tenga una única instancia y asegurar un
único punto de acceso global.
• Motivación
o Cuando necesitamos manejar de manera centralizada un recurso.
o La clase se encarga de asegurar que exista una única instancia y
de su acceso.
• Aplicabilidad
o Debe existir una única instancia de una clase, accesible
globalmente.
Patrón Singleton
• Estructura

Patrón Singleton
• Estructura (not thread-safe) - Java

Patrón Singleton
• Estructura (thread-safe) - Java

Patrón Singleton - Consecuencias
o Acceso controlado a la única instancia.

o La implementación por defecto del patrón Singletón no es
thread-safe y no debería usarse en entornos multi-hilos.
o Introduce alto acoplamiento entre la colaboración de
clases.
o Son notoriamente difíciles de testear.

Patrón Singleton - Consecuencias
o Viola el Single Responsability Principle, la gestión del

ciclo de vida de un objeto es una responsabilidad
separada.
o Usando un Contenedor IoC, una clase separada puede

ser responsable de la gestión del ciclo de vida del objeto
y se evita problemas de acoplamiento y testing.

Patrón Singleton
http://www.informit.com/articles/article.aspx?p=1404056
2009

Patrón Prototype
• Propósito
o Es realmente útil cuando los objetos difieren entre
ellos por su estado y es costoso crear los objetos

por el tiempo y procesamiento requerido.
• Motivación
o Se ve muchas veces el patrón prototipo para reducir
el tiempo de tareas costosas.

Patrón Prototype
• Copias Simples (Shallow Copy)
o El objeto original con estado y comportamiento son duplicados.
o Las referencias a otros objetos no son copiadas. Es decir, el
objeto original y el objeto copiado, hacen referencia al mismo

objeto de menor nivel.

Patrón Prototype
• Copias Completas (Deep Copy)
o El objeto original con estado y comportamiento son duplicados
o Los objetos contenidos, también son duplicados. Es decir, el
objeto original y el objeto clonado referencian a diferentes

objetos contenidos.

Patrón Prototype
• Aplicabilidad
o Cuando se requiere crear un objeto a partir de otro objeto
sin necesidad de conocer las clases exactas o los detalles de

cómo crearlas.
o El mismo objeto encapsula como crear copias de sí mismo.
• Consecuencias
o Aísla a los clientes de las clases, de la complejidad de estar
instanciando nuevos objetos. Estos son copiados.

o Los objetos copiados difieren mínimamente de sus objetos
prototipos.
Patrón Prototype
• Ejemplos

Patrón Factory Method
Propósito
o Un clase base puede extenderse por herencia.
o Las clases especializadas pueden redefinir los métodos
heredados.
o Un objeto de aplicación puede conocer solamente la clase base
que desea utilizar, pero no la clase especializada a instanciar.
o La elección puede basarse en:
v Algún estado en el objeto que se está ejecutando.
v Configuración de la aplicación.
v Requerimientos adicionales.

• Motivación
o Si un objeto de aplicación intenta usar los servicios de la clase
especializada necesita implementar el criterio de selección
para cada clase. Lo que resulta en un alto grado de
acoplamiento.
o Si los criterios de selección cambian. Cada clase aplicación que

utiliza alguna de las clases debe cambiar.
o La implementación de estos criterios conlleva a codificaciones

poco elegantes de los objetos aplicación.
• Aplicabilidad
o Se recomienda encapsular el/los criterios de selección de la clase
apropiada, dentro de un método denominado Factory Method.
• Estructura

• Ejemplo

• Consecuencias
o Elimina la necesidad de que el objeto aplicación maneje los
criterios de selección.
o Debido a que el método de fábrica retorna una instancia de
la clase, como una instancia del tipo de la clase padre, el
objeto aplicación no debe preocuparse por las subclases de
la jerarquía.
o Agregar nuevas clases y funcionalidad sin romper el Open
Closed Principle.

Patrón Abstract Factory
• Propósito
o Proporcionar una interfaz para crear familia de objetos
relacionados o dependientes sin especificar la clase concreta.

o Proporcionar un grupo de clases de factories concretas que
implementan la interfaz proporcionada por la clase abstract
factory.
• Motivación
o Si no existiera un abstract factory, el objeto de aplicación
debería tener la lógica necesaria para elegir la clase apropiada
en cada lugar donde se necesita.
• Diferencias con Factory Method
o Abstract Factory es usada para crear grupos de objetos
relacionados, ocultando la clase concreta específica.

o Para cada grupo o familia de objetos, una Factory concreta es
implementada la cual maneja la creación de los objetos y sus
relaciones.
o Cada Factory concreta implementa la interfaz de la abstract
factory.
o Abstract Factory especifica un método de creación de objetos,
donde las subclases definen el objeto concreto.
• Aplicabilidad
o Un sistema debería ser independiente de cómo sus
productos son creados, compuestos y representados

o Un sistema debería ser configurado para una familia de
productos.
o Se quiere proporcionar una librería de clases de
productos y se quiere revelar sólo la interfaz, no la
implementación.

• Estructura

• Consecuencias
o Aísla a los clientes de las clases concretas de la implementación
de los criterios de selección.
o Facilita el intercambio de familias de productos.
o Favorece la consistencia entre productos.
o Agregar nuevas factories y clases sin romper el Open Closed
Principle.

• Ejemplo

Patrón Builder
• Propósito
o Separa la construcción de un objeto complejo de su
representación. Es decir que el mismo proceso de

construcción puede crear diferentes representaciones.
• Motivación
o Un traductor de documentos RTF a otros formatos. ¿Es
posible añadir una nueva conversión sin modificar el

traductor?

Patrón Builder
• Aplicabilidad
o Cuando el algoritmo para crear un objeto complejo
debiera ser independiente de las partes de que se

componen dicho objeto y de cómo se ensamblan.
o El proceso de construcción debe permitir diferentes
representaciones del objeto que está siendo construido.

Patrón Builder
• Estructura

Patrón Builder
• Estructura

Patrón Builder
• Participantes
o Builder
§ Especifica una interfaz abstracta para crear las partes de un
objeto Producto.
o ConcreteBuilder
§ Implementa la interfaz Builder para construir y ensamblar
las partes del Producto.
§ Define la representación a crear.
§ Proporciona un interfaz para devolver el Producto.

Patrón Builder
• Participantes
o Director
§ Construye un objeto usando la interfaz Constructor
o Producto
§ Representa el objeto complejo en construcción. El
ConcreteBuilder construye la representación interna del
producto y define el proceso de ensamblaje.
§ Incluye las clases que definen sus partes constituyentes,
incluyendo interfaces para ensamblar las partes en el
resultado final.

Patrón Builder
• Colaboraciones
o El cliente crea el objeto Director y lo configura con el objeto
Builder deseado.
o El Director notifica al Builder cada vez que hay que construir
una parte de un producto.
o El Builder maneja las peticiones del Director y las añade al
producto.
o El cliente obtiene el producto del Builder.

Patrón Builder
• Colaboraciones

Patrón Builder
• Consecuencias
o Permite variar la representación interna del producto.
o Aísla el código de construcción y representación.
• Los clientes no necesitan saber nada de las clases que

definen la estructura interna del producto.
• Diferentes “directores” pueden reutilizar un mismo
“builder”
o Proporciona un control fino sobre el proceso de
construcción.

Patrón Builder
• Ejemplo

• Singleton
o Garantiza que una clase sólo tenga una instancia y proporciona
un punto de acceso global a ella.
• Prototype
o Especifica los tipos de objetos a crear por medio de una
instancia prototípica, y crea nuevos objetos copiando de este

prototipo.
• Factory Method
o 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.
• Abstract Factory
o Proporciona una interfaz para crear familias de objetos
relacionados o que dependen entre sí, sin especificar sus clases
concretas.
• Builder
o 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.

Patrones de Diseño - Creacionales

Cargado por

Copyright:

Formatos disponibles

Patrones de Diseño - Creacionales

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 de Diseño - Creacionales

Cargado por

Copyright:

Formatos disponibles

Diseño y Construcción de Software

Patrones de Diseño Creacionales

Mg. Ing. Efrain Bautista Ubillús

UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software

1. Clasificación de Patrones de Diseño

UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software

• Descripción del problema

o Cuál es el contexto y las precondiciones para su uso.

o Participantes, relaciones, responsabilidades y colaboraciones.

UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software

UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software

UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software

UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software

• Programe para una interfaz, no para una

• Favorecer la composición de objetos frente a la

UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software

• Propósito, los clasifica de acuerdo a su intención:

UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software

• Ayudan a crear sistemas

UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software

UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software

o La clase se encarga de asegurar que exista una única instancia y

UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software

UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software

UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software

o Acceso controlado a la única instancia.

UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software

o Viola el Single Responsability Principle, la gestión del

o Usando un Contenedor IoC, una clase separada puede

UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software

UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software

ellos por su estado y es costoso crear los objetos

el tiempo de tareas costosas.

UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software

o Las referencias a otros objetos no son copiadas. Es decir, el

objeto original y el objeto copiado, hacen referencia al mismo

UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software

o Los objetos contenidos, también son duplicados. Es decir, el

objeto original y el objeto clonado referencian a diferentes

UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software

sin necesidad de conocer las clases exactas o los detalles de

instanciando nuevos objetos. Estos son copiados.

UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software

UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software

o Si los criterios de selección cambian. Cada clase aplicación que

o La implementación de estos criterios conlleva a codificaciones

apropiada, dentro de un método denominado Factory Method.

UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software

UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software

UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software

relacionados o dependientes sin especificar la clase concreta.

relacionados, ocultando la clase concreta específica.

productos son creados, compuestos y representados

UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software

UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software

UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software

UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software

representación. Es decir que el mismo proceso de

posible añadir una nueva conversión sin modificar el

UNMSM – Maestría en Ingeniería de Sistemas e Informática – Mención en Ingeniería de Software