Sto progettando un'architettura in cui ho:
public interface IObjectReader{
public Object read();
}
public class ConcreteObjectReader implements IObjectReader{
@Override
public Object read(){
//do stuff
return new Object();
}
}
Ora, se voglio consentire la parametrizzazione di un lettore, potrei creare un'altra interfaccia in questo modo:
public interface IParameterizedObjectReader extends IObjectReader {
public void setParams(Map<String,String> params);
public Map<String,String> getParams();
}
Per me è ragionevole. Tuttavia, nel mio progetto ho anche object writer, processori di oggetti e così via, e devono anche essere, eventualmente, parametrizzati. In questo scenario, avere due o più interfacce che definiscono lo stesso contratto (getParams e setParams) è una pessima idea per me. Quindi definirei un IParameter di interfaccia come questo:
public interface IParameter{
public void setParams(Map<String,String> params);
public Map<String, String> getParams();
}
e farei l'interfaccia IParametereziedObjectReader (simile per IParameterizedObjectWriter, ecc.) anche estendere IParameter, ma lascerei vuoto.
Questa è una cattiva idea? O forse dovrei lasciare solo l'interfaccia IParameter ed eliminare le sue sottointerfacce? Per chiarezza, devo dire che non uso queste interfacce parametrizzate come marcatori ovunque nel mio codice, quindi sarebbero vuote solo per ragioni architettoniche.
Come progetteresti questa soluzione in modo diverso?