I vantaggi dell'utilizzo dei file di configurazione rispetto alla creazione di molte classi piccole?

Centinaia di classi sono un problema semplicemente perché sarai costretto a creare una complessa gerarchia ereditaria. Il principio principale che si oppone a questo è il principio Composizione sull'ereditarietà . L'ereditarietà su una scala così ampia ha grossi inconvenienti, oltre a dover semplicemente conoscere centinaia di classi.

Suggerisco anche di creare un'interfaccia per Unit e spostare la concentrazione mentale: pensa meno alle statistiche e alle abilità delle singole unità, ma più al comportamento generale delle unità.

Ad esempio, un'unità può essere in grado di muoversi. In questo caso, puoi aggiungere un'interfaccia ortogonale (cioè, non è necessario ereditare dall'interfaccia Unit pari) per Movable cose, che ti permette di interrogare fino a che punto possono muoversi, sia che lo spostamento verso x / y sia valido, o per eseguire effettivamente l'operazione di spostamento. Allo stesso modo, non pensare a "questa unità ha x salute", ma pensa che le unità siano danneggiabili con le possibili conseguenze della morte.

Per la configurazione effettiva delle unità che devi ovviamente fornire queste statistiche e abilità in qualche forma di configurazione (insieme a immagini / animazioni / ecc.). Per il recupero, tuttavia, ti suggerisco di dare un'occhiata da vicino al modello di fabbrica .

Infine, hai proposto una "master unit class", che mi ricorda di farti conoscere l' God object anti -modello. Non cadere in questo altro estremo. Ci sono molte più scelte rispetto a centinaia di classi rispetto a una classe. L'intero spettro tra questi è anche fattibile, e certamente molto più preferibile rispetto agli estremi.

In effetti, centinaia di classi si sbagliano. Sembra che il tuo collega voglia creare una classe separata, dove in effetti hai istanze separate della stessa classe. Ad esempio:

Animal
    Cat
        Black cat
        Brown cat
    Dog
        ...

è una gerarchia di classi sbagliata. Uno dovrebbe invece limitarsi a:

Animal
    Cat
    Dog

con Cat con una proprietà FurColor .

Nel tuo contesto, questo significa che diverse statistiche e abilità saranno presentate come proprietà, mentre tutte le unità condividono la stessa classe o hanno alcune classi specifiche.

Ora, dove inserire le informazioni sulle unità? Hai la seguente scelta:

• Codice hard,
• Utilizza i file di configurazione,
• Utilizza database.

Il primo ha un grosso svantaggio: devi ricostruire¹ l'applicazione ogni volta che vuoi cambiare un aspetto di un'unità. Ciò rende praticamente impossibile la regolazione e la personalizzazione.

Il secondo e il terzo sono la stessa cosa, dal momento che i file di configurazione sono anche un database. Quello che dovrebbe preoccuparti è scegliere un livello di severità corretto per il tuo database. Un database relazionale sarebbe probabilmente una scelta sbagliata, a meno che non siate assolutamente sicuri di non modificare lo schema nel tempo. Se la scelta è tra un NoSQL e, ad esempio, un mucchio di file XML, vedi cosa è più facile e più flessibile per te; inoltre, non reinventare la ruota.

^{¹ Build ≠ compile. Se utilizzi un linguaggio digitato in modo dinamico, devi comunque eseguire test per creare una versione stabile su ogni modifica che apporti.}

Il modo corretto dipende da molti fattori, ma uno di questi è il modo in cui queste unità differiscono l'una dall'altra.

Se le unità differiscono l'una dall'altra nei valori (iniziali) che hanno per i loro attributi (che sono tutti comuni a tutte le unità), allora l'idea di usare i dati di configurazione è un buon modo per creare facilmente molti differenti unità.

D'altra parte, se le diverse unità devono rispondere in modo diverso alle interazioni con altre entità nel tuo gioco (dove una risposta diversa significa scrivere un codice diverso), allora la soluzione migliore è usare classi diverse per le diverse unità, che tutte derivano da una classe base comune che definisce gli attributi comuni e le interfacce del metodo.

Come terza possibilità, potresti avere una combinazione delle due opzioni. In tal caso, dovresti utilizzare anche una combinazione di design: classi diverse per i gruppi di unità che mostrano comportamenti diversi, con i dati di configurazione per creare le diverse unità all'interno di ciascun gruppo.