Entrando en materia vamos a empezar con los patrones. Para todo aquel que esté intentando seguir el libro, observará que me he saltado una sección, más concretamente, la del caso de estudio. Aunque la sección no está mal ni mucho menos (me la he leído únicamente por encima), creo que no tiene lugar en el objetivo de esta serie de artículos, y por este motivo, la he saltado. Pero os animo a que si estáis siguiendo el libro, hagáis una pequeña pausa antes de continuar leyendo este artículo y os lo leáis antes de seguir.

El primero de los patrones que vamos a ver es el “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. 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. Otro nombre que recibe es el de “Kit”. Personalmente, nunca había oído este nombre, pero en el libro aparece y no está de más nombrarlo (lo que dije al principio, hay que saber cómo se nombran las cosas y no solo que son). Lo que busca el patrón es ofrecer la posibilidad de trabajar con varios objetos diferentes aunque relacionados y facilitar la adhesión de nuevos objetos relacionados en un futuro para cubrir nuevas necesidades.

Como ejemplo, vamos a coger el mencionado sistema de widgets para la creación de una aplicación cliente. El problema al que nos enfrentamos a la hora de realizar una implementación, es que queremos soportar múltiples estándares, y en un futuro, quizás, añadir nuevos. Con esto la aplicación cliente no puede crear un objeto concreto:

StndAMenuBar nemu = new StdnAMenuBar();

Las aplicaciones clientes deberían trabajar con objetos y clases genéricas abstrayéndose de la implementación concreta:

MenuBar menu = Menu.createMenuBar();

De esta forma, conseguiremos que nuestro sistema sea:

• Independiente de los procesos de creación, composición y representación de sus productos.
• Configurable para una familia de productos
• Solo necesitará proporcionar una librería de productos y no su implementación.

Así los elementos en nuestro desarrollo serán:

• AbstractFactory: Interfaz para las operaciones de creación de productos abstractos.
• ConcreteFactory: Implementa las operaciones para la creación de objetos de productos concretos
• AbstractProduct: Declara una interfaz para los objetos de un tipo de productos.
• ConcreteProduct: Define un objeto de producto que creará la correspondiente Concrete Factory , a la vez que implementa la interfaz de AbstractProduct.
• Client: Será el que utilice nuestras clases abstractas.

Lo se, no os habéis enterado de nada y estáis mirando el monitor con cara de pocos amigos. No os preocupéis, seguid en vuestra mente con la frase inicial que dijimos íbamos a recordar y repasad este apartado de nuevo cuando estéis viendo el ejemplo de código.

Pero antes de pasar al código, solo un par de anotaciones sobre algunas ventajas y desventajas.

Ventajas:

• 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 un nuevo productos, se requiere la implementación de el 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.

Para ello vamos a implementar en primer lugar nuestro interfaz que implementarán nuestros diferentes servicios:

public interface Servicio {
    public void codigoDeServicio();
}

Ahora vamos a crear la interfaz encargada de la creación de servicios:

public interface ServicioDeImpresion {
    public Servicio crearServicio();
}

Ahora crearemos los tres servicios que ofrece nuestra imprenta:

public class ServicioColor implements Servicio {
    public void codigoDeServicio() { return COLOR; }
}

public class ServicioBandW implements Servicio {
    public void codigoDeServicio() { return B_AND_W; }
}

public class ServicioDesign implements Servicio {
    public void codigoDeServicio() { return DESIGN; }
}

Ahora vamos a crear las Factory para cada uno de los servicios:

public class ColorFactory implements ServicioDeImpresion {
    public Servicio crearServicio() { return new ServicioColor(); }
}

public class BandWFactory implements ServicioDeImpresion {
    public Servicio crearServicio() { return new ServicioBandW(); }
}

public class DesignFactory implements ServicioDeImpresion {
    public Servicio crearServicio() { return new ServicioDesign(); }
}

Finalmente, lo utilizamos en un ejemplo que creará una Factory del tipo que le pasemos como parámetro:

public class MainFactory {
    public static void createFactory(ServicioDeImpresion factoria) {
        Servicio s = factoria.crearServicio();
        int c = s.codigoDeServicio();
        ...
    }
}

Con esto tendríamos implementado nuestro patrón Abstract Factory.

Buenos, espero que os hayáis aclarado, si tenéis cualquier duda, ya sabéis, dejad un comentario. Nos vemos.