Patrones de Diseño: Abstract Factory en Producción de Coches

Comprender el diagrama del patrón Abstract Factory es fundamental para dominar la creación de familias de objetos relacionados sin acoplar el código a clases concretas. A continuación se desglosa paso a paso cómo cada elemento del diagrama se traduce al problema real de producir distintos tipos de coches.

¿Cómo se definen los productos base en el catálogo?

El primer paso consiste en declarar clases o interfaces de los productos base [0:18]. En el diagrama aparecen como Producto A y Producto B. Trasladado al problema de producción de coches, estos productos base corresponden a Mastodon y Rhino. Son las abstracciones que establecen el contrato que todo producto concreto debe cumplir.

A partir de ahí se crean las clases concretas de los productos, una por cada familia existente [0:44]. En el diagrama se ven como Producto XA, Producto XB, Producto YA y Producto YB, donde X e Y representan las familias. En el contexto de coches:

• Sedan es una familia.
• Hatchback es otra familia.

Cada combinación genera un producto concreto: un Mastodon sedán, un Rhino sedán, un Mastodon hatchback y un Rhino hatchback.

¿Qué papel cumple el AbstractFactory en el diagrama?

El tercer punto del diagrama es declarar la interfaz AbstractFactory [1:08]. Esta interfaz contiene los métodos de creación correspondientes a cada producto base del catálogo: crearProductoA y crearProductoB.

La clave está en el tipo de retorno: siempre es el producto base, nunca el producto concreto. Esto es lo que permite el desacoplamiento y constituye la esencia de los patrones factory. El mismo principio ya se aplicaba en el patrón Factory Method [1:30]. En el problema de coches, esta interfaz se llamaría algo como CarFactory o FamilyCarFactory.

¿Cómo se implementan las fábricas concretas?

El cuarto y último punto consiste en crear las ConcreteFactories [1:46], es decir, fábricas concretas que implementen todos los métodos de creación definidos en el AbstractFactory. En el diagrama se representan como familia X y familia Y; en el problema real serían:

• La fábrica de Sedan.
• La fábrica de Hatchback.

Cada fábrica concreta contiene métodos como createMastodon y createRhino [2:01]. Dentro de sus implementaciones se retornan productos concretos, pero el tipo de dato declarado en la firma del método sigue siendo el producto base. Por ejemplo, la fábrica Sedan retorna un objeto Mastodon sedán, aunque el tipo de retorno es simplemente Mastodon, no Mastodon-sedán [2:18]. Esta distinción es de alta relevancia para garantizar la extensibilidad del código [2:39].

¿Por qué vale la pena la complejidad del Abstract Factory?

El diagrama puede parecer complejo a primera vista: múltiples elementos, familias de fábricas, productos base y productos concretos [2:48]. Sin embargo, cuando se implementa de forma correcta y bajo el contexto adecuado, los beneficios superan ampliamente la complejidad inicial:

• Extensibilidad: agregar una nueva familia solo requiere crear una nueva fábrica concreta y sus productos, sin modificar el código existente.
• Desacoplamiento: el código cliente trabaja con interfaces, no con clases concretas.
• Consistencia: cada fábrica garantiza que los productos creados pertenecen a la misma familia.

El patrón Abstract Factory brilla cuando un sistema debe manejar múltiples familias de productos relacionados y se necesita que esas familias sean intercambiables sin alterar la lógica principal. Si te resulta interesante cómo se traduce todo esto a código funcional, comparte qué parte del diagrama te generó más dudas.