1

PATRONES DE DISEÑO DE SOFTWARE

Ingeniria de Software II

2

Definición

Los patrones de software son

soluciones reusables de problemas recurrentes.

3

Definición

Un patron de diseño es una descripción de clases y objetos

comunicándose entre sí, adaptado para resolver un problema de diseño general en un contexto

particular

» Gamma

4

Definición

Cada patrón describe un problema que ocurre una y otra vez en nuestro

entorno y describe también el nucleo de la solucion al problema, de forma

que pueda utilizarse un millon de veces sin tener que hacer dos veces lo

mismo.» Alexander

5

Historia

1977

PATRONES ARQUITECTURALES, creados por el arquitecto Christopher Alexander.

1987

Ward Cunnigham y Ken Beck, basados en c. Desarrollaron 5 patrones para diseñar Interfaces de usuario.

1994Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (The Gang of Four [GOF]) publicaronEl libro Design Pattern Elements of Reusable Object-Oriented Sofware.

1998

Patterns in Java, Grand Mark, Usa UML y JAVA

6

Ventajas

1

Están ya probados: son soluciones que han sido utilizadas con anterioridad de manera repetida y se ha comprobado que funciona.

3Son expresivos: cuando un equipo de desarrolladores tiene un vocabulario común de patrones, se puede comunicar de manera fluida y precisa las ideas fundamentales sobre el diseño de una aplicación .

2

Son reutilizabes: corresponden con prolemas que no son específicos de un caso concreto, sino que se presentan una y otra ves en distintas aplicaciones .

7

Elementos Fundamentales

Nombre: Identifica al patron, define un vocabulario común.

El problema a Resolver: Describe cuando aplicar un patron, explica el problema y su contexto.

La Solucion: Describe los elementos que participan del diseño, sus relaciones, responsabilidades y colaboraciones, Da una descripción abstracta de un problema de diseño y la manera en que un grupo general de elementos lo resuelven.No describe una implementación concreta particular.

Consecuencias (+ o -): Resultados de aplicar el patrón, Impacto en la flexibilidad, extensibilidad y portabilidad de un sistema.

8

Clasificación de los patrones GoF (Banda De Los Cuatro)

Creación

Estructural

Comportamiento

Factory MerthodAdapterFacade

InterpreterComand

Abstrac Factory BridegeIterator

Mediator

Builder CompositeMementoObserver

Prototype DecoratorState

Strategy

SingletonFlyweight

ProxiVisitor

9

ABSTRACT FACTORY

Provee una interface que permite crear familias de objetos relacionados o dependientes, sin

especificar sus clases concretas.

Aplicabilidad: Usado cuando, es necesario organizar un conjunto de

elementos que trabajan con productos diferentes, pero relacionados de alguna manera.

Un sistema deba ser independiente de cómo se crean, componen o representan sus productos Si se cambia la implementación, secambian todos sus elementos a la vez.

10

ABSTRACT FACTORY (Estructura)

FábricaAbstracta: Define métodos abstractos para crear instancias de clases Producto concretas.

FábricaConcreta: Implementan los métodos definidos por la superclase para crear instancias de clases Producto concretas.

ProductoAbstracto: Clases abstractas que corresponden a una característica de un producto con la que sus subclases concretas trabajarán.

ProductoConcreto: define un producto para que pueda ser creado por la correspondiente fábrica concreta.

Cliente: utiliza sólo las interfaces declaradas por FábricaAbstractay ProductoAbstracto

11

ABSTRACT FACTORY (Ejemplos)

12

FACTORY METHOD

Define una interfaz para la creación de objetos, pero delega en las subclases la desición de

qué o cual clase instanciar.

Aplicabilidad: Cuando una calse no pueda anticipar que tipo

deobjetos debe crear.Cuando una clase quiere que sus clases

especifiquen los objetos que deben crear.

13

FACTORY METHOD (Estructura)

Product: Define la interfaz de los objetos creados por el método de fabricación (FactoryMethod())

Concret Product: implementa la interfaz Product.

Creator: declara el método de fabricación, que devuelve un objeto de tipo product.

ConcreteCreator: Implementa el método FactoryMethod de la clase Creador de tal forma que este cree instancias de la clase ProductoConcreto correspondiente.

14

FACTORY METHOD (Ejemplo)

15

BUILDER

Construir de manera flexible un objeto Complejo a partir de otro objeto Complejo en

una serie de pasos

Aplicabilidad: El algoritmo para crear un objeto complejo deba ser

independiente de las partes que componen el objeto y de cómo se ensamblan.

El proceso de construcción deba permitir distintas representaciones para el objeto que es construido

16

BUILDER (Estructura)

Constructor: especifica una interfaz abstracta para crear un objeto complejo Producto

ConstructorConcreto:construye y ensambla las partes del Producto implementando la interfaz de Constructor

Director: obtiene las partes que forman el Producto y lo construye usando la interfaz de Constructor

Parte: representa las partes que se usan para construir el Producto

Producto: representa el objeto complejo en construcción

17

SINGLETON

Asegurar que solo existe una única instancia de una clase, y que hay un punto global de

acceso a la misma.

Aplicabilidad: Es necesario cuando hay clases que tienen que

gestionar de manera centralizada un recurso. Asegurarse de que una clase tiene una sola

instancia y proporcionar un punto de acceso global a ella.

18

SINGLETON (Estructura)

define una operación de clase GetInstancia que permite a los clientes acceder a su instancia única y además es responsable de su creación de Constructor

Los clientes acceden a la única instanciasolamente a través de la operación GetInstancia

19

SINGLETON (Ejemplos)

En una aplicación que administra la venta y alquiler de películas de un video club, se desea agregar una funcionalidad que permita seleccionar diariamente una única película recomendada, para la casa central y todas las sucursales que posee el Video.

20

COMPOSITE

Componer objetos en jerarquías todo - parte y permitir a los clientes tratar objetos simples y

compuestos de manera UniformeAplicabilidad: Permite representar jerarquias de objetos similar a una estructura

de arbol. Permite tratamiento uniforme de objetos simples y complejos así

como composiciones recursivas. Simplifica el código de los clientes, que sólo usan una interfaz. Facilita añadir nuevos componenetes sin afectar a los clientes. Cuando se quiera que los clientes puedan ignorar la diferencia

entre objetos simples y compuestos y tratarlos uniformemente

21

COMPOSITE (Estructura)Cliente: Utiliza objetos de la composición mediante la interfaz de Componente

Simple: Representa los objetos de la composición que no tienen hijos e implementa sus operaciones.

Compuesto: Implementa las operaciones para los componentes con hijos y almacena a los hijos.

Componente: Declara la interfaz para la composición de objetos, implementa acciones por defecto cuando es oportuno y, opcionalmente, accede al padre en la jerarquía.

22

COMPOSITE (Ejemplos)

23

COMPOSITE (Ejemplos)

24

PROXY

El patrón obliga a que las llamadas a métodos de un objeto ocurran indirectamente a través de un objeto proxy, que actúa

como sustituto del objeto original, delegando luego las llamadas a los métodos de los objetos respectivos.

Aplicabilidad: los proxys remotos deben codificar las peticiones y enviárselas al

sujeto real remoto los proxys virtuales pueden tener un caché con información sobre el

sujeto real para evitar accesos innecesarios los proxys de protección comprueban que el cliente tenga permisos

de acceso para realizar una petición Proxy de Sincronización: Controla accesos de múltiples clientes a

un recurso.

25

PROXY (Estructura)

Sujeto: define la interfaz común para SujetoReal y Proxy

Sujeto real: define el objeto real al que Proxy representa

Proxy: representa a un objeto real y mantiene una referencia para acceder al sujeto real, controla el acceso y puede ser responsable de crearlo y destruirlo tiene una interfaz idéntica a la de Sujeto para que ambos sean intercambiables

26

PROXY (Ejemplo)

27

COMMAND

Su propósito es encapsular una solicitud como un objeto.

Facilita la parametrizaciónde los clientes con diferentes peticiones, el encolado de las mismas y

su reordenación.

Aplicabilidad: Permite implementar el hacer/deshacer (do/undo) mediante métodos. Presenta una forma sencilla de implementar un sistema basado en

comandos facilitándose su uso y ampliación. Se independiza la parte de la aplicación que invoca los comandos de la

implementación de los mismos. Los comandos se tratan como objetos, entonces se puede realizar herencia

o composiciones de comandos (Composite).

28

COMMAND (Estructura)

ConcreteCommand: Implementa un comando concreto y sus metodos do y undo. Su constructor debe inicializar los parámetros del comando.

Invoker: Instancia los comandos. Puede ejecutarlos inmediatamente (llamando a do) o dejar que el CommandManager lo haga.

CommandManager: Gestiona una colección de objetos comando creados por Invoker. Llama a do y undo, gestiona su secuenciación y reordenación.

AbstractCommand: Ofrece una interfaz para la ejecución de comandos. Define los métodos do y undo que implementarán cada clase concreta

29

MEDIATOR

Definir un objeto que encapsule como interactúan un conjunto de objetos, evitando que tengan que conocerse entre ellos y permitiendo cambiar la

interacción de forma independiente

Aplicabilidad: Encapsula el comportamiento de todo un conjunto de

objetos en un solo objeto. Un conjunto de objetos se comunique de una forma bien

definida pero compleja, con interdependencias complicadas.

Reutilizar un objeto sea difícil porque tenga que tener referencias a muchos objetos para comunicarse con ellos

30

MEDIATOR (Estructura)Mediador: define una interfaz para comunicarse con los objetos colegas

MediadorConcreto: implementa la conducta cooperativa coordinando los colegas, a los que conoce y mantiene actualizados

cada clase colega conoce a su mediador y se comunica con él cuando en otras circunstancias lo hubiera tenido que hacer con otro colega

31

MEDIADOR (Ejemplo)

32

ITERATOR

Este patrón define una interfaz que declara métodos para el acceso secuencial de objetos en una

colección. Una clase que accesa una colección únicamente a través de esta interfaz, se mantiene

independiente de la clase que implementa la interfaz.

Aplicabilidad: Es conveniente usar este patrón cuando una clase necesita

accesar el contenido de una colección, sin hacerse dependiente de la clase que implementa la colección.

La clase que accede a la colección solamente a través de dicho interfaz permanece independiente de la clase que implementa la interfaz.

Proporcionar una interfaz uniforme para recorrer diferentes estructuras de agregación (iteración polimórfica)

33

ITERATOR (Estructura)

Iterador: define una interfaz para acceder a los elementos del agregado y recorrerlos

IteradorConcreto implementa la interfaz de Iteradory mantiene la posición actual del recorrido

Agregado: define una interfaz para crear un objeto iterador

AgregadoConcreto: implementa la interfaz de creación del iterador para devolver una instancia apropiada de IteradorConcreto

34

OBSERVADOR

Definir una dependencia 1:n de forma que cuando el objeto 1 cambie su estado, los n objetos sean notificados y se actualicen automáticamente.

Aplicabilidad: Un cambio en un objeto requiera cambiar otros y no se

sepa cuantos objetos necesitan cambiar. Este patrón es útil cuando se tienen relaciones de

dependencias uno-a-muchos, que requieren que un objeto notifique a otros sobre cambios en su estado.

35

OBSERVADOR (Estructura)

Sujeto: conoce a sus observadores y proporciona una interfaz para suscribirlos y desuscribirlos

Observador: define una interfaz para actualizar los objetos que deban ser notificados de cambios en el sujeto

Sujeto Concreto: envía una notificación a sus observadores cuando cambia su estado

ObservadorConcreto: mantiene una referencia a un sujeto (SujetoConcreto), almacena parte del estado del sujeto e implementa la interfaz de actualización de Observador para mantener su estado consistente con el del sujeto.

36

OBSERVADOR (Ejemplo)

37

DELEGATION

Cuando se quiere extender y reutilizar la

funcionalidad de una clase SIN UTILIZAR LA HERENCIA

Aplicabilidad:Indica cuándo no usar herencia.Cuando una clase que hereda de otra quiere

ocultar algunos de los métodos heredados.La solución general propuesta en este patrón

es: incorporar la funcionalidad de la clase original usando una instancia de la clase original y llamando sus métodos.

38

DELEGATION (Ejemplo)

39

INTERFACE

Mantiene una clase (la interfaz) que usa datos y servicios provistos por otras clases

independientes, para proveer un acceso uniforme.

Aplicabilidad:Usando indirección, esta clase interfaz provee a

sus clases herederas acceso uniforme a métodos y atributos específicos, sin que deban saber a cuál clase específica pertenecen.

40

INTERFACE (Estructura)

la clase Cliente usa otras clases que implementan la interfaz IndirecciónIF. La interfaz IndirecciónIF provee la indirección que mantiene

a la clase Cliente independiente de las clases que proveen los servicios (clase Servicios).

41

INMUTABLE

Este patrón recomienda que para evitar la administración de la propagación y sincronización de cambios en el estado de los objetos, se usen múltiples objetos de ese tipo, haciendo estos objetos inmutables, es decir, deshabilitando cualquier cambio en su estado después de construido. Hay entonces dos aspectos en la implementación de este patrón: (1) Ningún método (a excepción del constructor) debe modificar los valores de las variables de instancia de la clase; (2) Cualquier método que calcula un nuevo estado, debe almacenar la información en una nueva instancia de la misma clase, en lugar de modificar el estado de un objeto ya existente.

42

INMUTABLE (Ejemplo) suponga que está creando un juego, donde se tiene un

escenario con ciertos objetos (árboles, rocas, ríos, etc.). Estos objetos ocasionalmente se mueven dentro del escenario, o aparecen en distintas posiciones del mismo escenario en otras etapas del juego. Para diseñar las clases del programa, se decide usar objetos inmutables para representar la posición de los objetos en el campo de juego. La organización de una clase para modelar estas posiciones, podría ser de la siguiente forma.

43

ADAPTER

Convertir la interfaz de una clase en otra interfaz esperada por los clientes.Permite que clases con interfaces incompatibles

puedan comunicarse.

Aplicabilidad:Se quiera utilizar una clase ya existente y su

interfaz no se corresponda con la interfaz que se necesita.

Convertir la interfaz de una clase en otra interfaz esperada por los clientes.

Permite que clases con interfaces incompatibles se comuniquen

44

ADAPTER (Estructura)

Objetivo: define la interfaz específica que usa el cliente

Cliente: colabora con objetos que respetan la interfaz de Objetivo

Adaptado: define la interfaz existente que necesita ser adaptada

Adaptador: implementa la interfaz

45

ADAPTER (Ejemplo)

Suponga que se está escribiendo un método que copia un arreglo de objetos, filtrando los objetos que no cumplen cierto criterio. Para poder luego reutilizarlo, suponga que se quiere hacer el método independiente del actual criterio de filtrado. Esto se puede hacer creando una interfaz que declare un método que el copiador de arreglos llame para saber si incluye o no el

objeto.

46

FACADE

Proporcionar una interfaz unificada para un conjunto de interfaces en un subsistema,

haciéndolo más fácil de usar.

Aplicabilidad:Se quiera proporcionar una interfaz sencilla para un

subsistema complejo.Se quiera desacoplar un subsistema de sus clientes

y de otros subsistemas, haciéndolo mas independiente y portable.

Se quiera dividir los sistemas en niveles: las fachadas serían el punto de entrada a cada nivel.

47

FACADE (Estructura)

Fachada: conoce las clases del ubsistema y delega las peticiones de los clientes en los objetos del subsistema

Clases del Sistema: implementan la funcionalidad del subsistema y llevan a cabo las peticiones que les envía la fachada, aunque no la conocen

48

FACADE (Ejemplo)

49

MODELO VISTA CONTROLADOR

Las interfaces de usuario son especialmente propensas a cambios de requerimientos.

Aplicabilidad: MVC divide una aplicación en tres áreas: procesamiento, entrada y

salida. El componente modelo encapsula los datos y la funcionalidad principales de la aplicación.

El componente Vista despliega la información al usuario, a partir de los datos del Modelo. Cada Vista tiene un componente Controlador asociado, que se encarga de recibir las entradas del usuario (usualmente en forma de eventos como: movimiento del mouse, activación de los botones del mouse, o entradas de teclado).

50

Ingenieria de Software II