abstract factory
TRANSCRIPT
UNIVERSIDAD NACIONAL DE TRUJILLO
INTEGRANTES:
Acate Venegas Karen Sofía
Castro Reyna Frank Peter
Iwamatsu moreno Luis Fernando
2014
[ABSTRACT FACTORY]
ABSTRACT FACTORY
Top. En Software Página 1
Contenido INTRODUCCION ............................................................................................................................. 3
Marco Teórico ............................................................................................................................... 4
Sobre los patrones de diseño .................................................................................................... 4
Objetivo ..................................................................................................................................... 4
Motivación ................................................................................................................................ 4
Utilización .................................................................................................................................. 4
Descripción ................................................................................................................................ 4
Diagrama ................................................................................................................................... 5
CAPITULO I .................................................................................................................................... 6
ABSTRACT FACTORY ...................................................................................................................... 6
1.1. Modelo .......................................................................................................................... 6
1.2. Relación con otros patrones ......................................................................................... 7
1.3. Características ............................................................................................................... 7
1.4. Implementación ............................................................................................................ 8
1.5. Ventajas en Inconvenientes ........................................................................................ 11
Conclusiones ............................................................................................................................... 12
Bibliografía .................................................................................................................................. 12
ABSTRACT FACTORY
Top. En Software Página 2
DEDICATORIA
A nuestros padres por el apoyo incondicional en lo que nos proponemos.
ABSTRACT FACTORY
Top. En Software Página 3
INTRODUCCION
“Abstract Factory”. Simplificando mucho el concepto para que de cara al futuro nos quede
aunque sea una idea clave en la cabeza sobre qué es este patrón, podemos decir que una
Abstract Factory es una clase que nos provee de una interfaz para producir una familia de
objetos. Lo que a todos los efectos es, crear una interfaz que nos permita la creación y
utilización de objetos relacionados pero sin tener que definir ni especificar una clase concreta.
Presenta una interfaz para la creación de familias de productos, de forma tal que el cliente que
las utiliza no requiera conocer las clases concretas que la componen. Esto fuerza al cliente a
crear solamente productos “relacionados” entre sí, a la vez que lo habilita para la utilización de
distintas familias de productos.
Se suele utilizar mucho por ejemplo para la creación de widgets o interfaces gráficas que sean
multiplataforma, de esta forma nos podemos abstraer del sistema concreto y realizar el
desarrollo de forma genérica.
El método fábrica utiliza una clase constructora que puede tener métodos definidos y/o
abstractos. El comportamiento es definido por las subclases, por lo que dependiendo de la
clase abstracta que utilicemos el comportamiento cambiará. Otro nombre que recibe es el de
“Kit”.
ABSTRACT FACTORY
Top. En Software Página 4
Marco Teórico
Sobre los patrones de diseño
Mucho se ha escrito sobre Software, pero tan poco puede ser de tanta utilidad como los patrones de diseño. Tanto si eres neófito en el mundo de la programación (y del diseño de Software), como un programador señor, los patrones de diseño te aportan “recetas” (si está entre comillado por algo) mucho más que útiles en el día a día (siempre y cuando seas programador y/o analista, claro está).
Objetivo Definir una interfaz para la creación de un objeto, delegando a las subclases la decisión sobre
la clase particular que deberá ser instanciada.
Motivación Pensemos en un toolkit de interfaz de usuario que admita múltiples estándares de interfaz de
usuario, de la interfaz de usuario como las barras de desplazamiento, ventanas y botones. Para
que una aplicación pueda portarse a varios estándares de interfaz de usuario en particular. Si
la aplicación crea instancias de clases o útiles específicos de la interfaz de usuarios será difícil
cambiar ésta más tarde.
Utilización
Cuando una clase no puede saber por anticipado el tipo de objetos que deberá crear.
Cuando una clase debe delegar a sus subclases la responsabilidad de decidir que
objetos serán creados.
Cuando las clases delegan responsabilidades a una o varias
Subclases y se requiere conocer con precisión cuales responsabilidades tiene cada una
de ellas.
Descripción
Algunas veces, una aplicación necesita utilizar varios recursos o sistemas operativos, Algunos
ejemplos incluyen:
Gestión de ventanas (la interfaz gráfica de una aplicación) Un sistema de ficheros. Comunicación con otras aplicaciones.
ABSTRACT FACTORY
Top. En Software Página 5
Es deseable que este tipo de aplicaciones sean lo suficientemente flexibles como para ser
capaces de utilizar distintos recursos sin tener que reescribir el código de la aplicación cada vez
que se introduce un recurso nuevo.
Una forma efectiva de resolver este problema es definir un creador de recursos genéricos, es
decir, el patrón Abstract Factory. La fábrica tiene uno o más métodos de creación, que pueden
ser llamados para producir recursos genéricos o productos abstractos.
Java (las tecnologías) se ejecutan en muchas plataformas, cada una de las cuales tiene
diferentes implementaciones de un sistema de ficheros, o un sistema de ventanas. La solución
que ha tomado Java es abstraer los conceptos de fichero, ventana sin mostrar la
implementación concreta.
Se puede desarrollar la aplicación utilizando las capacidades genéricas de los recursos como si
representara las funciones reales.
Diagrama
ABSTRACT FACTORY
Top. En Software Página 6
CAPITULO I
ABSTRACT FACTORY
1.1. Modelo
Se pueden observar los siguientes partícipes:
FabricaAbstracta define el interfaz a cumplir por cualquier fábrica, es decir la creación de productos de diferentes tipos.
Fabrica1 y Fabrica2 son las clases concretas que fabrican los productos definidos en el interfaz para cada una de las familias.
ProductoAbstractoA y ProductoAbstractoB son los interfaces de los productos con independencia de las familias de los mismos, de este modo el Cliente puede manejar los productos sin conocer la familia del mismo.
ProductoA1, ProductoA2, ProductoB1 y ProductoB2 son los productos finales creados por las fábricas concretas (Fabrica1 yFabrica2).
Cliente es la clase (o conjunto de ellas) que sin conocer las familias de productos (1 y 2) son capaces de interactuar con todos ellos (A y B), y de construirlos gracias al interfaz común de construcción de FabricaAbstracta.
ABSTRACT FACTORY
Top. En Software Página 7
1.2. Relación con otros patrones
Fábrica Abstracta. El método fábrica permite crear objetos individuales que tengan
un comportamiento específico porque la clase delega a sus subclases la
implementación del comportamiento, pero únicamente trabaja con una jerarquía de
clases. Si nos vemos en la necesidad de utilizar más de una jerarquía de clases
entonces debemos utilizar fábrica abstracta.
Método Plantilla. Normalmente ambos patrones se utilizan de forma conjunta, esto
se debe a que el método plantilla utiliza una clase abstracta que provee una parte de
la lógica, proveyendo la implementación faltante en las subclases que redefinen los
métodos faltantes. Para poder lograr una funcionalidad puede ser necesario que una
parte de la misma se encuentre en la clase abstracta y la otra parte en las subclases
que heredan de ella.
Prototipo. El método prototipo permite utilizar objetos sin saber cuáles son los
detalles de su implementación, por lo que puede ser utilizado con una clase que
provea un método fábrica.
1.3. Características
El método fábrica elimina la necesidad de que el cliente se comunique con los
creadores concretos, que solo debe comunicarse con la interfaz del producto por lo
que no debe trabajar con las clases concretas.
Es más flexible la creación de objetos a través del método fábrica de una clase, que
crearlos de forma directa. El método fábrica proporciona a las subclases una forma de
proveer una versión extendida de la clase.
Permite la conexión de jerarquías de clases que son paralelas, las jerarquías de clase
aparecen cuando una clase delega determinadas responsabilidades a sus subclases, el
patrón de método fábrica permite definir la conexión existente entre las jerarquías de
clase, permitiendo identificar fácilmente que clases están correlacionadas.
ABSTRACT FACTORY
Top. En Software Página 8
1.4. Implementación
Primero declaramos una clase abstracta llamada Creador, la cual contendrá el método fábrica.
El método fábrica es el que decidirá cuál de los objetos deberá devolver el método, para tomar
esa decisión utilizamos un par de bloques if.
El método devuelve un tipo Creador que puede contener a cualquiera de las subclases que
tienen delegada la responsabilidad de implementar el comportamiento específico. Para poder
identificar si se trata de la clase padre o de las subclases redefinimos el método publico
toString para que nos devuelva un String que nos permita identificar si se trata de la
superclase o de las subclases.
ABSTRACT FACTORY
Top. En Software Página 9
Ahora extendemos la superclase creador con dos subclases llamadas A y B que redefinen el
método toString proporcionando un comportamiento diferente al de su clase padre.
Por último creamos una clase llamada ProbarMetodoFabrica en la cual crearemos dos
variables de tipo Creador, la primera mandará el String “A” como argumento al método
fábrica, mientras que la segunda mandará “B” como argumento. El método fábrica
dependiendo del argumento que recibe mandará un objeto diferente cambiando con ello el
comportamiento del objeto. Para comprobar que son dos objetos diferentes los
imprimiremos, con lo que se llamará al método redefinido toString.
El resultado de la ejecución es el siguiente: A B
Con esto podemos ver que el mismo método nos devuelve un objeto diferente, dependiendo
de la forma en que implementemos el método fábrica. El que el método fábrica nos devuelva
un objeto diferente es lo que nos permite cambiar el comportamiento del objeto. Realmente
no sé cambia el comportamiento del objeto, sino que se utilizan objetos diferentes con
comportamientos diferentes, los cuáles seleccionamos a través del método fábrica
dependiendo de las necesidades que tengamos.
Ahora ajustaremos aplicaremos el patrón a un ejemplo sencillo que nos devuelve una figura
geométrica diferente para poder con mayor claridad cómo cambia el comportamiento del
objeto.
ABSTRACT FACTORY
Top. En Software Página 10
En la clase abstracta Figura declaramos un método abstracto llamado imprimir el cual es
redefinido por las subclases Circulo y Triangulo.
Cuando el método estático crearFigura es invocado por el cliente si el parámetro recibido fue
un circulo devuelve un objeto tipo círculo, lo mismo pasa con triangulo.
La clase ProbarMetodoFabricaFiguras actúa como cliente consumiendo la funcionalidad que
proporciona la clase Figura. Lo que hacemos es crear dos objetos de tipo figura, el primero
contiene un objeto del tipo circulo y el segundo uno del tipo triangulo, ambos tienen en común
el método imprimir heredado de su superclase. Como puede observarse se modifica el
comportamiento del objeto utilizando un objeto diferente dependiendo del comportamiento
que necesitamos que tenga. Ahora realicemos los cambios adecuados a nuestro diagrama.
ABSTRACT FACTORY
Top. En Software Página 11
El método abstracto imprimir de la clase padre es implementado por las subclases Circulo y
Triangulo, las cuáles son instanciadas por la superclase. Las subclases son las que se encargan
del comportamiento que deberá tener la superclase. Las instancias específicas del cliente son
las responsables de la manipulación de las subclases utilizando de ellas los métodos que
necesitan permitiendo mantener una adecuada comunicación entre la jerarquía de las clases
del cliente y la de la clase que implementa el método fábrica.
1.5. Ventajas en Inconvenientes
Ventajas:
Una fábrica ayuda a incrementar la flexibilidad general de una aplicación. Esta
flexibilidad se manifiesta tanto en tiempo de ejecución como en tiempo de
compilación. Durante el diseño, no hay que predecir todos los usos futuros de la
aplicación. En su lugar se crea un framework general entonces se desarrollan
implementaciones independientes del resto de la aplicación. En tiempo de ejecución,
la aplicación puede integrar fácilmente nuevas características y recursos.
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.
Hace fácil el intercambio de familias de productos. Solo necesitaremos cambiar de
factory.
Fomenta la consistencia entre productos.
Desventajas:
Para añadir unos nuevos productos, se requiere la implementación del interfaz y todos
sus métodos.
Y por fin hemos llegado al código. Vamos a implementar una pequeña imprenta y los
servicios que esta ofrece: Impresión a color, impresión en blanco y negro, y diseño de
carteles.
ABSTRACT FACTORY
Top. En Software Página 12
Conclusiones
Tal y como puede apreciarse, si en algún momento tenemos que expandir nuestro sistema, esto se puede hacer fácilmente y sobre todo de manera desacoplada:
Expandiendo por arquitectura: si queremos dar cabida a un nuevo framework gráfico, no tendremos más que crear una nueva fábrica concreta que construya los productos para la nueva arquitectura, así como crear una particularización de dicha arquitectura para cada producto. El cliente no necesita cambiar en nada, dado que los interfaces de construcción y de manejo del producto no se han alterado.
Expandiendo por producto: si lo que queremos es añadir otro producto (por ejemplo una ventana, un botón), sólo tendremos que crear el Producto abstracto nuevo, así como sus clases concretas para cada arquitectura, y añadir un nuevo método para crear dicho producto en el interfaz de la fábrica abstracta e implementarlo en las clases de fábricas concretas. En este caso el cliente obviamente cambia dado que hay un nuevo producto que puede utilizar.
Bibliografía
Gamma, E., Helm, R., Johnson, R., y Vlissides, J.: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley (1995)
http://www.dosideas.com/wiki/Abstract_Factory http://www.programadorphp.org/blog/patrones-de-diseno-elementos-reutilizables-
para-la-web/ http://antares.itmorelia.edu.mx/~jcolivar/courses/dp07a/patrones.pdf http://gresh-ross.blogspot.es/ http://www.fdi.ucm.es/profesor/fpeinado/courses/oop/LPS-06IntroPatrones-B&N.pdf http://www.fdi.ucm.es/profesor/jpavon/poo/2.14PDOO.pdf http://msdn.microsoft.com/es-mx/library/bb972258.aspx#EDAA http://www.apwebco.com/gofpatterns/creational/AbstractFactory.html http://msdn.microsoft.com/es-es/library/bb972258.aspx#EDAA http://arantxa.ii.uam.es/~eguerra/docencia/0708/04%20Creacion.pdf http://astreo.ii.uam.es/~jlara/TACCII/8_Patrones.pdf http://codejavu.blogspot.com/2013/07/ejemplo-patron-abstract-factory.html http://quegrande.org/apuntes/EI/4/DSI/teoria/09-10/fabrica_abstracta.pdf