Sunteți pe pagina 1din 70

Diseo de Sistemas

Clase 8:
Patrones de Diseo
(Parte I)

Hugo R. Cordero S.
Objetivos
Comprender el concepto de patrn y su clasificacin dentro
del diseo de los sistemas
Conocer los patrones de diseo y sus categoras: creacionales,
estructurales y de comportamiento
Entender la importancia del uso de los patrones de diseo
Conocer algunos patrones en detalle, sus motivaciones y sus
aplicaciones

2
Introduccin
Qu es un patrn?
Son soluciones a los problemas que usted encuentra una y
otra vez en el desarrollo de aplicaciones en el mundo real
Estn formados por estructuras reutilizables en la
construccin de aplicaciones
Es recurrente, lo que hace la solucin relevante a otras
situaciones
Ensea, porque permite entender cmo adaptarlo a la variante
particular del problema donde se quiere aplicar

3
Introduccin
Origen de los patrones
1977 Christopher Alexander
Lenguaje de Patrones.
Patrones de Construccin
Describen patrones, y mtodos de
construccin para diseos prcticos, seguros y
atractivos a gran escala , basado en
construcciones conocidas.
Tuvo gran influencia en otras reas ajenas a la
Arquitectura.

4
Introduccin
Clasificacin de Patrones
Arquitectnicos
Expresan un paradigma fundamental para representar un sistema
de software
De Diseo
Describen el esquema bsico para estructurar subsistemas y
componentes
Dialectos, idiomas o de cdigo
Especficos de un lenguaje de programacin o casos particulares
De Interaccin (o de interfaz)
Para el diseo de interfaces web grficas de usuario
Otros

5
Introduccin
Clasificacin de Patrones

6
Patrn de diseo
Los patrones de diseo (design patterns) son la base para
la bsqueda de soluciones a problemas comunes en el
desarrollo de software y otros mbitos referentes al
diseo de componentes, interaccin o interfaces.
Son el esqueleto de las soluciones a problemas comunes
en el desarrollo de software

7
Patrn de diseo
Es una solucin a un problema de diseo. Para que una
solucin sea considerada un patrn debe poseer ciertas
caractersticas. Una de ellas es que debe haber
comprobado su efectividad resolviendo problemas
similares en ocasiones anteriores. Otra es que debe ser
reusable, lo que significa que es aplicable a diferentes
problemas de diseo en distintas circunstancias.

8
Patrn de diseo
Partes de un Patrn

9
Patrn de diseo
Son importantes?
Saber de patrones de diseo ayuda a tener un lenguaje
comn con otros programadores.
Cuando nos toque modificar un programa, el autor del
cdigo seguramente tendr que explicar qu fue lo que
hizo, cmo funciona su cdigo y por qu hizo cualquier
cambio. Pero esa conversacin puede acortarse si dice,
aqu estoy utilizando tal o cual patrn (por ejemplo: el
patrn Factory).

10
Patrones de diseo
Causas comunes del Rediseo
Hay que tener en cuenta cmo puede necesitar cambiar el
sistema a lo largo del tiempo.
Los patrones de diseo ayudan a asegurar que un sistema
pueda cambiar de formas concretas.

Crear un objeto especificando su clase explcitamente.


(Creando objetos indirectamente)
Dependencia de operaciones concretas. (Evitar ligar las
peticiones al cdigo)

11
Patrones de diseo
Causas comunes del Rediseo
Dependencia de plataformas de HW o SW (Disear
nuestro sistema de manera que no exista mucha
dependencia de la plataforma)
Dependencias algortmicas. (Aquellos algoritmos que es
probable que cambien deben estar aislados).
Fuerte acoplamiento. (Tcnicas de Acoplamiento
abstracto)
Incapacidad para modificar las clases
convenientemente(Como adaptar una clase existente para
que podamos hacer uso de ella sin cambiar su estructura)

12
Categoras de Patrones de diseo
Por Propsito: Qu hace el patrn?
De Creacin: Establecen cmo deben crearse los objetos y
clases. Ayudan a hacer el sistema independiente de cmo se
crean, se componen y se representan sus objetos.

Estructurales: Establecen cmo se combinan las clases y los


objetos para formar estructuras ms grandes.

De Comportamiento: Se relaciona en modo en que las clases


y objetos interactan (algoritmo) y se reparten las
responsabilidades.

13
Categoras de Patrones de diseo
Creacionales
Aquellos que se desarrollan en el proceso de instanciar y
configurar objetos y clases
Factory
Abstract Factory
Singleton
Builder
Prototype

14
Categoras de Patrones de diseo
Estructurales
Aquellos que separan la interfaz de la implementacin. Se
ocupan de cmo las clases y objetos se organizan y
relacionan
Adapter o Wrapper
Bridge
Composite
Decorator
Facade
Proxy
Flyweigth

15
Categoras de Patrones de diseo
Comportamentales
Como se comunican los objetos, cooperan y distribuyen
responsabilidades para lograr sus objetivos
Template Method
Interpreter
Mediator
Command
Chain of responsibility
Iterator
Memento
Observer
State
Strategy
Visitor 16
Categoras de Patrones de diseo
Por mbito: A qu se aplica principalmente el patrn?

A Clases: Relaciones estticas entre clases y subclases


(Herencia).

A Objetos: Relaciones dinmicas entre objetos

17
Categoras de Patrones de diseo

18
Categoras de Patrones de diseo

19
Patrones de diseo
Cmo describir un Patrn?

20
Patrones de diseo
Cmo seleccionar un patrn?
Considerar cmo los patrones de diseo solucionan
problemas de diseo
Buscar las intenciones de cada patrn
Estudiar cmo se interrelacionan los patrones
Estudiar patrones de propsito similar
Examinar la causa de un rediseo
Considerar qu debera ser variable en un diseo

21
Patrones de diseo
Cmo usar un patrn?
Leer el patrn una vez para tener una visin general
Volver y estudiar la estructura, los participantes y las
colaboraciones
Ver un ejemplo concreto codificado del patrn
Elegir nombres para los participantes del patrn que sean
significativos en el contexto de la aplicacin
Definir las clases
Definir nombres especficos de la aplicacin para las
operaciones en el patrn
Implementar las operaciones que realizarn las
responsabilidades y colaboraciones del patrn

22
Factory
Utilidad
Separar la clase que crea los objetos, de la jerarqua de objetos
a instanciar
Permite que una clase difiera la instanciacin a las subclases
(son stas las que deciden qu clase instanciar)
Tambin conocido como
Factory Method
Virtual Constructor
Ventajas
Centralizacin de la creacin de objetos
Facilita la escalabilidad del sistema
El usuario se abstrae de la instancia a crear

23
Factory
Problema: Qu sucede si queremos aadir A?

24
Factory
Una primera solucin
Hay que recompilar todas las clases que heredan de A
Puede que no tengamos acceso al cdigo de A

25
Factory
Solucin
Separar el creador de las instancias de la propia clase las
instancias se crean en una clase CFactory

26
Factory
Implementacin
Dos variantes principales:
Cuando la clase Creator es abstracta y no proporciona
implementacin para el mtodo de fabricacin que declara.
Cuando la clase Creator es concreta y proporciona una
implementacin predeterminada para el mtodo de fabricacin.
Mtodos de fabricacin parametrizados:
Que los mtodos del Factory crean varios tipos de producto. El
mtodo recibe un parmetro que identifica el tipo de objeto a
crear.

27
Factory
Estructura

28
Factory
Participantes
1. Product: Interfaz de los objetos que crea el mtodo de
fabricacin.
2. ConcreteProduct*: Implementa la interfaz Product. Debe
existir una clase ConcreteProduct por cada tipo de producto
que queremos crear
3. Creator: Declara el mtodo de fabricacin, el cual devuelve
un objeto de tipo Product. Tambin puede definir una
implementacin predeterminada del mtodo de fabricacin
que devuelva un objeto ConcreteProduct. Puede llamar al
mtodo de fabricacin para crear un objeto Product.
4. ConcreteCreator*: Redefine el mtodo de fabricacin para
crear un objeto Product. Debe existir una clase
ConcreteCreator por cada tipo de producto que queremos
crear.
29
Factory
Ejemplo

30
Factory
Ejemplo
La clase Aplicacin no sabe qu tipo de documento especfico
debe crear, slo cundo debe hacerlo.
Esto implicara que el framework debera crear instancias de
cada subclase, pero slo conoce a las clases abstractas (Aplicacin
y Documento) y stas no pueden ser instanciadas.

31
Factory
Uso conocidos
Framework de aplicaciones
Conexiones a diferentes tipos de bases de datos

32
Prctica: Factory
Desarrollar una aplicacin que debe poder conectarse a
diferentes tipos de BD como Mysql, Sql Server, Oracle,
PostgreSQL.
Se debe ingresar el tipo de BD a utilizar y el sistema deber
crear la conexin.
Implemente el ejercicio utilizando el patrn Factory Method
Explique detalladamente cules seran los participantes del
patrn

33
Abstract Factory
Propsito
Define una interfaz para crear familia de objetos relacionados o
que dependen entre s, sin especificar sus clases concretas.
Motivacin
Su objetivo es soportar mltiples estndares en una aplicacin
(MS-Windows, Open Office,) sin necesidad de implementar los
componentes de cada estndar en particular. Esto ltimo podra
generar la creacin de un grupo de clases por cada tipo de
estndar existente, generando cdigo complicado de mantener.
Extensible para futuros estndares.
Tenemos un toolkit para crear interfaces de usuario de diferentes
estndares (Motif, Presentation Manager, WIN, OSX)

34
Abstract Factory
Motivacin

35
Abstract Factory
Proporciona una interfaz para crear familias de objetos y
dependencias sin especificar sus clases concretas
Ejemplo varias apariencias (Look & Feel):

36
Abstract Factory
Estructura

37
Abstract Factory
Participantes
1. AbstractProduct: Declara una interfaz para un tipo de objeto
Product.
2. Product: Define un objeto para que sea creado por la
ConcreteFactory correspondiente. Implementa la interfaz
AbstractProduct.
3. AbstractFactory: Declara una interfaz para operaciones que
crean objetos AbstractProduct.
4. ConcreteFactory: Implementa las operaciones para crear
objetos Product.
5. Client: Slo usa interfaces declaradas por las clases
AbstractFactory y AsbtractProduct.

38
Abstract Factory
Ventajas
Asla las clases de implementacin: ayuda a controlar los objetos
que se creen y encapsula la responsabilidad y el proceso de
creacin de objetos producto. (cdigo del cliente)
Hace fcil el intercambio de familias de productos sin mezclarse,
permitiendo configurar un sistema con una de entre varias
familias de productos: cambio de factory -> cambio de familia.
Fomenta la consistencia entre productos.
Desventajas
Soportar nuevas clases de productos es difcil.
La interfaz del Abstract Factory arregla el bloque de productos
que pueden ser creados. Para soportar nuevas clases se requiere
extender la interfaz factory. (cambios en AF clases y subclases)

39
Factory vs Abstract Factory

40
Singleton
Propsito
Garantiza que una clase slo tenga una instancia y proporciona
un punto de acceso global a ella.

Motivacin
Dentro de un sistema, existen elementos que deben ser nicos.
Por lo general, estas clases (elementos) administran algn recurso
de uso comn.

41
Singleton
Utilidad
Asegurar que una clase tiene una nica instancia y proporciona
un punto de acceso global a dicha instancia
Ventajas
Es necesario cuando hay clases que tienen que gestionar de
manera centralizada un recurso
Algunas clases slo necesitan exactamente un ejemplar
Un slo sistema de archivos
Un slo gestor de ventanas
Una variable global no garantiza que slo se instancie una vez

42
Singleton
Solucin
El constructor de la clase debe ser PRIVADO
Se proporciona un mtodo ESTTICO en la clase que devuelve
la nica instancia de la clase: getInstance()

43
Singleton
Estructura

Participantes
Define una operacin INSTANCIA que permite que los clientes
accedan a su nica instancia.
Puede ser responsable de crear su nica instancia.

44
Singleton
Implementacin
Definicin de la clase: asegurar que slo haya una instancia:

45
Singleton
Implementacin
Utilizacin

46
Singleton
Consecuencias
Acceso controlado a la nica instancia.
Espacio de nombre reducido. Mejora sobre el uso de variables
globales.
Permite el refinamiento de operaciones y la representacin.
Fcil modificacin para permitir un nmero variable de
instancias.
Ms flexible que las operaciones de clase.
Aplicacin
Cuando slo puede haber un ejemplar de una clase, y debe ser
accesible a los clientes desde un punto de acceso bien
conocido

47
Singleton
Ejemplo
Cada formulario captura el evento de cada uno de sus componentes e invoca
al mtodo de la clase LOG para escribir en el archivo.

48
Adapter
Propsito
Convierte la interfaz de una clase en otra interfaz que es la que
esperan los clientes. Permite que cooperen clases que de otra
forma no podran por tener interfaces incompatibles.

Motivacin
Una clase de un toolkit que ha sido rediseada para reutilizarse,
no puede hacerlo porque su interfaz no coincide con la interfaz
especfica del dominio que requiere la aplicacin.

49
Adapter

50
Adapter
Utilidad
Convertir la interfaz de una clase en otra interfaz esperada por
los clientes.
Permite que clases con interfaces incompatibles se
comuniquen
Tambin conocido como
Wrapper
Class Adapter y Object Adapter
Ventajas
Se quiere utilizar una clase ya existente y su interfaz no se
corresponde con la interfaz que se necesita
Se quiere envolver cdigo no orientado a objeto con forma de
clase

51
Adapter
Problema
Se desea utilizar la clase A (el mtodo ejec) utilizando como
entrada un objeto de la clase B:
objetoDeA.ejec(objetoDeB)
Pero no se puede, ya que la clase B no implementa la interfaz C

52
Adapter
Solucin
Construir una clase Adaptadora de B que implemente la
interfaz C. Al implementarla, usa un objeto de B y sus mtodos
Para utilizar la clase A:
objetoDeAdapterB = NEW AdapterB(objetoDeB)
objetoDeA.ejec(objetoDeAdapterB)

53
Adapter
Estructura

Participantes
Target
Define la interfaz especfica del dominio que usa el cliente.
Cliente
Colabora con los objetos conformando la interfaz del Target
Adaptee (el adaptado)
Define la interfaz existente que necesita adaptarse
Adapter
Adapta la interfaz Adaptee para usar en el objeto Target.
54
Adapter
Ejemplo
La clase TextShape adapta TextView a la interfaz Shape, de
manera que el editor grfico DrawingEditor puede reutilizar la
clase TextView, que de otra manera sera incompatible.

55
Adapter
Adaptador de Clase
Los clientes llaman a las operaciones de un objeto Adaptador
A su vez, el Adaptador llama a las operaciones heredadas de la
clase Adaptada que tratan la peticin

56
Adapter
Adaptador de Objeto
Los clientes llaman a las operaciones de un objeto Adaptador
A su vez, el Adaptador llama a las operaciones del Adaptado
que tratan la peticin

57
Adapter
Ejemplo

58
Facade
Propsito
Proporciona una interfaz unificada para un conjunto de
interfaces de un subsistema. Define una interfaz de alto nivel
que hace que el subsistema sea fcil de usar.
Motivacin
Estructurar un sistema en subsistemas ayuda a reducir su
complejidad.
Se debe minimizar las comunicaciones y dependencias entre
subsistemas.
Un modo de conseguir esto es introducir un objeto FACADE que
proporcione una interfaz nica y simplificada a los servicios ms
generales del subsistema

59
Facade
Utilidad
Simplificar el acceso a un conjunto de clases proporcionando
una nica clase que todos utilizan para comunicarse con dicho
conjunto de clases
Ventajas
Los clientes no necesitan conocer las clases que hay tras la
clase FACADE
Se pueden cambiar las clases ocultadas sin necesidad de
cambiar los clientes. Slo hay que realizar los cambios
necesarios en FACADE

60
Facade
Problema
La clase A debe saber cul es exactamente la clase que le
proporciona el servicio: b1() es de B, c1() de C, d1() de D

61
Facade
Problema
Adems puede haber muchas clases Cliente:

62
Facade
Solucin
Proporcionar una clase que implemente todos los servicios
(b1()). Los clientes slo usarn dicha clase.

63
Facade
Estructura

Participantes
Facade (Fachada)
Clase que centraliza las comunicaciones a los subsistemas.
Sabe qu clases del subsistema son las responsables por una peticin.
Delega las peticiones de los clientes en los objetos apropiados del
subsistema.
Clases del Subsistema
Implementan la funcionalidad del subsistema
64
Facade
Ejemplo
Estructurando un entorno de compilacin

65
Facade
Ejemplo
El subsistema de compilacin ofrece scanner, parser, ... a
travs de una interfaz unificada (la fachada) de la funcionalidad
del compilador

66
Facade
Ejemplo (2)
Pgina de compra por internet
Las clases son: Inventario, Pago, Shipping y Cliente

67
Facade
Ejemplo (2)
Oculta a los clientes los componentes del subsistema.
Disminuye el acoplamiento entre un subsistema y sus clientes.

68
Prctica: Facade
Crear una aplicacin que simule el encendido de un
automvil utilizando patrones. Para tal motivo considere que
se necesitan las siguientes operaciones
Comprobar gasolina
Comprobar puertas
Comprobar asientos
Comprobar espejos
Arrancar
Utilice el patrn Facade para simplificar el encendido que
utilizar el Cliente.

69
Bibliografa
Design Patterns CD, Elements of reusable Object-Oriented
software, Erich Gamma, Richard Helm, Ralph Johnson, John
Vlissides

70

S-ar putea să vă placă și