Uso dei generici sulle interfacce quando l'implementazione non è generica

Question

Uso dei generici sulle interfacce quando l'implementazione non è generica

#1 da (2 voti)

1

È pratica accettabile mettere i generici su un'interfaccia quando l'implementazione non sarà generica? Diciamo che il mio progetto avrà molte classi che leggono i dati dal database. Potrei creare un'interfaccia generica come:

public interface DataRetriever<T, R>{

  R retrieveData(T criteria);

}

public class UserDataRetriever implements DataRetriever<UserCriteria, User>{

  @Override
  public User retrieveData(UserCriteria criteria) {
    ...
  }
}

Oppure un altro esempio potrebbe essere:

public interface DataRetriever2<R>{

  R retrieveData();

}
public class UserDataRetriever2 implements DataRetriever2<User>{

  @Override
  public User retrieveData() {
    ...
  }
}

Con l'uso di generici sulle interfacce, sembra che io possa ricavare molta più riutilizzabilità dalle mie interfacce e non ho bisogno di un'interfaccia per classe di recupero dei dati. Tuttavia, temo che la documentazione per la mia interfaccia sia costretta a essere vaga. Le persone devono inoltre rispettare il numero di parametri sul metodo retrieveData in modo che possano creare un nuovo oggetto Pojo per lo scenario 1 o essere obbligati a mettere tutto nel costruttore nello scenario 2. Riflessioni sull'utilizzo di generici qui quando l'implementazione non sarà usa i farmaci generici?

object-oriented design java interfaces generics

posta radian 18.11.2018 - 19:30

fonte

1 risposta

Leggi altre domande sui tag object-oriented design java interfaces generics

Quale struttura dati utilizzare per la memorizzazione temporanea di dati di sensori intermittenti e asincroni? Entità e relazioni polimorfiche

score 2 · Accepted Answer

È prassi comune avere implementazioni non generiche di interfacce generiche, proprio come l'hai mostrata, e non c'è niente di sbagliato in questo.

Ma ovviamente progettare una buona interfaccia generica è una sfida più grande di una specifica. Pertanto, devi decidere che cosa deve essere un'istanza DataRetriever e quali operazioni deve supportare per essere utile. Mi aspetto una singola istanza DataRetriever per gestire tutte le query di una determinata classe, ad es. User , (ma forse non è quello che hai in mente ...).

Quindi, R retrieveData(T criteria) mi sembra un'operazione utile, mentre R retrieveData() manca di un modo per specificare i criteri della query.

Forse vorrai anche introdurre un'interfaccia generica per QueryCriteria e avere T estendere QueryCriteria<R> , quindi ogni implementazione si aspetta criteri che corrispondano al tipo di oggetto.

People also have to adhere to the number of parameters on the retrieveData method so they might be creating a new pojo object for scenario 1 or might be forced to put everything in the constructor in scenario 2.

L'aderenza alla firma della funzione è al centro dell'uso delle interfacce, quindi definiscilo in modo che i tuoi colleghi non siano costretti a ricorrere all'ambiente di lavoro, altrimenti dovresti ripensare all'interfaccia. Quindi, se il risultato dell'analisi è che per il recupero dei dati un singolo criterio è tutto ciò che è necessario, attenersi a tale modello (e lasciare che le varie implementazioni definiscano le classi di criteri di cui hanno bisogno).