Patrón Creacional - Factory Method

Qué es el patrón Factory Method

El Factory Method es un patrón creacional que propone definir una interfaz para crear objetos, pero dejar que las subclases decidan qué clase concreta instanciar. En lugar de usar new directamente, se usa un método fábrica que devuelve una instancia de una interfaz común. Así se desacopla el código cliente de las implementaciones concretas.

Cuándo usarlo

Cuando el código no debe depender de clases concretas.
Cuando el tipo de objeto a crear puede variar según el contexto.
Cuando se desea facilitar la extensión de nuevas variantes sin modificar el código base.

Ejemplo en TypeScript — Factory Method

Supongamos que tenemos una aplicación que envía distintos tipos de notificaciones. Queremos que el código cliente no dependa de si la notificación es por correo, push o SMS.

[typescript]

interface Notification {
  send(message: string): void;
}

class EmailNotification implements Notification {
  send(message: string) {
    console.log(`📧 Email enviado: ${message}`);
  }
}

class PushNotification implements Notification {
  send(message: string) {
    console.log(`📲 Push enviado: ${message}`);
  }
}

abstract class NotificationFactory {
  abstract createNotification(): Notification;

  notify(message: string) {
    const notification = this.createNotification();
    notification.send(message);
  }
}

class EmailNotificationFactory extends NotificationFactory {
  createNotification(): Notification {
    return new EmailNotification();
  }
}

class PushNotificationFactory extends NotificationFactory {
  createNotification(): Notification {
    return new PushNotification();
  }
}

// Uso
const factory: NotificationFactory = new EmailNotificationFactory();
factory.notify('Actualización disponible');

En este ejemplo, NotificationFactory define el método createNotification() que las subclases concretas implementan. El cliente solo usa notify() sin preocuparse por qué tipo de notificación se está enviando.

Ejemplo en TypeScript — Simple Factory

Una variante más directa es el Simple Factory, que no requiere subclases. Toda la lógica de decisión se centraliza en una sola clase o función. No es un patrón oficial de GoF, pero se usa mucho en la práctica para simplificar.

[typescript]

interface Notification {
  send(message: string): void;
}

class EmailNotification implements Notification {
  send(message: string) {
    console.log(`📧 Email enviado: ${message}`);
  }
}

class PushNotification implements Notification {
  send(message: string) {
    console.log(`📲 Push enviado: ${message}`);
  }
}

class NotificationSimpleFactory {
  static create(type: 'email' | 'push'): Notification {
    if (type === 'email') return new EmailNotification();
    if (type === 'push') return new PushNotification();
    throw new Error('Tipo de notificación no soportado');
  }
}

// Uso
const notification = NotificationSimpleFactory.create('push');
notification.send('Bienvenido al sistema');

Este enfoque es más simple pero menos extensible: cualquier nuevo tipo requiere modificar la fábrica, lo que viola el principio Open/Closed. Sin embargo, es ideal para sistemas pequeños o donde las variaciones son pocas.

Ejemplo en Java — Simple Factory

En Java, el patrón Simple Factory se implementa con una clase que encapsula la creación de objetos. Supongamos que queremos una fábrica para exportadores de archivos:

[java]

interface Exporter {
    void export(String data);
}

class PDFExporter implements Exporter {
    public void export(String data) {
        System.out.println("Exportando a PDF: " + data);
    }
}

class CSVExporter implements Exporter {
    public void export(String data) {
        System.out.println("Exportando a CSV: " + data);
    }
}

class ExporterFactory {
    public static Exporter create(String type) {
        switch (type) {
            case "pdf": return new PDFExporter();
            case "csv": return new CSVExporter();
            default: throw new IllegalArgumentException("Tipo no soportado: " + type);
        }
    }
}

// Uso
Exporter exporter = ExporterFactory.create("csv");
exporter.export("Reporte financiero");

Este patrón es muy común en Java para desacoplar la creación de objetos, especialmente en frameworks como Spring, donde los beans suelen gestionarse mediante fábricas o contenedores.

¿Cuál es la diferencia entre Factory Method y Simple Factory?

La Simple Factory usa una sola clase con un método estático para decidir qué objeto crear. El Factory Method, en cambio, usa herencia o polimorfismo: cada subclase define su propia lógica de creación. El primero es más directo; el segundo, más flexible y extensible.

¿Se pueden combinar ambos enfoques?

Sí. En proyectos grandes, es común tener una Simple Factory que elija qué Factory Method usar. Esto permite separar la lógica de decisión global de las lógicas de creación específicas.

¿Cuándo debería preferir uno sobre el otro?

Usá Simple Factory para sistemas pequeños o cuando la creación de objetos no va a cambiar frecuentemente.
Usá Factory Method cuando esperás extender el sistema con nuevas variantes y querés evitar modificar el código existente.

Resumen rápido

Factory Method delega la creación a subclases, favoreciendo la extensión sin modificar código.
Simple Factory centraliza la lógica de creación en una clase estática.
Ambos reducen acoplamiento, pero difieren en flexibilidad y escalabilidad.

Dominar estas variantes te permite diseñar arquitecturas más limpias y modulares, adaptadas a la evolución natural de tu software.