# Prop�sito

El Factory Method define una interfaz para crear un objeto, pero deja que las subclases decidan qu� clase instanciar. Delega en las subclases la creaci�n del objeto.

# Problema

La necesidad de crear objetos sin especificar la clase del objeto que se va a crear. En un ejemplo del �mbito de la cocina: debemos preparar un plato, pero no sabemos si ser� una sopa, una ensalada o un postre hasta el �ltimo momento.

# Soluci�n

La soluci�n que ofrece el Factory Method es:

• Definir una interfaz de creaci�n de objetos: Crear una interfaz o m�todo abstracto para la creaci�n de objetos.

• Delegar la creaci�n a las subclases: Las subclases tendr�n la implementaci�n concreta para la creaci�n de objetos.

Como resultado, el cliente puede trabajar con interfaces o clases abstractas sin tener que conocer las clases concretas. Es como tener un m�todo general para �preparar un plato”, pero las subrecetas son las que determinan los ingredientes y procedimientos espec�ficos.

# Estructura

# Participantes

• Creador: Define el m�todo abstracto para la creaci�n del objeto.

• CreadorConcreto: Implementa el m�todo factoryMethod. Devuelve una instancia del ProductoConcreto.

• Producto: Interfaz o clase abstracta de los objetos que se crear�n.

• ProductoConcreto: Implementaci�n espec�fica del producto que se crea.

# Cu�ndo Usarlo

• Una clase no puede prever la clase de objetos que debe crear.

• Una clase quiere que sean las subclases quienes decidan los objetos que crea.

# Ejemplo: Gesti�n de Documentos

Pensemos en un sistema de gesti�n de documentos donde los usuarios pueden crear diferentes tipos (texto, planillas, presentaciones). Cada tipo tiene caracter�sticas propias pero comparten funcionalidades b�sicas como abrir, cerrar y guardar.

Soluci�n planteada

Implementamos un Factory Method que permite a las subclases decidir qu� clase de documento instanciar. DocumentManager actuar�a como el cliente.

# C�digo Java

abstract class Document {
    public abstract void open();
    public abstract void close();
    public abstract void save();
}

class TextDocument extends Document {
    @Override
    public void open() { /* ... */ }
    @Override
    public void close() { /* ... */ }
    @Override
    public void save() { /* ... */ }
}

abstract class DocumentCreator {
    public abstract Document createDocument();
}

public class TextDocumentCreator extends DocumentCreator {
    @Override
    public Document createDocument() {
        return new TextDocument();
    }
}

public class DocumentManager {
    public static void main(String[] args) { 
        DocumentCreator creator = new TextDocumentCreator();
        Document doc = creator.createDocument();
        doc.open();
        doc.save();
        doc.close();
    }
}

# Mapeo Participantes

• DocumentCreator (Creador): Define el m�todo f�brica.
• TextDocumentCreator (CreadorConcreto): Implementa el m�todo para devolver un tipo espec�fico.
• Document (Producto): Define la interfaz com�n.
• TextDocument (ProductoConcreto): Implementaci�n espec�fica.
• DocumentManager (Cliente): Decide qu� documento crear.

# Conclusiones

Este enfoque mantiene el c�digo flexible y extensible, permitiendo agregar f�cilmente nuevos tipos de documentos sin modificar el c�digo existente.

# Patrones relacionados