Discusión:Factory Method (patrón de diseño)
En la versión en inglés dicen que Abstract Factory se suele implementar con Factory Methods, no que sea una simplificación. Me gustaría saber en qué se diferencian estos dos patrones.
Difrerencias entre Factory Method y Abstract Factory[editar]
Un Factory Method es simplemente un método que construye objetos (en lugar de crearlos con "new"), ya sea por comodidad (abstraer parámetros), por gestión de recursos (usar copias únicas), por el ámbito del objeto (no tiene sentido si no lo crea un padre), etc.
Ejemplos de uso del patrón en java:
http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/BorderFactory.html (comodidad y gestión)
http://java.sun.com/j2se/1.5.0/docs/api/java/sql/Connection.html#createStatement() (por ámbito).
El [Abstract Factory] emplea varios Factory Method para crear tipos concretos de familias abstractas.
¿Creéis que podríamos mejorar la definición?[editar]
Cómo se ha podido observar en comentarios anteriores en este apartado de discusiones creo que existe cierta confusión en cuanta al objetivo de utilización de este patrón.
Lo primero que me ha confundido un poco es el diagrama de clases. Aunque bien desarrollado crea confusión al pintar dos posibles implementaciones de la interfaz de Producto. Creo que habría quedado más claro con una única implementación. Yo me haría la siguiente pregunta, ¿por qué no tres implementaciones? Si el diagrama muestra una interfaz y una implementación se presupone que habrá tantas implementaciones como comportamientos a implementar.
En cuanto a la definición y ejemplo descrito también tengo alguna sugerencia. Según podemos leer en el libro "Design Patterns: Elements of Reusable Object-Oriented Software from the Gang Of Four" el patrón Factory Method se define así:
"Define an interface for creating an object, but let the classes that implement the interface decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses."
Para mi la definición se puede mejorar siguiendo la explicación y el ejemplo descritos en un artículo publicado por James Sugrue en la web de DZone. El nombre del artículo es Design Patterns Uncovered: The Factory Method Pattern. Podemos ver el ejemplo que ha programado James Sugrue en su artículo:
Interface (Product)
public interface Logger {
public void log(String message);
}
Concrete implementation of the Logger (Product)
public class XMLLogger implements Logger {
public void log(String message) {
//log to xml
System.err.println("logging");
}
}
The abstract Creator
public abstract class AbstractLoggerCreator
{
//the factory method
public abstract Logger createLogger();
//the operations that are implemented for all LoggerCreators
//like anOperation() in our diagram
public Logger getLogger()
{
//depending on the subclass, we'll get a particular logger.
Logger logger = createLogger();
//could do other operations on the logger here
return logger;
}
}
ConcreteCreator
public class XMLLoggerCreator extends AbstractLoggerCreator{
@Override
public Logger createLogger() {
XMLLogger logger = new XMLLogger();
return logger;
}
}
public class Client {
private void someMethodThatLogs(AbstractLoggerCreator logCreator)
{
Logger logger = logCreator.createLogger();
logger.log("message");
}
public static void main(String[] args)
{
//for the purposes of this example, create an XMLLoggerCreator directly,
//but this would normally be passed to constructor for use.
AbstractLoggerCreator creator = new XMLLoggerCreator();
Client client = new Client();
client.someMethodThatLogs(creator);
}
}
¿Qué opináis?