patrones de diseÑo de software
TRANSCRIPT
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