Patrón de diseño Fábrica Abstracta


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 senior, 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á).

Fábrica Abstracta

El patrón de diseño Fábrica Abstracta se utiliza para proporcionar una interfaz común para crear una serie de objetos (productos) bajo una u otra arquitectura o framework, sin que los clientes de dichos productos tengan que tener conocimiento de la arquitectura elegida para implemetar cada familia de productos.

Modelo

El siguiente diagrama de clases expone el patrón de diseño:

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 y Fabrica2).
  • 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.

Caso de ejemplo

En el siguiente ejemplo seguro que nos queda todo un poco más claro. Como puede verse se trata de proporcionar 2 tipos de arquitecturas para la creación de componentes visuales, uno con Motif y el otro con WxWidgets, los productos a crear son controles de Imagen y Texto:

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.

Espero que os haya servido de utilidad, no dudéis en consultarme sobre este patrón de diseño y de cómo podéis aplicarlo.

, , , , , , , , ,

  1. #1 by Angel on 2010/10/19 - 19:32

    Que tal camarada.

    Bueno mil gracias por responder, tratare de trabajar un poco mas en esto de los patrones de diseño, es un poco complicado pero si creo poder entenderlo. se ve interezante por lo poco que logro entender.

    que estes muy bien

  2. #2 by Angel on 2010/10/16 - 02:47

    no le entiendo nada camarada y me toca exponer sobre este patron de diseño
    me podrias proporcinal algunos ejemplo para asi entenderlo mejor, soy nuevo en esto de programacion orientada a objetos y mucho mas con los patrones de diseño

    • #3 by Emilio González Montaña on 2010/10/16 - 10:09

      Mucho me temo que no hay atajo sin trabajo, estudia, no hay otro modo, uno no puede intentar entender un patrón de diseño sin saber orientación a objetos, que es la base.

      Es cómo si un constructor de casas quisiera hacer una catedral sin saber ni hacer una casa pequeña antes…

(No será publicado)