Patrón de método de fábrica en Java usando genéricos, ¿cómo?

Question

tengo código que se ve como sigue:

public interface BaseDAO{ 
// marker interface 
} 

public interface CustomerDAO extends BaseDAO{ 
public void createCustomer(); 
public void deleteCustomer(); 
public Customer getCustomer(int id); 
// etc 
} 

public abstract class DAOFactory { 
public BaseDAO getCustomerDAO(); 
public static DAOFactory getInstance(){ 
    if(system.getProperty("allowtest").equals("yes")) { 
    return new TestDAOFactory(); 
    } 
    else return new ProdDAOFactory(); 
} 

public class TestDAOFactory extends DAOFactory{ 
public BaseDAO getCustomerDAO() { 
    return new TestCustomerDAO(); // this is a concrete implementation 
    //that extends CustomerDAO 
    //and this implementation has dummy code on methods 
} 

public class ProdDAOFactory extends DAOFactory { 
public BaseDAO getCustomerDAO() { 
    return new ProdCustomerDAO(); // this implementation would have 
    // code that would connect to the database and do some stuff.. 
} 
} 

Ahora, sé que el código huele .. por muchas razones. Sin embargo, este código también está aquí: http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html, se refieren 9.8

Lo que intento hacer es lo siguiente: 1) Interruptor de mis DAOs implementaciones en tiempo de ejecución basado en el entorno (propiedades del sistema). 2) Hacer uso de los genéricos de Java para que pueda evitar la conversión de tipos ... , por ejemplo, hace algo como esto:

CustomerDAO dao = factory.getCustomerDAO(); 
dao.getCustomer(); 

A diferencia:

CustomerDAO dao = (CustomerDAO) factory.getCustomerDAO(); 
dao.getCustomer(); 

sus ideas y sugerencias, por favor .

Answer 1

debe definir la fábrica así:

public abstract class DAOFactory<DAO extends BaseDAO> { 
public DAO getCustomerDAO(); 
public static <DAO extends BaseDAO> DAOFactory<DAO> getInstance(Class<DAO> typeToken){ 
    // instantiate the the proper factory by using the typeToken. 
    if(system.getProperty("allowtest").equals("yes")) { 
    return new TestDAOFactory(); 
    } 
    else return new ProdDAOFactory(); 
} 

getInstance debe devolver un DAOFactory escrita a máquina adecuada.

La variable fábrica tendrá el tipo:

DAOFactory<CustomerDAO> factory = DAOFactory<CustomerDAO>.getInstance(CustomerDAO.class); 

y el uso se escribe correctamente:

CustomerDAO dao = factory.getCustomerDAO(); 
dao.getCustomer(); 

el único problema será probablemente un reparto requerido dentro de los métodos getInstance.

Answer 2

Cuando he usado fábricas, he usado típicamente instanceof para determinar el tipo verdadero del objeto. Por ejemplo:

CustomerDAO dao; 
if (factory.getCustomerDAO() instanceof CustomerDAO) { 
    dao = factory.getCustomerDAO(); 
} 
dao.getCustomer(); 

Esto se parece más limpio para mí, sobre todo si factory.getCustomerDAO() no devuelve nada cerca de un CustomerDAO (debido a cambios en la implementación).

Sólo mis dos centavos.

Answer 3

Hay un montón de artículos que detallan lo que necesita:

• Generic DAO Pattern With JDK 5.0
• Generic Data Access Objects (igual al anterior)
• Don't repeat the DAO (con la primavera, pero los principios son los mismos)
• Java 1.5 Generic DAO (Spring otra vez)

Tenga en cuenta que at, a diferencia de su ejemplo, no hay ninguna razón por la cual los métodos de DAOFactory no devuelvan las subclases reales (es decir, CustomerDAO getCustomerDAO()). Además, el beneficio principal del uso de DAO genéricos es tener el tipo de entidad "genericized", por lo que no tiene que emitir desde load()/get()/find() y métodos similares.

Answer 4

Su ejemplo no demuestra la necesidad de BaseDAO, y no hay ninguna razón por la cual DAOFactory.getCustomerDAO() no se debe declarar para que devuelva CustomerDAO. Entonces, realmente no veo la necesidad de genéricos allí. Sin embargo, tenga en cuenta lo siguiente:

interface DataAccess<T> { 
    void store(T entity); 
    T lookup(Serialiable identifier); 
    void delete(Serializable identifier); 
    Collection<? extends T> find(Criteria query); 
} 

abstract class DataAccessFactory { 
    abstract DataAccess<T> getDataAccess(Class<T> clz); 
    static DataAccessFactory getInstance() { 
    ... 
    } 
} 

que he usado algo así como este enfoque en varios proyectos, y es muy agradable para escribir uno de DAO que funcione para todas las entidades en el modelo. La debilidad son los métodos de "búsqueda". Existen algunos enfoques claros, y el próximo trabajo en JPA es la estandarización de una API de "Criterios", pero por ahora a menudo es más fácil exponer los criterios del mecanismo de persistencia subyacente.