java generici costruttori

Question

Attualmente ho il seguente codice che recupera i dati dal database e quindi crea un User. Questo codice è usato in molti dei miei corsi per creare altri oggetti come News, Comments ecc ...

Usa dbutils di apache comuni.

final ResultSetHandler<User> handler = new ResultSetHandler<User>() { 

      @Override 
      public User handle(ResultSet rs) throws SQLException { 

       User user = null; 
       if (rs.next()) { 
        user = new User(); 
        user.setId(rs.getInt("id")); 
        user.setUsername(rs.getString("username")); 
        user.setPassword(rs.getString("password")); 
       } 
       return user; 
      } 
     }; 

     final User user = run.query(
       "SELECT id, username, password FROM users WHERE username = ? AND active = 2 LIMIT 1;", handler, 
       username); 

sarebbe possibile avvolgere il QueryRunner in una classe generica e sovrascrivere il metodo query in modo il gestore instanciate il generico T con il ResultSet. Mi assicuravo che qualsiasi tipo di T avesse un costruttore che accetta un ResultSet.

Come così:

 public class QueryExecuter<T> extends QueryRunner { 
    private ResultSetHandler<T> _handler; 

    public QueryExecuter(){//The T type was for testing haha 
     super(); 
     handler = new ResultSetHandler<T>() { 

      @Override 
      public T handle(ResultSet rs) throws SQLException { 

       T object = null; 
       if (rs.next()) { 
        object = new T(rs); 
       } 
       return object; 
      } 
     }; 
    } 
} 

Non so se capirai, ma spero di sì, mi chiede se volete maggiori dettagli o una spiegazione migliore.

EDIT

ho pensato che avrei potuto usare un AbstractClass invece che il tipo generico che tutti gli oggetti differenti avrebbero estende, ma sembra che non posso scrivere un costruttore astratto. Devo fare un metodo statico che restituisca un'istanza dell'oggetto come:

public abstract class DatabaseEntity { 
    public static abstract DatabaseEntity create(ResultSet rs);//even this doesn't work... 
} 

Answer 1

Possibile, sì? Ma è una cattiva idea.

Si potrebbe fare:

class ResultSetHandler<T> { 
    ResultSetHandler<T>(Class<T> clazz) { 
    this.clazz = clazz; 
    } 

    public T handle(ResultSet rs) throws SQLException { 
    T object = null; 
    if (rs.next()) { 
     object = clazz.getConstructor(ResultSet.class).newInstance(rs) 
    } 
    return object; 
    } 
} 

dominio e il database di miscelazione è una cattiva idea, però. Che cosa sarebbe meglio, però, sarebbe quello di definire un metodo di abtract che crea l'oggetto in base al gruppo di risultati:

abstract class ResultSetHandler<T> { 

    protected abstract T create(ResultSet rs); 

    public T handle(ResultSet rs) throws SQLException { 
    T object = null; 
    if (rs.next()) { 
     object = create(rs); 
    } 
    return object; 
    } 
} 

Poi, nella tua classe che implementa, avete solo bisogno di fornire un metodo create() invece di gestire il risultato imposta te stesso, ad esempio:

h = new ResultSetHandler<Person>() { 
    protected Person create(ResultSet rs) { 
    return new Person(rs.getString("name")); 
    } 
} 

Answer 2

Non credo sia possibile farlo in Java. Non è possibile creare un'istanza di T in un generico. Generics in java non sono realmente modelli come in C++, sono solo zucchero di sintassi attorno a uno object che rimuove i cast e induce avvisi di tempo di compilazione.

In C# non esiste un modo per limitare T in modo che sia necessario un costruttore.

La soluzione migliore se ciò è davvero necessario è risolvere la classe appropriata utilizzando il reflection, ma anche in questo caso si verificherà un problema poiché non è possibile conoscere la classe di esecuzione di T come viene invocato il metodo - questa informazione viene rimossa da il bytecode java. Quindi ti rimane il compito di passare la classe al metodo per usare la riflessione su di essa. E non sono troppo sicuro che sia comunque una buona idea di design.

Answer 3

Si potrebbe fare qualcosa del genere (passando la classe dell'oggetto da creare, e usare reflection per chiamare il suo costruttore), ma troverei il design sbagliato avere il POJO dipendente da JDBC, e non solo sapere come è memorizzato nel database, ma anche quali alias sono stati utilizzati nella query utilizzata per caricarlo.

In breve, non è responsabilità del costruttore POJO utente gestire un set di risultati di una query esterna sconosciuta.

si potrebbe progettare una superclasse AbstractSingleEntityHandler che avrebbe semplicemente avere il blocco

if (rs.next()) { 

, e sarebbe delegare la creazione effettiva entità ad un metodo astratto, ma non sarebbe guadagnare molto.