patrones de diseño gof

17
Ingeniería de Software II – Ing. Oscar Ascón Valdivia Ronald Roldán Salinas Página 1 PATRONES DE DISEÑO GoF 1. HISTORIA En 1994 apareció el libro “Design Patterns: Elements of Reusable Object Oriented Software”. Escrito por los ahora famosos Gang of Four (GoF). GoF: Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides. 2. DEFINICIONES Cada “Patrón” describe un problema que ocurre una y otra vez en nuestro entorno y describe también el núcleo de su solución, de forma que puede utilizarse un millón de veces sin hacer dos veces lo mismo (Christoph Alexander, Arquitecto y Urbanista). Un “Patrón de Diseño” es una descripción de clases y objetos que se comunican entre sí, adaptada para resolver un problema general de diseño en un contexto particular (GoF). Un “Patrón de Diseño” es una solución a un problema en un contexto. Es la base fundamental para la búsqueda de soluciones a problemas comunes en el desarrollo de software. Para que una solución sea considerada como un patrón, debe poseer ciertas características: Efectivo y Reutilizable. 3. IMPORTANCIA Es un tema importante en el desarrollo de software actual, permitiendo capturar la experiencia. Busca ayudar a la comunidad de desarrolladores de software a resolver problemas comunes, creando un cuerpo literario de base. El uso de los patrones ayuda a obtener un software de alta calidad (reutilización y extensibilidad).

Upload: ronaldroldansalinas

Post on 08-Nov-2015

249 views

Category:

Documents


0 download

DESCRIPTION

analisis de sistemas

TRANSCRIPT

  • Ingeniera de Software II Ing. Oscar Ascn Valdivia

    Ronald Roldn Salinas Pgina 1

    PATRONESDEDISEOGoF1. HISTORIA

    En 1994 apareci el libro Design Patterns: Elements of Reusable Object Oriented Software.Escrito por los ahora famosos Gang of Four (GoF).

    GoF: Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides.

    2. DEFINICIONES Cada Patrn describe un problema que ocurre una y otra vez en nuestro entorno y

    describe tambin el ncleo de su solucin, de forma que puede utilizarse un milln de vecessin hacer dos veces lo mismo (Christoph Alexander, Arquitecto y Urbanista).

    Un Patrn de Diseo es una descripcin de clases y objetos que se comunican entre s,adaptada para resolver un problema general de diseo en un contexto particular (GoF).

    Un Patrn de Diseo es una solucin a un problema en un contexto. Es la base fundamental para la bsqueda de soluciones a problemas comunes en el

    desarrollo de software. Para que una solucin sea considerada como un patrn, debe poseerciertas caractersticas: Efectivo y Reutilizable.

    3. IMPORTANCIA Es un tema importante en el desarrollo de software actual, permitiendo capturar la

    experiencia. Busca ayudar a la comunidad de desarrolladores de software a resolver problemas comunes,

    creando un cuerpo literario de base. El uso de los patrones ayuda a obtener un software de alta calidad (reutilizacin y

    extensibilidad).

  • Ingeniera de Software II Ing. Oscar Ascn Valdivia

    Ronald Roldn Salinas Pgina 2

    4. VENTAJAS DE LOS PATRONES DE DISEO Facilitan la localizacin de los objetos que formarn el sistema. Facilitan la determinacin de la granularidad adecuada. Especifican interfaces para las clases. Especifican implementaciones (al menos parciales). Facilitan el aprendizaje y la comunicacin entre programadores y diseadores. Formalizar un vocabulario comn entre diseadores. Estandarizar el modo en que se realiza el diseo. Evitar la reiteracin en la bsqueda de soluciones a problemas ya conocidos y solucionados

    anteriormente.

    5. CONCEPTO DE ANTIPATRN Un Antipatrn de diseo es un patrn de diseo que conduce a una mala solucin para un

    problema. Evitar los antipatrones siempre que sea posible, requiere su reconocimiento e identificacin

    dentro del ciclo de vida del software. Patrn de diseo Buen Camino. Antipatrn de diseoMal Camino.

    6. ELEMENTOS DE UN PATRNNombre:Describe el problema de diseo.El Problema:Describe cundo aplicar el patrn.La Solucin:Describe los elementos que componen el diseo, sus relaciones, responsabilidades y colaboracin.

  • Ingeniera de Software II Ing. Oscar Ascn Valdivia

    Ronald Roldn Salinas Pgina 3

    7. TIPOS DE PATRN7.1. RESPECTO A SU PROPSITO

    7.1.1. CREACIONALESResuelven problemas relacionados con la creacin de instancias de objetos.Dentro de este tipo tenemos las siguientes: Abstract Factory

    Proporciona una clase que delega la creacin de una o ms clases concretas con elfin de entregar objetos especficos. Este patrn puede ser utilizado cuando:

    La creacin de objetos debe ser independiente del sistema que los utilice. Los sistemas deben ser capaces de utilizar mltiples familias de objetos. Se usan bibliotecas sin exponer detalles de la implementacin.

    Factory MethodDefine una interfaz para crear un objeto, pero deja que sean las subclases quienesdecidan que clase instanciar. Permite que una clase delegue en sus subclases lacreacin de objetos. Este patrn puede ser utilizado cuando:

    Una clase no puede anticipar el tipo de objeto que debe crear. Las subclases pueden especificar que objetos deben ser creados.

  • Ingeniera de Software II Ing. Oscar Ascn Valdivia

    Ronald Roldn Salinas Pgina 4

    SingletonGarantiza que una clase slo tenga una instancia y proporciona un punto de accesoglobal a ella. Este patrn puede ser utilizado cuando:

    Se requiere exactamente una instancia de una clase. Es necesario el acceso controlado a un solo objeto.

    PrototypeSe encarga de crear objetos mediante clonacin basados en plantilla de objetosexistentes. Este patrn puede ser utilizado cuando:

    La composicin, creacin y representacin de los objetos debedesacoplarse de un sistema.

    Las clases que se creen se especifican en tiempo de ejecucin. Para un objeto existen un nmero limitado de combinaciones de estado. Se requiere que objetos o estructuras de objetos sean idnticos o se

    parezcan mucho a otros objetos o estructuras existentes. La creacin inicial de cada objeto es una operacin costosa.

  • Ingeniera de Software II Ing. Oscar Ascn Valdivia

    Ronald Roldn Salinas Pgina 5

    BuilderCentraliza el proceso de creacin de un objeto en un nico punto, de tal forma queel mismo proceso de construccin pueda crear representaciones diferentes. Estepatrn puede ser utilizado cuando:

    Los algoritmos de creacin de objetos deben ser desacoplados del sistema. Son obligatorias mltiples representaciones de algoritmos de creacin. Se requiere control sobre el proceso de creacin en tiempo de ejecucin.

    7.1.2. ESTRUCTURALESSe centran en problemas relacionados con la forma de estructurar clases. Segn este tipotenemos las siguientes: Adapter

    Permite trabajar juntas a clases con interfaces diferentes a travs de la creacin deun objeto comn mediante el que puedan comunicarse e interactuar. Este patrnpuede ser utilizado cuando:

    Una clase no cumple los requisitos de interfaz. Condiciones complejas atan el comportamiento de los objetos a su estado. Las transacciones entre los estados necesitan ser explcitas.

  • Ingeniera de Software II Ing. Oscar Ascn Valdivia

    Ronald Roldn Salinas Pgina 6

    BridgeDefine una estructura de objeto abstracto con independencia de la implementacincon la finalidad de limitar el acoplamiento. Este patrn puede ser utilizado cuando:

    Las abstracciones e implementaciones no deben ser dependientes entiempo de compilacin.

    Los cambios en la implementacin no deberan tener impacto en losclientes.

    Los detalles de la implementacin se deben ocultar al cliente.

    CompositeFacilita la creacin de jerarquas de objetos donde cada objeto se puede tratar deforma independiente o como un conjunto de objetos anidados a travs de la mismainterfaz. Este patrn puede ser utilizado cuando:

    Se necesitan representaciones jerrquicas de objetos. Los objetos y composiciones de objetos debe ser tratados de manera

    uniforme.

  • Ingeniera de Software II Ing. Oscar Ascn Valdivia

    Ronald Roldn Salinas Pgina 7

    DecoratorAade dinmicamente funcionalidad a un objeto, permitiendo no tener que crearsubclases incorporando la nueva funcionalidad, sino otras que la implementan y seasocian a la primera. Este patrn puede ser utilizado cuando:

    El comportamiento de objetos debe ser dinmicamente modificable. Las funcionalidades especficas no deben residir en la parte alta de la

    jerarqua de objetos.

    FacadeProporciona una interfaz unificada para un conjunto de interfaces de un subsistema.Define una interfaz de alto nivel que hace que el subsistema sea ms fcil de usar.Este patrn puede ser utilizado cuando:

    Se necesita una interfaz simple para proporcionar acceso a un sistemacomplejo.

    Hay muchas dependencias entre las implementaciones de sistemas y losclientes.

  • Ingeniera de Software II Ing. Oscar Ascn Valdivia

    Ronald Roldn Salinas Pgina 8

    FlyweightFacilita la reutilizacin de muchos objetos de grano fino, haciendo ms eficiente lautilizacin de grandes cantidades de objetos. Este patrn se utiliza cuando:

    Se utilizan muchos objetos parecidos y los costes de almacenamiento sonaltos.

    Unos pocos objetos compartidos se pueden sustituir por muchos nocompartidos.

    No tiene importancia la identidad de cada objeto.

    ProxyUna clase que permite operar con un objeto de otra clase exponiendo una o ms desus interfaces. Este patrn es utilizado cuando:

    El objeto representado es externo al sistema. Los objetos se deben crear bajo demanda. Se requiere aadir funcionalidad cuando se accede a un objeto. Se requiere control de acceso para el objeto original.

  • Ingeniera de Software II Ing. Oscar Ascn Valdivia

    Ronald Roldn Salinas Pgina 9

    7.1.3. DE COMPORTAMIENTOPermiten resolver problemas relacionados con el comportamiento de la aplicacin,normalmente en tiempo de ejecucin. Chain of Responsability

    Evita acoplar el emisor de una peticin a su receptor dando a ms de un objeto laposibilidad de responder a una peticin. Este patrn puede ser utilizado cuando:

    Ms de un objeto puede manejar una peticin y el manejador no se conocea priori.

    Se requiere enviar una peticin a un objeto entre varios sin especificarexplcitamente el receptor.

    El conjunto de objetos que puede tratar una peticin debera serespecificado dinmicamente.

    CommandPermite solicitar una operacin a un objeto sin conocer realmente el contenido deesta operacin, ni el receptor real de la misma. Para ello se encapsula la peticincomo un objeto, con lo que adems se facilita la parametrizacin de los mtodos.Este patrn puede ser utilizado para:

    Facilitar la parametrizacin de las acciones a realizar. Independizar el momento de peticin del de ejecucin. Implementar CallBacks, especificando que rdenes queremos que se

    ejecuten en ciertas situaciones. Desarrollar sistemas utilizando rdenes de alto nivel que se construyen con

    operaciones sencillas (primitivas).

  • Ingeniera de Software II Ing. Oscar Ascn Valdivia

    Ronald Roldn Salinas Pgina 10

    InterpreterDefine una representacin para su gramtica junto con un intrprete del lenguaje.Este patrn puede ser utilizado cuando:

    Se quiere definir un lenguaje para representar expresiones regulares querepresenten cadenas a buscar dentro de otras cadenas.

    Se pretende definir un lenguaje que permita representar las distintasinstancias de una familia de problemas.

  • Ingeniera de Software II Ing. Oscar Ascn Valdivia

    Ronald Roldn Salinas Pgina 11

    IteratorDefine una interfaz que declara los mtodos necesarios para accedersecuencialmente a un grupo de objetos de una coleccin. Algunos de estos mtodoscomunes que se definen en la interfaz iterator son:

    Primero() Siguiente() HayMas() ElementoActual()

    Este patrn puede ser utilizado cuando: Se necesita tener acceso a elementos sin tener acceso a toda la

    representacin. Se pretenden hacer recorridos mltiples o concurrentes de los elementos. Existen diferencias sutiles entre los detalles de implementacin de varios

    iteradores.

  • Ingeniera de Software II Ing. Oscar Ascn Valdivia

    Ronald Roldn Salinas Pgina 12

    MediatorDefine un objeto que encapsula la manera en que interactan un conjunto deobjetos entre ellos. Este patrn puede ser utilizado cuando:

    La comunicacin entre los conjuntos de objetos est bien definido y escomplejo.

    Existen demasiadas relaciones y se necesita un punto comn de control ocomunicacin.

    MementoSu finalidad es almacenar el estado de un objeto (o del sistema completo) en unmomento dado de manera que se pueda restaurar en ese punto de manera sencilla.Este patrn puede ser utilizado cuando:

    El estado interno de un objeto debe ser guardado y restaurado en unmomento posterior.

    El estado interno no se puede exponer mediante interfaces sin exponer laimplementacin.

  • Ingeniera de Software II Ing. Oscar Ascn Valdivia

    Ronald Roldn Salinas Pgina 13

    ObserverDefine una independencia del tipo uno a muchos entre objetos, de manera quecuando uno de los objetos cambia su estado, notifica este cambio a todos losdependientes. Este patrn puede ser utilizado cuando:

    Se necesita consistencia entre clases relacionadas, pero con independencia. Los cambios de estado en uno o ms objetos deben dar lugar a

    comportamiento en otros objetos.

    StateSe utiliza cuando el comportamiento de un objeto cambia dependiendo del estadodel mismo. Por ejemplo:Una alarma puede tener diferentes estados: activada, desactivada, en configuracin,etc. En este caso se pueden definir una interfaz Estado_Alarma y luego definir losdiferentes estados.Este patrn puede ser utilizado cuando se permite a un objeto alterar sucomportamiento segn el estado interno en que se encuentre

  • Ingeniera de Software II Ing. Oscar Ascn Valdivia

    Ronald Roldn Salinas Pgina 14

    StrategyPermite mantener un conjunto de algoritmos de entre los cuales el objeto clientepuede elegir aquel que le conviene e intercambiarlo dinmicamente segn susnecesidades. Este patrn puede ser utilizado cuando:

    La nica diferencia entre muchas clases relacionadas es su comportamiento. Se requieren mltiples versiones de un algoritmo. El comportamiento de una clase debe ser definido en tiempo de ejecucin.

    Template MethodDefine dentro de una operacin de una superclase, los pasos de un algoritmo, deforma que todos o parte de estos pasos son redefinidos en las subclases herederasde la citada superclase. Este patrn puede ser utilizado cuando:

    El comportamiento comn entre subclases debe estar localizado en unaclase comn.

    Las clases padre deben ser capaces de invocar de manera uniforme en elcomportamiento de sus subclases.

  • Ingeniera de Software II Ing. Oscar Ascn Valdivia

    Ronald Roldn Salinas Pgina 15

    VisitorPermite aplicar una o ms operaciones a un conjunto de objetos en tiempo deejecucin, desacoplando dichas operaciones de la estructura del objeto. Este patrnpuede ser utilizado:

    Cuando la estructura del objeto no se puede cambiar, pero s lasoperaciones que realiza.

    Ampliamente en intrpretes, compiladores y procesadores de lenguajes, engeneral.

    7.2. RESPECTO A SU AMBITO7.2.1. CLASES

    Relaciones estticas entre clases.7.2.2. OBJETOS

    Relaciones dinmicas entre objetos.

  • Ingeniera de Software II Ing. Oscar Ascn Valdivia

    Ronald Roldn Salinas Pgina 16

    8. VOCABULARIO COMN

    8.1. CLASE ABSTRACTAEs una clase que tiene al menos un mtodo abstracto que obliga a que toda la clase seaabstract.

    8.2. HERENCIAFacilita la creacin de objetos a partir de otros ya existentes e implica que una subclase obtienetodo el comportamiento (mtodos) y eventualmente los atributos (variables) de su superclase(clase padre).

    8.3. INTERFACEContiene cabeceras de mtodos y constantes (variables finales), pero no implementacin demtodos o miembros de datos no finales.

    8.4. POLIMORFISMOSe refiere a la capacidad para que varias clases derivadas de una antecesora utilicen un mismomtodo de forma diferente.

  • Ingeniera de Software II Ing. Oscar Ascn Valdivia

    Ronald Roldn Salinas Pgina 17

    8.5. SOBRE CARGA DE MTODOSPosibilidad de tener dos o ms mtodos con el mismo nombre pero funcionalidad diferente.

    8.6. GRANULARIDADDensidad de cada objeto.