El patrón Factory se entiende mejor cuando lo trasladas a un diagrama UML. Aquí descubrirás cómo se relacionan la clase producto base, los productos concretos y las fábricas concretas para resolver el problema de instanciación rígida en programación orientada a objetos.

La idea central: separar qué se crea de quién lo crea, apoyándote en herencia, polimorfismo y abstracción. Veamos los cuatro pasos que estructuran el diagrama y las relaciones entre sus elementos.

¿Cómo se declara la clase producto base en el patrón Factory?

El primer paso es definir una abstracción común que actúe como contrato para todos los productos que tu fábrica pueda generar [0:20].

Necesitas declarar una clase producto base o una interface que será retornada por las fábricas y sus subclases. Esta clase puede tener atributos y operaciones compartidas. Si decides usar una interfaz en lugar de clase abstracta, solo cambias la sintaxis del diagrama por interface.

¿Qué es una clase producto base? Es la abstracción común (clase o interfaz) que define el tipo de objeto que las fábricas prometen retornar, sin comprometerse con una implementación concreta.

¿Qué papel juegan los productos concretos y el polimorfismo?

El segundo paso implementa las variantes específicas que tu sistema necesita crear [1:00].

Aquí entran productA y productB, dos subclases que heredan o implementan la clase producto base. Lo interesante: estas subclases pueden sobrescribir el método común aprovechando la naturaleza polimórfica de la programación orientada a objetos. Esto es opcional. Si te sirve la implementación heredada, no necesitas redefinirla.

El polimorfismo aquí es la pieza que permite tratar a productA y productB como si fueran simplemente product, sin que el código cliente sepa cuál recibió.

¿Cómo se conecta la clase Factory con los productos?

El tercer paso introduce la fábrica como abstracción [1:40]. Declaras una clase o interfaz factory que retorna objetos cuyo tipo coincide con el producto base, no con los productos concretos.

En el diagrama verás que la clase factory tiene:

• Un método anotherOperation para lógica adicional.
• El método fábrica makeProduct, que retorna product (la abstracción).
• Cero referencias directas a productA o productB.

Este detalle es clave. La fábrica abstracta nunca promete devolver un producto concreto; promete devolver algo que cumple el contrato del producto base.

¿Por qué retornar la abstracción y no el tipo concreto?

Porque eso mantiene flexible al código cliente. Si mañana agregas un productC, la firma del método no cambia. Solo creas una nueva fábrica concreta y listo.

¿Cómo implementan las fábricas concretas el método makeProduct?

El cuarto paso es donde ocurre la creación real de objetos [2:30]. Implementas las clases factory concretas, y cada una sobrescribe makeProduct para retornar un producto específico usando la palabra clave new.

Por ejemplo, concreteFactoryA internamente hará algo como:

java return new concreteProductA;

Aunque el método declara retornar product, gracias a la herencia o implementación, productA también es un producto. Esa es la magia del polimorfismo aplicado al patrón.

• Si trabajas con herencia, dices: productA es un product.
• Si trabajas con implementación de interfaz, dices: productA cumple el contrato de product.
• En ambos casos, el método puede retornarlo sin romper el tipo declarado.

Lo mismo aplica para concreteFactoryB devolviendo concreteProductB.

¿Por qué la fábrica concreta usa new internamente? Porque alguien tiene que instanciar el objeto. Factory no elimina new, lo encapsula en un solo lugar para que el resto del código no dependa de clases concretas.

¿Qué dependencia existe entre fábrica concreta y producto concreto?

Entre concreteFactoryA y productA existe una relación de dependencia directa [3:30]. Si el nombre de productA cambia, también tienes que modificar el código de concreteFactoryA.

Y aquí va una idea importante: la dependencia no es mala por sí misma. Lo que buscas es reducirla al mínimo necesario. Factory no la elimina, la concentra en un solo punto controlado del sistema, lejos del código cliente.

En resumen, el diagrama del patrón Factory se construye con cuatro elementos enlazados:

1. Clase o interfaz producto base.
2. Productos concretos que heredan o implementan esa base.
3. Clase o interfaz factory que retorna el producto base.
4. Fábricas concretas que sobrescriben makeProduct y retornan productos concretos con new.

¿Te quedó claro el diagrama desde el primer vistazo o necesitaste releer los pasos? Cuéntame en los comentarios qué relación te costó más entender, si la de herencia entre productos o la dependencia entre fábrica concreta y producto concreto.