0% encontró este documento útil (0 votos)
6 vistas3 páginas

Patrón de Diseño: Fábrica Abstracta

Este patrón de diseño permite crear familias de objetos relacionados sin especificar sus clases concretas. Se utiliza cuando se necesitan crear diferentes tipos de objetos pero su interfaz debe ser independiente de estas diferencias.

Cargado por

zulix69
Derechos de autor
© All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como TXT, PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
6 vistas3 páginas

Patrón de Diseño: Fábrica Abstracta

Este patrón de diseño permite crear familias de objetos relacionados sin especificar sus clases concretas. Se utiliza cuando se necesitan crear diferentes tipos de objetos pero su interfaz debe ser independiente de estas diferencias.

Cargado por

zulix69
Derechos de autor
© All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como TXT, PDF, TXT o lee en línea desde Scribd

Abstract Factory

Ir a la navegaci�nIr a la b�squeda
Abstract Factory (F�brica Abstracta) es un patr�n de dise�o para el desarrollo de
software.

�ndice
1 Contexto y problema
2 Aspecto est�tico
3 Un ejemplo
4 V�ase tambi�n
5 Enlaces externos
Contexto y problema
Contexto: Debemos crear diferentes objetos, todos pertenecientes a la misma
familia. Por ejemplo: las bibliotecas para crear interfaces gr�ficas suelen
utilizar este patr�n y cada familia ser�a un sistema operativo distinto. As� pues,
el usuario declara un Bot�n, pero de forma m�s interna lo que est� creando es un
Bot�nWindows o un Bot�nLinux, por ejemplo.

El problema que intenta solucionar este patr�n es el de crear diferentes familias


de objetos.

El patr�n Abstract Factory est� aconsejado cuando se prev� la inclusi�n de nuevas


familias de productos, pero puede resultar contraproducente cuando se a�aden nuevos
productos o cambian los existentes, puesto que afectar�a a todas las familias
creadas.

Aspecto est�tico
Diagrama Abstract [Link]

La estructura t�pica del patr�n Abstract Factory es la siguiente:

Cliente: La clase que llamar� a la factor�a adecuada ya que necesita crear uno de
los objetos que provee la factor�a, es decir, Cliente lo que quiere es obtener una
instancia de alguno de los productos (ProductoA, ProductoB).
AbstractFactory: Es la definici�n de la interfaces de las factor�as. Debe de
proveer un m�todo para la obtenci�n de cada objeto que pueda crear.
("crearProductoA()" y "crearProductoB()")
Factor�as Concretas: Estas son las diferentes familias de productos. Provee de la
instancia concreta de la que se encarga de crear. De esta forma podemos tener una
factor�a que cree los elementos gr�ficos para Windows y otra que los cree para
Linux, pudiendo poner f�cilmente (creando una nueva) otra que los cree para MacOS,
por ejemplo.
Producto abstracto: Definici�n de las interfaces para la familia de productos
gen�ricos. En el diagrama son "ProductoA" y "ProductoB". En un ejemplo de
interfaces gr�ficas podr�an ser todos los elementos: Bot�n, Ventana, Cuadro de
Texto, Combo... El cliente trabajar� directamente sobre esta interfaz, que ser�
implementada por los diferentes productos concretos.
Producto concreto: Implementaci�n de los diferentes productos. Podr�a ser por
ejemplo "Bot�nWindows" y "Bot�nLinux". Como ambos implementan "Bot�n" el cliente no
sabr� si est� en Windows o Linux, puesto que trabajar� directamente sobre la
superclase o interfaz.
Un ejemplo
Veremos un ejemplo did�ctico y basado en el libro Head First Design Patterns, de
O'Reilly.

Supongamos que disponemos de una cadena de pizzer�as. Para crear pizzas disponemos
de un m�todo abstracto en la clase Pizzer�a que ser� implementada por cada subclase
de Pizzer�a.

abstract Pizza crearPizza()


Concretamente se crear� una subclase de Pizzer�a por cada zona, por ejemplo la
Pizzer�a de New York ser�a PizzeriaNewYork y la de Californ�a Pizzer�aCalifornia
que implementar�n el m�todo con los ingredientes de sus zonas.

Las pizzas son diferentes seg�n las zonas. No es igual la pizza de New York que la
pizza de California. Igualmente, aunque usar�n los mismos ingredientes (tomate,
mozzarella...) no los obtendr�n del mismo lugar, cada zona los comprar� donde lo
tenga m�s cerca. As� pues podemos crear un m�todo creador de Pizza que sea

Pizza(FactoriaIngredientes fi);
Como vemos utilizamos la factor�a abstracta (no las concretas de cada zona, como
podr�a ser IngredientesNewYork o IngredientesCalifornia). Pizza podr� obtener los
ingredientes de la factor�a independientemente de donde sea. Ser�a f�cil crear
nuevas factor�as y a�adirlas al sistema para crear pizzas con estos nuevos
ingredientes. Efectivamente, en este ejemplo cliente es Pizza y es independiente de
la Factor�a usada.

El creador de la Pizza ser� el encargado de instanciar la factor�a concreta, as�


pues los encargados de instanciar las factor�as concretas ser�n las pizzer�as
locales. En Pizzer�aNewYork podemos tener el m�todo crearPizza() que realice el
siguiente trabajo:

Pizza crearPizza() {
Factor�aIngredientes fi = new IngredientesNewYork();
Pizza pizza = new Pizza(fi); // Uso de la factor�a
[Link]();
[Link]();
return pizza;
}
Como conclusi�n podemos observar que gracias a la factor�a de ingredientes crear
una nueva zona, por ejemplo una pizzer�a en Barcelona, no nos implicar�a estar
modificando el c�digo existente, solo deberemos extenderlo (uno de los pilares de
la Ingenier�a del software) ya crear�amos la subclase de Pizzer�a:
Pizzer�aBarcelona que al instanciar la factor�a solo deber�a escoger la factor�a de
Barcelona. Obviamente se deber�a crear la factor�a de Barcelona que se encargar�a
de crear los productos obtenidos de Barcelona. As� que en ning�n momento
modificamos las pizzer�as existentes, la superclase pizzer�a o las otras factor�as
o productos, solo creamos nuevas clases.

V�ase tambi�n
Factory Method
Enlaces externos
Patr�n Abstract Factory con UML
Patrones de Fabricaci�n: F�bricas de Objetos - Le�n Welicki
Ejemplo en Java con Diagrama UML
Ejemplo en C# con Diagrama UML (en ingl�s)
Categor�a: Patrones de dise�o
Men� de navegaci�n
No has accedidoDiscusi�nContribucionesCrear una
cuentaAccederArt�culoDiscusi�nLeerEditarVer historialBuscar
Buscar en Wikipedia
Portada
Portal de la comunidad
Actualidad
Cambios recientes
P�ginas nuevas
P�gina aleatoria
Ayuda
Donaciones
Notificar un error
En otros proyectos
Wikimedia Commons
Imprimir/exportar
Crear un libro
Descargar como PDF
Versi�n para imprimir
Herramientas
Lo que enlaza aqu�
Cambios en enlazadas
Subir archivo
P�ginas especiales
Enlace permanente
Informaci�n de la p�gina
Elemento de Wikidata
Citar esta p�gina

En otros idiomas
Catal�
Deutsch
English
Fran�ais
Galego
???
Portugu�s
???????
??
13 m�s
Editar enlaces
Esta p�gina se edit� por �ltima vez el 21 may 2019 a las 22:10.
El texto est� disponible bajo la Licencia Creative Commons Atribuci�n Compartir
Igual 3.0; pueden aplicarse cl�usulas adicionales. Al usar este sitio, usted acepta
nuestros t�rminos de uso y nuestra pol�tica de privacidad.
Wikipedia� es una marca registrada de la Fundaci�n Wikimedia, Inc., una
organizaci�n sin �nimo de lucro.
Pol�tica de privacidadAcerca de WikipediaLimitaci�n de
responsabilidadDesarrolladoresDeclaraci�n de cookiesVersi�n para m�vilesWikimedia
Foundation Powered by MediaWiki

También podría gustarte