Abstract Factory
Upcoming SlideShare
Loading in...5
×
 

Abstract Factory

on

  • 21,717 views

ABSTRACT FACTORY DESIGN PATTERN

ABSTRACT FACTORY DESIGN PATTERN

Statistics

Views

Total Views
21,717
Views on SlideShare
21,576
Embed Views
141

Actions

Likes
0
Downloads
447
Comments
1

1 Embed 141

http://www.slideshare.net 141

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Abstract Factory Abstract Factory Presentation Transcript

    • ABSTRACT FACTORY PATTERN Diego Alejandro Henao Calderón Código: 72917 E-mail: [email_address] Universidad del Quindío
    • Contenido
      • Introducción
      • Propósito
      • También conocido como…
      • Motivación
      • Aplicabilidad
      • Estructura
      • Participantes
      • Colaboraciones
      • Consecuencias
      • Implementación
      • Código de ejemplo
      • Usos conocidos
      • Patrones relacionados
      • Conclusiones
    • Introducción
      • El Patrón Abstract Factory toma el mismo concepto de Factory Method pero al próximo nivel. En términos simples, un Abstract Factory es una clase que provee una interfaz para producir una familia de objetos. En el lenguaje de programación Java, esto se puede implementar o bien con una interfaz o con una clase abstracta.
    • Propósito
      • Provee una interfaz para la creación de familias relacionadas o objetos dependientes sin especificar sus clases concretas. Por ejemplo para la creación de widgets o interfaces gráficas multiplataforma (SO Diferentes)
    • También conocido como…
      • Kit
      Foto: http ://gpwiki.org/images/b/b1/AbstractFactoryPatternUMLDiagram.png
    • Motivación (1 de 4)
      • Su objetivo es soportar múltiples estándares (MS-Windows, Motif, Open Look,…).
      • Extensible para futuros estándares.
      • Restricciones: cambiar el Look-and-Feel sin recompilar y cambiar el Look-and-Feel en tiempo de ejecución.
    • Motivacion (2 de 4)
      • Ejemplo de partida: Creación de Widgets en aplicación cliente.
      • Un armazón para interfaces gráficas que soporte distintos tipos de presentación (look-and-feel).
      • Las aplicaciones cliente no deben cambiar porque cambie el aspecto de la interfaz de usuario.
      • Los clientes no son conscientes de las clases concretas, sino sólo de las abstractas.
      • Sin embargo los WidgetFactory imponen dependencias entre las clases concretas de los Widgets que contiene.
    • Ejemplo de Motivacion (3 de 4)
    • Ejemplo de motivacion (4 de 4)
      • Problema: Las aplicaciones clientes NO deben crear sus widgets para un Look-and-Feel concreto.
          • Scrollbar *sb = new MotifScrollBar();
          • Menu *menu = new MotifMenu();
      • Solución: Abstraer el proceso de creación de widgets. En lugar de:
      • Scrollbar *sb = new MotifScrollBar();
      • Usar:
      • Scrollbar *sb = WidgetFactory->CreateScrollBar();
        • WidgetFactory será una instancia de MotifWidgetFactory
    • Aplicaciones
      • Un sistema debe ser independiente de los procesos de creación, composición y representación de sus productos.
      • Un sistema debe ser configurado con una familia múltiple de productos.
      • Una familia de productos relacionados se ha diseñado para ser usados conjuntamente (y es necesario reforzar esta restricción).
      • Se quiere proporcionar una librería de productos y no revelar su implementación (simplemente revelando sus interfaces).
    • Estructura Foto: http ://www.gsong.pe.kr/tt/attach/1/1618012864.png
    • Participantes
      • AbstractFactory (WidgetFactory): Declara un interfaz para las operaciones de creación de objetos de productos abstractos
      • ConcreteFactory (MotifWidgetFactory, PMWidgetFactory): Implementa las operaciones para la creación de objetos de productos concretos.
      • AbstractProduct (Window, ScrollBar): Declara una interfaz para los objetos de un tipo de productos.
      • ConcreteProduct (MotifWindow, MotifScrollBar): Define un objeto de producto que creará la correspondiente Concrete Factory , a la vez que implementa la interfaz de AbstractProduct .
      • Client : Usa solamente las interfaces declaradas por las clases AbstractFactory y AbstractProduct .
    • Colaboraciones
      • Normalmente una única instancia de cada ConcreteFactory es creada en tiempo de ejecución. Esta concrete factory crea productos teniendo una implementación particular. Para crear diferentes productos de objetos, los clientes deben usar diferentes concrete factory
      • AbstractFactory delega la creación de productos a sus subclases ConcreteFactory.
    • Consecuencias (1 de 2)
      • Ventajas:
        • Aísla las clases de implementación: ayuda a controlar los objetos que se creen y encapsula la responsabilidad y el proceso de creación de objetos producto. (código del cliente)
        • Hace fácil el intercambio de familias de productos sin mezclarse, permitiendo configurar un sistema con una de entre varias familias de productos:
        • cambio de factory  cambio de familia.
        • Fomenta la consistencia entre productos.
    • Consecuencias (2 de 2)
      • Desventajas:
        • Soportar nuevas clases de productos es difícil. Porque la interfaz del Abstract Factory arregla el bloque de productos que pueden ser creados. Para soportar nuevas clases se requiere extender la interfaz factory. (cambios en AF clases y subclases)
          • Posible Solución:
          • Pasarle un parámetro a los métodos de creación de productos  clase abstracta común  necesidad de downcast  solución no segura.
    • Implementacion (Tecnicas AF Pattern)
      • Factorías como singletons:
        • Sólo una instancia de ConcreteFactory por familia de productos. (Mejor implementado a través de Singleton)
      • Creacion de productos: Utilizando un Factory Method para cada producto. Requiere de varias Concrete Factory subclase por cada familia de productos. Cuando hay varias familias de productos -> Prototype
      • Definir factorías extensibles:
        • Añadiendo un parámetro en las operaciones de creación que indique el tipo de objeto a crear: mas flexible y menos seguro.
    • Código de Ejemplo (1 de 3) foto: http://blog.dotnetstyling.com/archive/2007/11/25/Abstract-Factory-Design-Pattern.aspx
    • Ejemplo de Código (2 de 3) foto: http://blog.dotnetstyling.com/archive/2007/11/25/Abstract-Factory-Design-Pattern.aspx
    • Ejemplo de Código (3 de 3) foto: http://blog.dotnetstyling.com/archive/2007/11/25/Abstract-Factory-Design-Pattern.aspx
    • Usos Conocidos
      • ET++ usa Abstract Factory para archivar portablemente sobre diferentes sistemas windows (X Windows y SunView)
      • La clase base abstracta de WindowsSystem define la interfaz para crear objetos que representan recursos del sistema windows.
      Foto: http://alumni.media.mit.edu/~tpminka/patterns/ET++/mirror.gif
    • Patrones relacionados
      • Se pueden implementar con Factory Method o Prototype.
      • Las factorías concretas suelen ser Singleton
      Foto: http://upload.wikimedia.org/wikipedia/commons/archive/e/ed/20061219215908!Factory_Method_UML_class_diagram.png Foto: http://cvs.m17n.org/~akr/mj/design-pattern/fig-GoF/PNG/singleton.png
    • Conclusiones
      • Una situación en la que el programa maneja un tipo de objetos con unas características comunes y algunas características propias. Esto en general en software se resuelve mediante el uso de dos características de los lenguajes de programación orientados a objetos, las clases abstractas y los interfaces .
      • El patrón de diseño Abstract Factory aborda el problema de la creación de familias de objetos (como por ejemplo interfaces gráficos) que comparten toda una serie de características comunes en los objetos que componen dichas familias.
      • El uso de este patrón está recomendado para situaciones en las que tenemos una familia de productos concretos y prevemos la inclusión de distintas familias de productos en un futuro.
    • Bibliografía
      • Cano F.P., Gonzalez R. & Zamora R. Abstract Factory . Obtenido el 10 de Marzo de 2008 desde: [ http:// kybele.escet.urjc.es /documentos/SI/Patrones/01_ Abstract%20Factory . ppt#257 ,4,Definición del Abstract Factory ]
      • Abstract Factory. (WIKIPEDIA, 2008). Obtenido el 10de Marzo de 2008 desde: http://es.wikipedia.org/wiki/Abstract_Factory_(patr%C3%B3n_de_dise%C3%B1o)
      • Patrones de diseño - abstract factory (introduccion) Obtenido el 10de Marzo de 2008 desde: http://www.thealphasite.org/articulos/patrones_de_diseno_abstract_factory
      • Gamma E., Helm R., Johnson R., Vlissides J. (1995) Abstract Factory. Design Patterns: Elements of Reusable Object-Oriented Software. Ed.: Addison-Wesley.
      • http://gpwiki.org/images/b/b1/AbstractFactoryPatternUMLDiagram.png
      • http://www.tml.tkk.fi/~pnr/GoF-models/gif/Abstract-factory.gif
      • Abstract Factory Design Pattern (2008). Obtenido el 10 de Marzo de 2008 desde: http ://blog.dotnetstyling.com/archive/2007/11/25/Abstract-Factory-Design-Pattern.aspx
    • Gracias. Preguntas? ABSTRACT FACTORY – DIEGO ALEJANDRO HENAO CALDERON