Está en la página 1de 50

PATRONES DE DISEO DE SOFTWARE

Integrantes: Lozano Alcazar Eduardo Tello Ccapacca Celso Torres Caldern Pedro Zuiga Aranibar Porfirio

Definicin

Los patrones de software son soluciones reusables de problemas recurrentes.


2

Definicin
Un patrn de diseo es una descripcin de clases y objetos comunicndose entre s, adaptado para resolver un problema de diseo general en un contexto particular.
Erich Gamma

Definicin
Cada patrn describe un problema que ocurre una y otra vez en nuestro entorno y describe tambin el ncleo de la solucin al problema, de forma que pueda utilizarse un milln de veces sin tener que hacer dos veces lo mismo.
Christopher Alexander

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 disear Interfaces de usuario.

1987 1977

PATRONES ARQUITECTURALES, creados por el arquitecto Christopher Alexander.

Ventajas

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

2
Son reutilizables: corresponden con problemas que no son especficos 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 comn de patrones, se puede comunicar de manera fluida y precisa las ideas fundamentales sobre el diseo de una aplicacin .

Elementos Fundamentales
Nombre: Identifica al patron, define un vocabulario comn. El problema a Resolver: Describe cuando aplicar un patron, explica el problema y su contexto. La Solucion: Describe los elementos que participan del diseo, sus relaciones, responsabilidades y colaboraciones, Da una descripcin abstracta de un problema de diseo y la manera en que un grupo general de elementos lo resuelven. No describe una implementacin concreta particular. Consecuencias: Resultados de aplicar el patrn, Impacto en la flexibilidad, extensibilidad y portabilidad de un sistema.
7

Clasificacin de los patrones GoF (Banda De Los Cuatro)


Creacin Factory Merthod Estructural Adapter Facade Bridge Builder Composite Comportamiento Interpreter Comand Iterator Mediator Memento Observer

Abstrac Factory

Prototype

Decorator
Flyweight Proxi

State Strategy
Visitor

Singleton

ABSTRACT FACTORY
Provee una interface que permite crear familias de objetos relacionados o dependientes. Aplicabilidad:
Usado cuando, es necesario organizar un conjunto de elementos que trabajan con productos diferentes, pero relacionados de alguna manera. Un sistema debe ser independiente de cmo se crean, componen o representan sus productos. Si se cambia la implementacin, se cambian todos sus elementos a la vez.

ABSTRACT FACTORY (Estructura)


ProductoAbstracto: Clases abstractas que corresponden a una caracterstica de un producto con la que sus subclases concretas trabajarn. FbricaAbstracta: Define mtodos abstractos para crear instancias de clases Producto concretos. Cliente: utiliza slo las interfaces declaradas por FbricaAbstractay ProductoAbstracto

ProductoConcreto: define un producto para que pueda ser creado por la correspondiente fbrica concreta. FbricaConcreta: Implementan los mtodos definidos por la superclase para crear instancias de clases Producto concretos.

10

ABSTRACT FACTORY (Ejemplo)

Jirafa

11

FACTORY METHOD
Define una interfaz para la creacin de objetos, pero delega en las subclases la decisin de qu o cual clase instanciar. Aplicabilidad: Cuando una clase no pueda anticipar que tipo de objetos debe crear. Cuando una clase quiere que sus clases especifiquen los objetos que deben crear.

12

FACTORY METHOD (Estructura)


Creator: declara el mtodo de fabricacin, que devuelve un objeto de tipo product.

Product: Define la interfaz de los objetos creados por el mtodo de fabricacin (FactoryMethod()) ConcreteCreator: Implementa el mtodo FactoryMethod de la Creador de tal forma que Concret Product: implementa laclase 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 cmo se ensamblan. El proceso de construccin 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 construccin

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 travs de la operacin GetInstancia

define una operacin de clase GetInstancia que permite a los clientes acceder a su instancia nica y adems es responsable de su creacin de Constructor

18

SINGLETON (Ejemplos)
En una aplicacin que administra la venta y alquiler de pelculas de un video club, se desea agregar una funcionalidad que permita seleccionar diariamente una nica pelcula recomendada, para la casa central y todas las sucursales que posee el Video.

19

COMPOSITE
Componer objetos en jerarquas 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 cdigo de los clientes, que slo usan una interfaz. Facilita aadir 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 composicin 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 composicin de objetos, implementa acciones por defecto cuando es oportuno y, opcionalmente, accede al padre en la jerarqua.

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

COMPOSITE (Ejemplos)

22

COMPOSITE (Ejemplos)

23

PROXY
El patrn obliga a que las llamadas a mtodos de un objeto ocurran indirectamente a travs de un objeto proxy, que acta como sustituto del objeto original, delegando luego las llamadas a los mtodos de los objetos respectivos. Aplicabilidad: los proxys remotos deben codificar las peticiones y envirselas al sujeto real remoto los proxys virtuales pueden tener un cach con informacin sobre el sujeto real para evitar accesos innecesarios los proxys de proteccin comprueban que el cliente tenga permisos de acceso para realizar una peticin Proxy de Sincronizacin: Controla accesos de mltiples clientes a un recurso.

24

PROXY (Estructura)
Sujeto: define la interfaz comn 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 idntica a la de Sujeto para que ambos sean intercambiables

25

PROXY (Ejemplo)

26

COMMAND
Su propsito es encapsular una solicitud como un objeto. Facilita la parametrizacinde los clientes con diferentes peticiones, el encolado de las mismas y su reordenacin. Aplicabilidad:
Permite implementar el hacer/deshacer (do/undo) mediante mtodos. Presenta una forma sencilla de implementar un sistema basado en comandos facilitndose su uso y ampliacin. Se independiza la parte de la aplicacin que invoca los comandos de la implementacin 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 parmetros del comando. AbstractCommand: Ofrece una interfaz para la ejecucin de comandos. Define los mtodos do y undo que implementarn cada clase concreta

CommandManager: Gestiona una coleccin de objetos comando creados por Invoker. Llama a do y undo, gestiona su secuenciacin y reordenacin. 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 interactan un conjunto de objetos, evitando que tengan que conocerse entre ellos y permitiendo cambiar la interaccin 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 difcil 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 patrn define una interfaz que declara mtodos para el acceso secuencial de objetos en una coleccin. Una clase que accesa una coleccin nicamente a travs de esta interfaz, se mantiene independiente de la clase que implementa la interfaz. Aplicabilidad:
Es conveniente usar este patrn cuando una clase necesita accesar el contenido de una coleccin, sin hacerse dependiente de la clase que implementa la coleccin. La clase que accede a la coleccin solamente a travs de dicho interfaz permanece independiente de la clase que implementa la interfaz. Proporcionar una interfaz uniforme para recorrer diferentes estructuras de agregacin (iteracin polimrfica)
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 creacin del iterador para devolver una instancia apropiada de IteradorConcreto

IteradorConcreto implementa la interfaz de Iteradory mantiene la posicin 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 automticamente. Aplicabilidad: Un cambio en un objeto requiera cambiar otros y no se sepa cuantos objetos necesitan cambiar. Este patrn 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: enva una notificacin 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 actualizacin 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 cundo no usar herencia. Cuando una clase que hereda de otra quiere ocultar algunos de los mtodos heredados. La solucin general propuesta en este patrn es: incorporar la funcionalidad de la clase original usando una instancia de la clase original y llamando sus mtodos.
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 indireccin, esta clase interfaz provee a sus clases herederas acceso uniforme a mtodos y atributos especficos, sin que deban saber a cul clase especfica pertenecen.

39

INTERFACE (Estructura)

la clase Cliente usa otras clases que implementan la interfaz IndireccinIF. La interfaz IndireccinIF provee la indireccin que mantiene a la clase Cliente independiente de las clases que proveen los servicios (clase Servicios).

40

INMUTABLE
Este patrn recomienda que para evitar la administracin de la propagacin y sincronizacin de cambios en el estado de los objetos, se usen mltiples objetos de ese tipo, haciendo estos objetos inmutables, es decir, deshabilitando cualquier cambio en su estado despus de construido. Hay entonces dos aspectos en la implementacin de este patrn: (1) Ningn mtodo (a excepcin del constructor) debe modificar los valores de las variables de instancia de la clase; (2) Cualquier mtodo que calcula un nuevo estado, debe almacenar la informacin 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, ros, etc.). Estos objetos ocasionalmente se mueven dentro del escenario, o aparecen en distintas posiciones del mismo escenario en otras etapas del juego. Para disear las clases del programa, se decide usar objetos inmutables para representar la posicin de los objetos en el campo de juego. La organizacin de una clase para modelar estas posiciones, podra 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 especfica 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 mtodo que copia un arreglo de objetos, filtrando los objetos que no cumplen cierto criterio. Para poder luego reutilizarlo, suponga que se quiere hacer el mtodo independiente del actual criterio de filtrado. Esto se puede hacer creando una interfaz que declare un mtodo 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, hacindolo ms fcil 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, hacindolo mas independiente y portable. Se quiera dividir los sistemas en niveles: las fachadas seran 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 enva 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 aplicacin en tres reas: procesamiento, entrada y salida. El componente modelo encapsula los datos y la funcionalidad principales de la aplicacin. El componente Vista despliega la informacin 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, activacin de los botones del mouse, o entradas de teclado).

49

50

También podría gustarte