P. 1
PATRONES DE DISEÑO DE SOFTWARE

PATRONES DE DISEÑO DE SOFTWARE

|Views: 4.438|Likes:
Publicado porGalatea2

More info:

Published by: Galatea2 on Apr 08, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PPTX, PDF, TXT or read online from Scribd
See more
See less

08/13/2013

pdf

text

original

PATRONES DE DISEÑO DE SOFTWARE

Ingeniria de Software II
1

Definición 

Los patrones de software son soluciones reusables de problemas recurrentes.
2

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

3

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

4

Historia
1998
Patterns in Java, Grand Mark, Usa UML y JAVA

1994
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (The Gang of Four [GOF]) publicaron El libro Design Pattern Elements of Reusable Object-Oriented Sofware. Ward Cunnigham y Ken Beck, basados en c. Desarrollaron 5 patrones para diseñar Interfaces de usuario. PATRONES ARQUITECTURALES, creados por el arquitecto Christopher Alexander.

1987

1977

5

Ventajas

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

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 .

3
Son 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 .

6

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

Clasificación de los patrones GoF (Banda De Los Cuatro)
Creación Factory Merthod Estructural Adapter Facade Bridege Comportamiento Interpreter Comand Iterator Mediator Memento Observer State Strategy Visitor

Abstrac Factory

Builder

Composite

Prototype

Decorator Flyweight Proxi

Singleton

8

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.

9

ABSTRACT FACTORY (Estructura)
ProductoAbstracto: Clases abstractas que corresponden a una característica de un producto con la que sus subclases concretas trabajarán. FábricaAbstracta: Define métodos abstractos para crear instancias de clases Producto concretas. Cliente: utiliza sólo las interfaces declaradas por FábricaAbstractay ProductoAbstracto

ProductoConcreto: define un producto para que pueda ser creado por la correspondiente fábrica concreta. FábricaConcreta: Implementan los métodos definidos por la superclase para crear instancias de clases Producto concretas.

10

ABSTRACT FACTORY (Ejemplos)

11

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.

12

FACTORY METHOD (Estructura)
Creator: declara el método de fabricación, que devuelve un objeto de tipo product.

Product: Define la interfaz de los objetos creados por el método de fabricación (FactoryMethod()) ConcreteCreator: Implementa el método FactoryMethod de la Concret Product: implementa la clase Creador de tal forma que interfaz este cree instancias de la clase Product. ProductoConcreto correspondiente.

13

FACTORY METHOD (Ejemplo)

14

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

15

BUILDER (Estructura)
Constructor: especifica una interfaz abstracta para crear un objeto complejo Producto Producto: representa el objeto complejo en construcción

Parte: representa las partes que se usan para construir el Producto Director: obtiene las partes que forman el Producto y lo construye usando la interfaz de Constructor ConstructorConcreto:construye y ensambla las partes del Producto implementando la interfaz de Constructor
16

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.

17

SINGLETON (Estructura)
Los clientes acceden a la única instancia solamente a través de la operación GetInstancia

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

18

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.

19

COMPOSITE
Componer objetos en jerarquías todo - parte y permitir a los clientes tratar objetos simples y compuestos de manera Uniforme
Aplicabilidad:  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

20

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

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.

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

COMPOSITE (Ejemplos)

22

COMPOSITE (Ejemplos)

23

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.

24

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

25

PROXY (Ejemplo)

26

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

27

COMMAND (Estructura)
ConcreteCommand: Implementa un comando concreto y sus metodos do y undo. Su constructor debe inicializar los parámetros del comando. AbstractCommand: Ofrece una interfaz para la ejecución de comandos. Define los métodos do y undo que implementarán cada clase concreta

CommandManager: Gestiona una colección de objetos comando creados por Invoker. Llama a do y undo, gestiona su secuenciación y reordenación. Invoker: Instancia los comandos. Puede ejecutarlos inmediatamente (llamando a do) o dejar que el CommandManager lo haga.

28

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
29

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

30

MEDIADOR (Ejemplo)

31

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)
32

ITERATOR (Estructura)
Iterador: define una interfaz para acceder a los elementos del agregado y recorrerlos

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 IteradorConcreto implementa la interfaz de Iteradory mantiene la posición actual del recorrido

33

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.

34

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.
35

OBSERVADOR (Ejemplo)

36

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.
37

DELEGATION (Ejemplo)

38

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.

39

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

40

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.
41

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.

42

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
43

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

44

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.

45

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.
46

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

47

FACADE (Ejemplo)

48

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

49

Ingenieria de Software II
50

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->