Come gestire diverse configurazioni con proprietà non sovrapposte?

Penso che la domanda sia interessante. Non è il problema in sé. È dovuto all'abuso dell'eredità. Un cattivo uso molto comune.

Perché lo dico?

Because I try to reduce redundant code I created an abstract class defining a general configuration, let's call it "GeneralConfiguration".

Questa è una delle peggiori ragioni per usare l'ereditarietà. L'obiettivo al di sotto delle classi astratte è molto più sofisticato di salvarci dalla duplicazione del codice .

For each "shared" property GeneralConfiguration defines an interface

Qui i dettagli di implementazione sono stati trasferiti a qualcosa che doveva essere astratto . Questo uccide le classi astratte che fanno bene, ci distraggono dai dettagli.

L'unica cosa in comune tra A e B è che, concettualmente , entrambe sono configurazioni , ma qui terminano le loro somiglianze.

Com'è?

Now, if the application user enters one configuration(A or B) it should be possible to access in a general and easy way all given methods/properties of the configurations.

Dal design entrambi si sono trasformati in qualcosa di diverso. Entrambi sono stati progettati come due componenti diversi e ora stiamo cercando di risolverlo con l'ereditarietà. L'ereditarietà non funziona in questo modo.

Sulla carta, entrambi potrebbero avere lo stesso significato e lo scopo, ma tale funzione non è stata trasferita al design.

Se vogliamo astrarci dai "dettagli" (A o B), la configurazione dovrebbe essere totalmente agnostica per loro .

Esempio:

public Configuration {
  Map<enum,Object> properties;

  public Configuration(){
        properties = new HashMap<enum,Object>();
  }

  public Object getProperty(enum propertyName){
         return properties.get(propertyName);
  }

  public void setProperty(enum propertyName, Object value){
        properties.put(propertyName, value);
  }
 }

Ora, non c'è né A né B (e l'ereditarietà diventa inutile) .

Come impiantiamo A e B?

Ora possiamo implementare "dettagli" sull'astrazione. Ad esempio, implementando il modello di delega

public ConfigA {
    Configuration config;

  public ConfigA(Configuration config){
      this.config = config;
  }

 public String getA(){
       return (String)  config.getProperty(MyEnumA.A);
  }

  public void setA(String value){
      config.setProperty(MyEnumA.A,value);
  }
      ...
}

Se abbiamo bisogno di "dettagli" usiamo ConfigA / ConfigB . Usiamo Configurazione per il resto.

Nota: quando dico astrazione non mi riferisco solo alle classi astratte. Mi riferisco al concetto.

Penso che il modello Builder possa aiutarti.

public class ConfigBuilder 
{
    public void SetPropertyA(string a)
    public void SetPropertyB(int b)
    public GeneralConfiguration Build()
}

L'interfaccia utente può interagire con i metodi esposti dall'oggetto ConfigBuilder . Una volta che l'utente è OK, verrà invocato il metodo Build per determinare se ConfigA o ConfigB verrà creato in base alle proprietà impostate nell'oggetto ConfigBuilder .