Abstract Factory

Abstract Factory es un patrón de diseño que separa la creación de un objeto (o una familia de objetos relacionados) del uso del objeto de manera tal que un cliente que requiera el objeto solicita la creación del mismo a un Factory (factoría) sin tener que especificar la clase concreta del objeto que requiere. La decisión del tipo del objeto a crear está encapsulada en el Factory.

Cuando un cliente requiere objeto de tipo “ProductoA” (que es una interfaz), lo solicita a una implementación de la factoría, por ejemplo “Factoría Concreta 1”, que es la responsable de proveer una instancia de una clase que implementa la interfaz “ProductoA”. Gracias a este patrón de diseño, el nombre de la clase concreta que implementa la interfaz está completamente encapsulado en la implementación de la factoría; el cliente, desconoce el nombre de la clase concreta de la instancia que recibe de la factoría.

Este patrón es muy útil para mantener la inversión de dependencias entre los módulos que contienen las abstracciones de alto nivel (reglas de negocios y/o casos de uso, por ejemplo) y los módulo encargados de la construcción de las clases que implementan las abstracciones definidas en los módulos más abstractos. En otras palabras, con éste patrón de diseño es posible que un módulo solicite la creación de los objetos que requiere sin tener dependencias de código fuente con dichos objetos.

La ejecución de la lógica de negocios de una aplicación y la construcción de misma son responsabilidades que deberían estar asignadas a módulos diferentes con las implementaciones de las factorías incluidas en los módulos que construyen/inicializan un sistema (módulos “main”):

AbstractFactory e Inyección de dependencias

Los frameworks para inyección de dependencias y el patrón AbtractFactory pueden complementarse de manera tal que estos frameworks se empleen como los mecanismos de creación de objetos en diferentes implementaciones del Factory; es decir, podemos tener factorías basadas en Spring o factorías basadas en Google Guice. De esta manera, es posible evitar que módulos abstractos tengan dependencias de código fuente con estos frameworks.

Limitaciones

Una de las limitaciones tiene que ver con el estado en el cuál se crean los objetos; es decir, con este patrón de diseño y otros similares, se brinda al cliente la posibilidad de solicitar la creación de un objeto pero (al menos en la versión inicialmente propuesta) no incluye un mecanismo para inicializar el estado del objeto a crear.

Singleton (Instancia Única)

El patrón Singleton garantiza que una clase sólo tenga una instancia y proporciona un punto de acceso global a ésta instancia. Se emplea cuando una aplicación sólo requiere una instancia de un objeto como en el caso de las factorías.

La creación de la instancia única es responsabilidad y está completamente encapsulada en una clase. La implementación de este patrón debe considerar si esta se va a emplear en entornos de ejecución concurrente.

Finalmente, debido a su utilidad, muchos lenguajes han incorporado facilidades para la creación de instancias únicas (Scala, por ejemplo).