SlideShare una empresa de Scribd logo
2014
UNIVERSIDAD NACIONAL
DE TRUJILLO

[ABSTRACT FACTORY]

INTEGRANTES:





Acate Venegas Karen Sofía
Castro Reyna Frank Peter
Iwamatsu moreno Luis Fernando
ABSTRACT FACTORY

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

Top. En Software

Página 1
ABSTRACT FACTORY

DEDICATORIA

A nuestros padres por el apoyo incondicional en lo que nos proponemos.

Top. En Software

Página 2
ABSTRACT FACTORY

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”.

Top. En Software

Página 3
ABSTRACT FACTORY
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.

Top. En Software

Página 4
ABSTRACT FACTORY
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

Top. En Software

Página 5
ABSTRACT FACTORY
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.

Top. En Software

Página 6
ABSTRACT FACTORY

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.

Top. En Software

Página 7
ABSTRACT FACTORY
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.

Top. En Software

Página 8
ABSTRACT FACTORY

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.
Top. En Software

Página 9
ABSTRACT FACTORY

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.

Top. En Software

Página 10
ABSTRACT FACTORY

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.

Top. En Software

Página 11
ABSTRACT FACTORY

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-reutilizablespara-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

Top. En Software

Página 12

Más contenido relacionado

La actualidad más candente

Diagramas UML
Diagramas UMLDiagramas UML
Diagramas UML
1da4
 
Cuarta forma normal y quinta forma normal
Cuarta forma normal y quinta forma normalCuarta forma normal y quinta forma normal
Cuarta forma normal y quinta forma normal
Memo Wars
 
Programación MySQL-Ejercicios
Programación MySQL-EjerciciosProgramación MySQL-Ejercicios
Programación MySQL-Ejerciciostestgrupocomex
 
Fundamentos de las bases de datos
Fundamentos de las bases de datosFundamentos de las bases de datos
Fundamentos de las bases de datos
Jaime David Romero Olivo
 
Modelo Entidad Relacion
Modelo Entidad RelacionModelo Entidad Relacion
Diagrama UML de Clases
Diagrama UML de ClasesDiagrama UML de Clases
Diagrama UML de Clases
Adal Dg
 
MODELO RELACIONAL
MODELO RELACIONALMODELO RELACIONAL
MODELO RELACIONAL
ELSER TARRILLO TORRES
 
Diagramas de implementacion
Diagramas de implementacionDiagramas de implementacion
Diagramas de implementacion
ZonickX
 
Algebra relacional
Algebra relacionalAlgebra relacional
Algebra relacionalLuis Jherry
 
Rational rose
Rational roseRational rose
Rational rose
Israel Chava Gonzales
 
Transformar modelo entidad relacion a modelo logico
Transformar modelo entidad relacion a modelo logicoTransformar modelo entidad relacion a modelo logico
Transformar modelo entidad relacion a modelo logicojosecuartas
 
Requerimiento funcional y no funcional
Requerimiento funcional y no funcional Requerimiento funcional y no funcional
Requerimiento funcional y no funcional
CristobalFicaV
 
Algebra relacional
Algebra relacionalAlgebra relacional
Algebra relacional
claudyabra
 
TIPOS DE BASE DE DATOS
TIPOS DE BASE DE DATOSTIPOS DE BASE DE DATOS
TIPOS DE BASE DE DATOS
UNIVERSIDAD NACIONAL DEL CALLAO
 
Diagrama componentes
Diagrama componentesDiagrama componentes
Diagrama componentes
marianela0393
 
Ingeniería web_Unidad 3
Ingeniería web_Unidad 3Ingeniería web_Unidad 3
Ingeniería web_Unidad 3
Gerónimo Hernández Martínez
 
Taxonomia de las herramientas case
Taxonomia de las herramientas caseTaxonomia de las herramientas case
Taxonomia de las herramientas caseisidro luna beltran
 

La actualidad más candente (20)

Diagramas UML
Diagramas UMLDiagramas UML
Diagramas UML
 
Cuarta forma normal y quinta forma normal
Cuarta forma normal y quinta forma normalCuarta forma normal y quinta forma normal
Cuarta forma normal y quinta forma normal
 
Programación MySQL-Ejercicios
Programación MySQL-EjerciciosProgramación MySQL-Ejercicios
Programación MySQL-Ejercicios
 
Base de datos distribuidos
Base de datos distribuidosBase de datos distribuidos
Base de datos distribuidos
 
Fundamentos de las bases de datos
Fundamentos de las bases de datosFundamentos de las bases de datos
Fundamentos de las bases de datos
 
Modelo Entidad Relacion
Modelo Entidad RelacionModelo Entidad Relacion
Modelo Entidad Relacion
 
Diagrama UML de Clases
Diagrama UML de ClasesDiagrama UML de Clases
Diagrama UML de Clases
 
MODELO RELACIONAL
MODELO RELACIONALMODELO RELACIONAL
MODELO RELACIONAL
 
Diagramas de implementacion
Diagramas de implementacionDiagramas de implementacion
Diagramas de implementacion
 
Algebra relacional
Algebra relacionalAlgebra relacional
Algebra relacional
 
Rational rose
Rational roseRational rose
Rational rose
 
Transformar modelo entidad relacion a modelo logico
Transformar modelo entidad relacion a modelo logicoTransformar modelo entidad relacion a modelo logico
Transformar modelo entidad relacion a modelo logico
 
Requerimiento funcional y no funcional
Requerimiento funcional y no funcional Requerimiento funcional y no funcional
Requerimiento funcional y no funcional
 
Roles desarrollo del software
Roles desarrollo del softwareRoles desarrollo del software
Roles desarrollo del software
 
Algebra relacional
Algebra relacionalAlgebra relacional
Algebra relacional
 
TIPOS DE BASE DE DATOS
TIPOS DE BASE DE DATOSTIPOS DE BASE DE DATOS
TIPOS DE BASE DE DATOS
 
Diagrama componentes
Diagrama componentesDiagrama componentes
Diagrama componentes
 
Ingeniería web_Unidad 3
Ingeniería web_Unidad 3Ingeniería web_Unidad 3
Ingeniería web_Unidad 3
 
modelo entidad-relacion
modelo entidad-relacionmodelo entidad-relacion
modelo entidad-relacion
 
Taxonomia de las herramientas case
Taxonomia de las herramientas caseTaxonomia de las herramientas case
Taxonomia de las herramientas case
 

Destacado

Patrones de diseño
Patrones de diseñoPatrones de diseño
Patrones de diseño
aguilarlupitas
 
Abstract Factory
Abstract FactoryAbstract Factory
Abstract Factory
Diego Calderon
 
Patrones de diseño Singleton
Patrones de diseño SingletonPatrones de diseño Singleton
Patrones de diseño SingletonCarolina Rojas
 
Plataformas de desarrollo web
Plataformas de desarrollo webPlataformas de desarrollo web
Plataformas de desarrollo web
Genesis Jurado
 
Patrones de diseño I
Patrones de diseño IPatrones de diseño I
Patrones de diseño Ikaolong
 
PATRONES DE DISEÑO WEB
PATRONES DE DISEÑO WEBPATRONES DE DISEÑO WEB
PATRONES DE DISEÑO WEB
Mario Martinez
 

Destacado (7)

Patrones de diseño
Patrones de diseñoPatrones de diseño
Patrones de diseño
 
Patron creacional singleton
Patron creacional singletonPatron creacional singleton
Patron creacional singleton
 
Abstract Factory
Abstract FactoryAbstract Factory
Abstract Factory
 
Patrones de diseño Singleton
Patrones de diseño SingletonPatrones de diseño Singleton
Patrones de diseño Singleton
 
Plataformas de desarrollo web
Plataformas de desarrollo webPlataformas de desarrollo web
Plataformas de desarrollo web
 
Patrones de diseño I
Patrones de diseño IPatrones de diseño I
Patrones de diseño I
 
PATRONES DE DISEÑO WEB
PATRONES DE DISEÑO WEBPATRONES DE DISEÑO WEB
PATRONES DE DISEÑO WEB
 

Similar a Abstract factory

Abstract factory. presentación
Abstract factory. presentaciónAbstract factory. presentación
Abstract factory. presentación
avidal020
 
Abstract factory. presentación
Abstract factory. presentaciónAbstract factory. presentación
Abstract factory. presentaciónavidal020
 
Taller patrones de diseño
Taller patrones de  diseñoTaller patrones de  diseño
Taller patrones de diseño
tovar1982
 
Patrones de diseño - Daniel E. Jaramillo
Patrones de diseño - Daniel E. JaramilloPatrones de diseño - Daniel E. Jaramillo
Patrones de diseño - Daniel E. Jaramillo2008PA2Info3
 
Presentacion Patrones Creacionales
Presentacion Patrones CreacionalesPresentacion Patrones Creacionales
Presentacion Patrones Creacionales
Sergio David Fernández
 
Patrones de diseño de GoF
Patrones de diseño de GoFPatrones de diseño de GoF
Patrones de diseño de GoF
Yaskelly Yedra
 
Patrones de-diseño-mañana
Patrones de-diseño-mañanaPatrones de-diseño-mañana
Patrones de-diseño-mañana
ale abad aguilar
 
Patrones De DiseñO
Patrones De DiseñOPatrones De DiseñO
Patrones De DiseñO
gueste39de6
 
Patrones de diseño - Henry Vallejo
Patrones de diseño - Henry VallejoPatrones de diseño - Henry Vallejo
Patrones de diseño - Henry Vallejo2008PA2Info3
 
Patrones de diseño - Andrés Dorado
Patrones de diseño - Andrés DoradoPatrones de diseño - Andrés Dorado
Patrones de diseño - Andrés Dorado2008PA2Info3
 
Transparencias_Patrones.ppt
Transparencias_Patrones.pptTransparencias_Patrones.ppt
Transparencias_Patrones.ppt
BenaventeSolorzanoCa
 
Programacion Orientada a Objetos IE
Programacion Orientada a Objetos IEProgramacion Orientada a Objetos IE
Programacion Orientada a Objetos IE
Karen Olan
 
Patrones de diseño
Patrones de diseñoPatrones de diseño
Patrones de diseño
Juanes Alzt
 
Unidad II_1.pptx
Unidad II_1.pptxUnidad II_1.pptx
Unidad II_1.pptx
Arigol15Gomez
 
Gestor de Base de Datos
Gestor de Base de DatosGestor de Base de Datos
Gestor de Base de Datos
Christian Collaguazo Malla
 
Patrones de diseño
Patrones de diseñoPatrones de diseño
Patrones de diseño
Israel Rey
 

Similar a Abstract factory (20)

Abstract factory. presentación
Abstract factory. presentaciónAbstract factory. presentación
Abstract factory. presentación
 
Abstract Factory
Abstract FactoryAbstract Factory
Abstract Factory
 
Abstract factory. presentación
Abstract factory. presentaciónAbstract factory. presentación
Abstract factory. presentación
 
Taller patrones de diseño
Taller patrones de  diseñoTaller patrones de  diseño
Taller patrones de diseño
 
Patrones
PatronesPatrones
Patrones
 
Patrones de diseño - Daniel E. Jaramillo
Patrones de diseño - Daniel E. JaramilloPatrones de diseño - Daniel E. Jaramillo
Patrones de diseño - Daniel E. Jaramillo
 
Presentacion Patrones Creacionales
Presentacion Patrones CreacionalesPresentacion Patrones Creacionales
Presentacion Patrones Creacionales
 
Patrones de diseño de GoF
Patrones de diseño de GoFPatrones de diseño de GoF
Patrones de diseño de GoF
 
Patrones de-diseño-mañana
Patrones de-diseño-mañanaPatrones de-diseño-mañana
Patrones de-diseño-mañana
 
Patrones De DiseñO
Patrones De DiseñOPatrones De DiseñO
Patrones De DiseñO
 
Patrones de diseño - Henry Vallejo
Patrones de diseño - Henry VallejoPatrones de diseño - Henry Vallejo
Patrones de diseño - Henry Vallejo
 
Patrones de diseño - Andrés Dorado
Patrones de diseño - Andrés DoradoPatrones de diseño - Andrés Dorado
Patrones de diseño - Andrés Dorado
 
Transparencias_Patrones.ppt
Transparencias_Patrones.pptTransparencias_Patrones.ppt
Transparencias_Patrones.ppt
 
Programacion Orientada a Objetos IE
Programacion Orientada a Objetos IEProgramacion Orientada a Objetos IE
Programacion Orientada a Objetos IE
 
Decorator
DecoratorDecorator
Decorator
 
Patrones de diseño
Patrones de diseñoPatrones de diseño
Patrones de diseño
 
Unidad II_1.pptx
Unidad II_1.pptxUnidad II_1.pptx
Unidad II_1.pptx
 
Gestor de Base de Datos
Gestor de Base de DatosGestor de Base de Datos
Gestor de Base de Datos
 
Conceptos poo
Conceptos pooConceptos poo
Conceptos poo
 
Patrones de diseño
Patrones de diseñoPatrones de diseño
Patrones de diseño
 

Abstract factory

  • 1. 2014 UNIVERSIDAD NACIONAL DE TRUJILLO [ABSTRACT FACTORY] INTEGRANTES:    Acate Venegas Karen Sofía Castro Reyna Frank Peter Iwamatsu moreno Luis Fernando
  • 2. ABSTRACT FACTORY 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 Top. En Software Página 1
  • 3. ABSTRACT FACTORY DEDICATORIA A nuestros padres por el apoyo incondicional en lo que nos proponemos. Top. En Software Página 2
  • 4. ABSTRACT FACTORY 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”. Top. En Software Página 3
  • 5. ABSTRACT FACTORY 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. Top. En Software Página 4
  • 6. ABSTRACT FACTORY 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 Top. En Software Página 5
  • 7. ABSTRACT FACTORY 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. Top. En Software Página 6
  • 8. ABSTRACT FACTORY 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. Top. En Software Página 7
  • 9. ABSTRACT FACTORY 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. Top. En Software Página 8
  • 10. ABSTRACT FACTORY 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. Top. En Software Página 9
  • 11. ABSTRACT FACTORY 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. Top. En Software Página 10
  • 12. ABSTRACT FACTORY 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. Top. En Software Página 11
  • 13. ABSTRACT FACTORY 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-reutilizablespara-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 Top. En Software Página 12