El patrón Abstract Factory resuelve un problema común en programación orientada a objetos: cómo producir varias familias de objetos relacionados sin acoplarte a sus clases concretas. Si ya conoces el patrón Factory, piensa en este como el siguiente nivel, una factory de factories.

Qué problema resuelve el patrón Abstract Factory

Imagina que tienes una aplicación que gestiona la producción de coches y, hasta ahora, solo fabricas dos modelos: Mastodon y Rhino, cada uno en su propia fábrica. El negocio crece, las ventas suben y el equipo directivo te pide algo nuevo: agregar versiones por cada modelo, una sedán y una hatchback.

Ahora necesitas Mastodon sedán, Mastodon hatchback, Rhino sedán y Rhino hatchback. Y para complicarlo un poco más, cada versión se debe producir en una fábrica particular: una fábrica de sedanes y una fábrica de hatchbacks.

¿Por qué el patrón Factory simple no funciona aquí? Porque Factory está pensado para que un método retorne un único producto concreto. En este caso, una sola fábrica necesita retornar más de un producto, así que el patrón se queda corto.

Cómo soluciona Abstract Factory el problema de las familias de productos

La propuesta del patrón es elegante y se construye en capas. Primero declaras una clase base o interfaz por cada modelo del catálogo. En este ejemplo, tendrías una abstracción para Mastodon y otra para Rhino, pensadas para soportar cualquier vehículo nuevo que aparezca en el futuro.

Después implementas clases concretas de cada producto por cada familia de versión. Es decir, tu código tendrá clases específicas como Rhino sedán, Rhino hatchback, Mastodon sedán y Mastodon hatchback.

Cómo se define la fábrica abstracta

El siguiente paso es declarar la interfaz o clase base que da nombre al patrón: la abstract factory. Esta abstracción indica los métodos de creación que toda fábrica concreta debe implementar, definiendo qué productos se van a producir y qué forma tendrán esas fábricas.

Por ejemplo, una fábrica de sedanes retornará la versión sedán del Mastodon y la versión sedán del Rhino. Una fábrica de hatchbacks hará lo mismo, pero con la versión hatchback de cada modelo. Por eso decimos que es una fábrica de fábricas.

Cómo se implementan las fábricas concretas

Finalmente creas clases fábrica concretas por cada familia de versiones. Cada una implementa los métodos de creación definidos en la abstract factory y produce los vehículos que le corresponden a esa familia.

¿Qué es una familia de productos en este patrón? Es un grupo de objetos relacionados que comparten una temática o variación. En el ejemplo, sedán y hatchback son dos familias, y cada una agrupa sus propias versiones de Mastodon y Rhino.

Cuáles son los conceptos clave para entender Abstract Factory

Para dominar este patrón conviene tener claros algunos conceptos que aparecen a lo largo de la explicación.

• Encapsular múltiples fábricas bajo una misma familia, sin que el código cliente conozca clases concretas.
• Clases base o interfaces por producto, que definen el contrato de lo que un Mastodon o un Rhino deben cumplir.
• Clases concretas por familia, que materializan cada combinación de modelo y versión.
• Interfaz abstract factory, que declara los métodos de creación para cada producto del catálogo.
• Fábricas concretas, una por cada familia de versiones, que implementan esos métodos de creación.

Con esa base ya puedes leer el diagrama del patrón y saltar al código sin perderte. ¿Tienes dudas sobre cómo se vería esto en tu lenguaje favorito? Déjalas en los comentarios.