Una classe unificante complessa dovrebbe fare il calcolo?

Interfaccia separata dall'implementazione. "PlayerCharacter" dovrebbe essere un'interfaccia con metodi come "getStats", "getContacts", "getReputation" ecc. Ciò ti dà la libertà di giocare con l'implementazione senza dover cambiare il codice che usa questa interfaccia.

L'implementazione può scegliere di memorizzare i valori nella cache e ricalcolarli se necessario. Ad esempio un metodo "getStats" restituirebbe il valore della variabile "stats"; e se la variabile è vuota, dovrebbe essere ricalcolata per prima. Metodi come "removeLifepath" possono rimuovere tutti i valori relativi a Lifepath memorizzati nella cache.

I metodi per il ricalcolo effettivo potrebbero essere inseriti in un'altra classe, se necessario. Quindi avresti: A) l'interfaccia, B) una o più classi che eseguono il calcolo, e C) un'implementazione che mantiene i valori memorizzati nella cache e chiama il ricalcolo quando necessario.

Schizzo rapido:

interface PlayerCharacter {

    List<Lifepath> getLifepaths();

    void addLifepath(Lifepath lifepath);

    void removeLifepath(Lifepath lifepath);

    Skills getSkills();

}

class PlayerCharacterImpl {

    List<Lifepath> lifepaths = new ArrayList<>();
    Skills cachedSkills = null;

    public List<Lifepath> getLifepaths() {
        return Collections.unmodifiableList(lifepaths);
    }

    public void addLifepath(Lifepath lifepath) {
        lifepaths.add(lifepath);
        cachedSkills = null;
    }

    public void removeLifepath(Lifepath lifepath) {
        lifepaths.remove(lifepath);
        cachedSkills = null;
    }

    // thread-unsafe
    public Skills getSkills() {
        if (null == skills) {
            skills = PlayerCharacterCalc.calculateSkills(lifepaths);
        }
        return skills
    }

}

class PlayerCharacterCalc {

    static Skills calculateSkills(List<Lifepath> lifepaths) {
        Skills skills = new Skills();
        for (Lifepath lifepath : lifepaths) {
            skills.apply(lifepath);
        }
        return skills;
    }

}

Questa sarà una risposta parziale poiché non sono un utente regolare di Java (più di un ragazzo C ++). Ecco alcune idee che potrebbero guidarti:

1) Se un attributo può essere modificato da più fonti (uno Stat calcolato con un valore base, bonus / malus da un'abilità e bonus da più lifepath), forse non dovresti salvarlo come un singolo valore, ma come un associazione di valore; e potrebbe essere usato per limitare il valore totale se bacchetta per essere sicuro che non lascerà dei limiti. Ad esempio, qualcosa del genere:

public class StatModifier {
  public String source; // the 'editing' source (ex : a lifepath)
  public String target; // the edited Stat (ex : strength)
  public int modifier;
}

public class Stat {
  private int base;
  private ArrayList<StatModifier> modifiers;
  private int computedValue;
  private int actualValue;
  private bool computed;

  public function addModifier(modifier) { // removeModifier() is basically the same
    modifiers.add(modifier);
    computed = false;
  }
  public function getValue() {
    if (!computed) {
      computedValue = base;
      // TODO : here compute value (ex : sum modifiers)

      actualValue = Math.min(computedValue, 100); // Max stat value : 100
      computed = true;
    }
    return actualValue;
  }
}

Se si utilizza questo metodo, le modifiche di Lifepath sono un elenco di modificatori e quando si aggiunge / rimuove un lifepath, è sufficiente aggiungere / rimuovere i modificatori associati. Quei modificatori sarebbero logicamente presenti nell'istanza Lifepath e la classe PlayerCharacter dovrà solo recuperare questo elenco ed elaborarlo.

2) se devi limitare il valore totale di un gruppo (ad esempio, un personaggio non può avere più di 50 punti abilità in tutte le abilità), potresti usare una classe SkillSet (per esempio) che funzionerebbe come una lista di abilità e un validatore. In questo modo, la classe PlayerCharacter deve solo richiedere il metodo validate () di tutte queste classi per essere sicuro che il carattere sia valido e le regole di convalida effettive saranno gestite impostate per set.

3) mantenere un elenco delle modifiche apportate dall'ultima convalida. In questo modo, se rilevi che l'utente non è valido, puoi eseguire il rollback.

4) se usi '1)', una fase di validazione potrebbe anche essere quella di verificare che le fonti di ogni modificatore (ancora) esista.

Isola e amp; Incapsula la complessità

Tirare i calcoli nelle proprie classi di "funzione". La loro struttura e le relazioni dipendono molto dal tuo progetto esistente.

Forse trasforma affiliations , contacts , ecc. in classi. Questo rende PlayerCharacter più utilizzabile per classi di "funzione".

Con PlayerCharacter ora un insieme di altre classi e proprietà individuali, come opportuno, puoi facilmente creare classi di "dati". Queste classi di dati sono intese come personalizzazioni per le classi funzionali. Il codice di classe della funzione avrà l'aspetto e l'atmosfera di gestire una classe coerente, non un miscuglio di PlayerCharacter e altre classi.

Scrub your Design

Dovrai riesaminare per assicurarti di avere funzionalità fondamentali nelle classi giuste. Ad esempio, ogni classe "data" può avere la sua funzione "cancella" che fa cose molto specifiche e minimali. Una classe "funzione", allo stesso modo, orchestrerà tutte le classi "dati" nel processo di cancellazione generale e farà cose "delete-y" che sono di un contesto interclassico.

Ottieni una visualizzazione di alto livello dei modelli di progettazione

Scopri alcune nozioni di base sui vari modelli. Questo ti darà un'idea di come potresti affrontare il problema. Non sudare i diagrammi delle classi, basta avere le idee e le motivazioni dietro di loro. Non sto dicendo che dovresti implementare esplicitamente un particolare schema o qualsiasi modello. Stai solo cercando ispirazione.

Peso vivo - Stato condiviso.

Visitatore - Esecuzione della stessa operazione su una raccolta di tipi diversi

Metodo modello - definisce un algoritmo in una classe base usando operazioni astratte che sottoclassi l'override per fornire un comportamento concreto.

Adattatore -     Converti l'interfaccia di una classe in un'altra interfaccia che i clienti si aspettano.     Adapter consente alle classi di funzionare insieme, altrimenti non potrebbe a causa di interfacce incompatibili.

Façade - Fornisce un'interfaccia unificata a un insieme di interfacce in un sottosistema. Façade definisce un'interfaccia di livello superiore che semplifica l'utilizzo del sottosistema.