Qual è il modo più pratico per aggiungere funzionalità a questo pezzo di codice?

Per un problema mal definito come questo, preferisco scrivere prima un'applicazione reale, senza particolare riferimento a quale sarà l'interfaccia. Ovviamente, dovresti pensare a come sarà l'interfaccia man mano che procedi, ma c'è un singolo client, quindi sei libero di riorganizzarti se necessario.

Quando avvii la seconda applicazione che utilizzerà l'interfaccia, avvia i metodi di astrazione necessari per la seconda applicazione da quelli forniti dal primo. Iterate. La seconda applicazione forzerà inevitabilmente il primo a essere modificato per supportare un'interfaccia comune. Il terzo costringerà il secondo e il primo a cambiare. Ecc.

Quando arrivi al punto in cui aggiungere una nuova applicazione non richiede più la modifica delle interfacce, allora sei pronto per pubblicare la tua interfaccia.

My first idea was to write an interface [...] but then it came to my mind that if I add any other functionality later all code will break for those who are using the old interface.

Utilizza invece una classe astratta:

public interface Hexagon<T extends HexagonData>{
    T getData();
    void setData(T data);
}

public abstract class HexagonData{
    public boolean isTransparent(){ return false; }
    public boolean isPassable(){ return true; }
    public int getPassageCost(){ return 0; }
}

Non utilizzare annotazioni a meno che non si abbia effettivamente bisogno dei metadati relativi al membro che è stato annotato.

Se vuoi aggiungere dataelements / properties / variables al tuo Hexagon senza modificare gli altri HexagonHandlers come HexagonalGridCalculator puoi aggiungere proprietà dinamiche come questa:

public class Hexagon implements Serializable {

    // ... other methods not important in this context

    void setProperty(int id, object data);

    object getProperty(int id, object notFoundValue);
} 

e definire le costanti per gli elementi dati / proprietà / variabili

const int SatelliteData = 1;

Se in un secondo momento desideri disporre di dati aggiuntivi, definisci nuove costanti

const int Transparent = 2;
const int Passable = 3;
const int tPassageCost = 4;

che non influisce sugli altri gestori.

Propongo un approccio sfaccettato simile a quello usato nella libreria standard C ++.

interface Hexagon {
  void setData(int id, T data); //these should only be used from Facet class
  Object getData(int id);

  sealed class IFacet<T> {
    private static int count = 0;
    private int _id = count++;
    public T getData(Hexagon hexagon) {
       return (T) hexagon.getData(_id);
    }
    public void setData(Hexagon hexagon, T data) {
       hexagon.setData(_id, data);
    }
  }
}

//Usages:

class CostManager {
  public readonly Facet<int> PASSAGE_COST = new Facet<int>();

  static void incrementCost(Hexagon hex) {
    PASSAGE_COST.setData(hex, PASSAGE_COST.getData(hex)+1);
  }
}

class TransparencyManager {
  public readonly Facet<boolean> TRANSPARENT = new Facet<boolean>();
  static void disable(Hexagon hex) {
    TRANSPARENT.setData(hex, false);
  }

}

Ogni Facet si rivolge esattamente a una proprietà di Hexagon (dato che usano _id univoco). Se Hexagon.setData () e Hexagon.getData () vengono sempre utilizzati attraverso una classe Facet, i dati memorizzati avranno sempre il tipo di Facet corrispondente. Ciò impedirà all'utente di provare a scrivere dati di tipo sbagliato su un dato ID.

Per illustrare il tipo di errori che questo approccio protegge da considerare un esempio basato sulla risposta @ k3b:

  static void configure(Hexagon hex) {
     hex.setData(DataType.TRANSPARENCY, "very transparent"); // compiler accepts this just fine, strings are objects, aren't they?
  }

  static void processHexagon(Hexagon hex) {
    boolean data = (Boolean)hex.getData(DataType.TRANSPARENCY); // compiler accepts this, Boolean are objects too
  }

  static void doSomeJob(Hexagon hex) {
     configure(hex);
     // working
     // more work
     // ...
     processHexagon(hex); //oops, you've got runtime error
  }

Ora considera lo stesso codice con Facets:

  static void configure(Hexagon hex) {
     TRANSPARENT.setData(hex, "very transparent"); // compiler slaps you
  }

  static void processHexagon(Hexagon hex) {
    boolean data = TRANSPARENT.getData(hex); // no downcast!
  }

  static void doSomeJob(Hexagon hex) {
     configure(hex);
     // working
     // more work
     // ...
     processHexagon(hex); //no runtime errors, just compile-time ones
  }

Come puoi vedere, il codice è ancora meno dettagliato, poiché ora non è necessario eseguire downcast.

Lo costruirei come un DTO. Avere interfacce con getter e setter per i dati necessari e eseguire l'elaborazione in sistemi esterni. Forse fornire un esadecimale predefinito che potrebbero estendere se lo volessero. Il risultato sarebbe più un sistema di componenti di entità che di object oriented, ma è una specie di punto dei sistemi di componenti la flessibilità da estendere in modi che non si aspettavano in anticipo.

Per quanto ne so, tu vuoi fornire un'API che permetta agli utenti della tua libreria di costruire oggetti complessi ( esagoni ), con una serie di attributi che potenzialmente possono essere estesi in futuro ( costo trasparente, passabile, di passaggio ecc.)

I problemi di progettazione del genere sono presi di mira da Modello di generatore :

the builder pattern uses another object, a builder, that receives each initialization parameter step by step and then returns the resulting constructed object at once... Builders are good candidates for a fluent interface...

Per il tuo caso, l'implementazione potrebbe essere la seguente (supponendo che newAttribute venga aggiunta nella libreria delle versioni successive):

public class HexagonBuilder {

    public Hexagon build() { /*...*/ }

    public HexagonBuilder transparent(boolean isTransparent) { /*...*/; return this }

    public HexagonBuilder passable(boolean isPassable) { /*...*/; return this }

    public HexagonBuilder passageCost(int cost) { /*...*/; return this }

    public HexagonBuilder newAttribute(Object attribute) { /*...*/; return this }
}

Come puoi vedere, il vecchio codice si compilerebbe bene con la versione più recente della tua libreria, perché la sola differenza è compatibile - semplicemente non invoca il metodo newAttribute .

Nota che per il vecchio codice non solo compila, ma funziona anche senza problemi con la nuova versione della libreria, dovrai fornire un comportamento predefinito appropriato per il codice client che non imposta un nuovo attributo.

_{Per motivi di completezza, prendi in considerazione altri schemi di creazione - < em> Factory, Prototype etc, anche se per i dettagli forniti nella domanda fino ad ora, Builder sembra la soluzione migliore.}