PDF de programación - Patrones de diseño - Capitulo 3

Construcción de Software

Capítulo 3

Patrones de diseño

Contenidos

1. Concepto de patrón
2. Clasificación de patrones
3.

Estudio de algunos de los principales patrones GoF

Adaptador
Factoría
Singleton
Estrategia
Composite
Fachada

•
•
•
•
•
•
• Observador

2

Bibliografía

• [Larman 02] Larman, C. “UML y Patrones: Una

introducción al análisis y diseño orientado a
objetos y al proceso unificado”, Segunda Edición,
Prentice-Hall, 2002. Capítulo 23.

• [Larman 05] Larman, C. “Applying UML and
Patterns. An Introduction to Object-Oriented
Analysis and Design and Iterative Development”,
3rd edition, Prentice-Hall, 2005. Capítulo 26.

• [Gamma et al. 02] Gamma E., et al., Patrones de

Diseño, Addison-Wesley, 2002.

3

Arquitectura software y patrones

“Una arquitectura orientada a objetos bien
estructurada está llena de patrones. La calidad de un
sistema orientado a objetos se mide por la atención
que los diseñadores han prestado a las colaboraciones
entre sus objetos.”

“Los patrones conducen a arquitecturas más
pequeñas, más simples y más comprensibles”

G. Booch

4

Diseño orientado a objetos

• “Diseñar software orientado a objetos es difícil pero
diseñar software orientado a objetos reutilizable es
más difícil todavía. Diseños generales y flexibles son
muy difíciles de encontrar la primera vez”

• ¿Qué conoce un programador experto que desconoce

uno inexperto?

Reutilizar soluciones que funcionaron en el pasado:

EXPERIENCIA

5

Patrones

• Describen un problema recurrente y una solución.
• Cada patrón nombra, explica, evalúa un diseño

recurrente en sistemas OO.

• Elementos principales:

– Nombre
– Problema
– Solución: Descripción abstracta
– Consecuencias

6

Granularidad

• Patrones de Código

– Nivel de lenguaje de programación

• Frameworks

– Diseños específicos de un dominio de aplicaciones.

• Patrones de Diseño

– Descripciones de clases cuyas instancias colaboran entre sí
que deben ser adaptados para resolver problemas de diseño
generales en un contexto particular.

– Un patrón de diseño identifica: Clases, Instancias, Roles,
Colaboraciones y la Distribución de responsabilidades.

7

Patrones y frameworks

• Un framework es una colección organizada de

clases que constituyen un diseño reutilizable para un
dominio específico de software.

• Necesario adaptarlo a una aplicación particular.
• Establece la arquitectura de la aplicación
• Diferencias:

– Patrones son más abstractos que los frameworks
– Patrones son elementos arquitecturales más pequeños
– Patrones son menos especializados

8

Modelo-Vista-Control

(MVC paradigm o MVC framework)

• Utilizado para construir interfaces de usuario en

Smalltalk-80.

• Basado en tres tipos de objetos:

– Modelo: objetos del dominio
– Vista: objetos presentación en pantalla (interfaz de usuario)
– Controlador: define la forma en que la interfaz reacciona a

la entrada del usuario.

• Desacopla el modelo de las vistas.

9

90
80
70
60
50
40
30
20
10
0

1er trim. 2do trim. 3er trim. 4to trim.

Este
Oeste
Norte

1tr

2tr

4tr

3tr

Vistas

Modelo

t1=20
t2=25
t3=90
t4=20

1tr. 2tr. 3tr. 4tr.
20 25 90 20
30 38 32 32
47 47 45 45

Este
Oeste
Norte

Modelo-Vista-Control

• Utiliza los siguientes patrones:

– Observer
– Composite
– Strategy
– Decorator
– Factory method

11

Plantilla de definición

• Nombre del patrón
• Propósito

− ¿Qué hace? ¿Cuál es su razón y propósito? ¿Qué
cuestión de diseño particular o problema aborda?

• Sinónimos
• Motivación

− Escenario que ilustra un problema particular y cómo el

patrón lo resuelve.

12

Plantilla de definición

• Aplicabilidad

− ¿En qué situaciones puede aplicarse? ¿Cómo las

reconoces? Ejemplos de diseños que pueden mejorarse

• Estructura

− Diagramas de clases que ilustran la estructura

• Participantes

− Clases que participan y sus responsabilidades

• Colaboraciones

− Diagramas de interacción que muestran cómo

colaboran los participantes.

13

Plantilla de definición

• Consecuencias

– ¿Cómo alcanza el patrón sus objetivos? ¿Cuáles son los

compromisos y resultados de usar el patrón? Alternativas,
Costes y Beneficios

• Implementación

– Técnicas, heurísticas y consejos para la implementación
– ¿Hay cuestiones dependientes del lenguaje?

• Ejemplo de código
• Usos conocidos
• Patrones relacionados

14

Clasificación de patrones de diseño

Propósito
Estructural

Creación

Ámbito

Clase

Factory Method

Adapter

Comportamiento

Interpreter

Template Method

Objeto

Abstract Factory
Builder
Prototype
Singleton

Adapter
Bridge

Composite
Decorator
Facade
Flyweight

Proxy

Chain of Responsability

Command

Iterator
Mediator
Memento
Observer

State

Strategy
Visitor

15

Adaptador

En NuevaEra...
• La aplicación NuevaEra necesita soportar

diferentes tipos de servicios externos de terceras
partes, entre los que se encuentran los calculadores
de impuestos, servicios de autorización de pagos,
sistemas de inventario, y sistemas de contabilidad.
Cada uno tiene una API diferente, que no puede
ser cambiada.

• Una solución es añadir un nivel de indirección con

objetos que adapten las distintas interfaces
externas a una interfaz consistente que es la que se
utiliza en la aplicación.

16

Adaptador (GoF)

• Nombre: Adaptador (Adapter / Wrapper)
• Contexto/Problema: ¿Cómo resolver

interfaces incompatibles, o proporcionar
una interfaz estable para componentes
similares con diferentes interfaces?

• Solución (consejo): Convertir la interfaz

original de un componente en otra interfaz,
a través de un objeto adaptador intermedio.

17

Adaptador

«interface»

ITaxCalculatorAdapter

getTaxes( Sale ) : List of TaxLineItems

Adapters use interfaces and
polymorphism to add a level of
indirection to varying APIs in other
components.

TaxMasterAdapter

GoodAsGoldTaxPro

Adapter

getTaxes( Sale ) : List of TaxLineItems

getTaxes( Sale ) : List of TaxLineItems

«interface»

IAccountingAdapter

postReceivable( CreditPayment )
postSale( Sale )
...

ICreditAuthorizationService

«interface»

Adapter

requestApproval(CreditPayment,TerminalID, MerchantID)
...

SAPAccountingAdapter

GreatNorthernAccountingAdapter

«interface»

IInventoryAdapter

...

postReceivable( CreditPayment )
postSale( Sale )
...

postReceivable( CreditPayment )
postSale( Sale )
...

18

Adaptador

• Una instancia de adaptador será instanciada para el

servicio externo elegido, tal como
SAPAccountingAdapter, y adaptará la petición
postSale al interfaz externo, como p.ej. un interfaz
SOAP XML sobre HTTPS para un servicio Web
de intranet ofrecido por SAP.

• Guía: Es común es que el nombre del patrón se

inserte en los nombres de los tipos involucrados, de
forma que se transmita rápidamente qué patrones
están involucrados en un fragmento de código.

19

Adaptador

:Register

: SAPAccountingAdapter

makePayment

...

postSale( sale )

SOAP over
HTTP

xxx

«actor»

: SAPSystem

the Adapter adapts to
interfaces in other components

20

Factoría

En NuevaEra...
• ¿Quién crea el adaptador? ¿Y cómo determinar

qué clase de adaptador crear?

• Si los creara algún objeto del dominio, las

responsabilidades de los objetos del dominio
excederían la lógica pura de la aplicación y
entrarían en cuestiones relacionadas con la
conexión con componentes software externos.

21

Factoría

• Nombre: Factoría concreta (Simple Factory /

Concrete Factory)

• Contexto/Problema: ¿Quién debe ser el

responsable de la creación de los objetos cuando
existen consideraciones especiales, como una
lógica de creación compleja, el deseo de separar
las responsabilidades de la creación para mejorar
la cohesión, etc.?

• Solución (consejo): Crear un objeto Fabricación

Pura (es decir, que no pertenece al modelo
conceptual) denominado Factoría que maneje la
creación.

22

Factoría

ServicesFactory

accountingAdapter : IAccountingAdapter
inventoryAdapter : IInventoryAdapter
taxCalculatorAdapter : ITaxCalculatorAdapter

getAccountingAdapter() : IAccountingAdapter
getInventoryAdapter() : IInventoryAdapter
getTaxCalculatorAdapter() : ITaxCalculatorAdapter
...

note that the factory methods
return objects typed to an
interface rather than a class, so
that the factory can return any
implementation of the interface

if ( taxCalculatorAdapter == null )
{
// a reflective or data-driven approach to finding the right class: read it from an
// external property

String className = System.getProperty( "taxcalculator.class.name" );
taxCalculatorAdapter = (ITaxCalculatorAdapter) Class.forName( className ).newInstance();

}
return taxCalculatorAdapter;

23

Factoría

Los objetos factoría tienen varias ventajas:
• Separan la responsabilidad de la creación
compleja en objetos de apoyo cohesivos.

• Ocultan la lógica de la creación

potencialmente compleja.

• Permiten introducir estrategias para mejorar
el rendimiento de la gestión de la memoria,
como objetos caché o de reciclaje.

24

Factoría

En NuevaEra…
• La lógica para decidir qué clase se crea se resuelve

leyendo el nombre de la clase de una fuente
externa (p.ej., por medio de una propiedad del
sistema, si se usa Java) y después se carga la clase
dinámicamente.

• Es un ejemplo de diseño dirigido por los datos.
• A menudo se accede a las factorías con el patrón

Singleton.

25

Singleton

En NuevaEra...
• ¿Quién crea la factoría de servicios y cómo

se accede?
– Sólo se necesita una instancia de la factoría en

el proceso.

– ¿Cómo conseguir visibilidad a la factoría?
⇒ Es preciso mantener visibilidad global a

una única instancia de una clase

26

Singleton (GoF)

• Nombre: Singleton
• Contexto / Problema: Se admite

exactamente una instancia de una clase –es
un “singleton”. Los objetos necesitan un
único punto de acceso global.

• Solución (consejo): Definir un método

estático de la clase que devuelva el
singleton.

27

Singleton

UML notation: this '1' can optiona