13
UNIVERSIDAD NACIONAL DE TRUJILLO INTEGRANTES: Acate Venegas Karen Sofía Castro Reyna Frank Peter Iwamatsu moreno Luis Fernando 2014 [ABSTRACT FACTORY]

Abstract factory

Embed Size (px)

Citation preview

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