Come strutturare correttamente una raccolta di costanti immutabili

Question

Come strutturare correttamente una raccolta di costanti immutabili

#1 da (1 voti)
#2 da (1 voti)

0

Sono in fase di progettazione di un programma basato sull'input ricevuto, selezionerei una particolare categoria e un'azione all'interno di quella categoria. La categoria, l'azione all'interno di e il valore (i) relativi a quell'azione sono tutti valori immutabili, insieme alla relazione tra categoria e azione.

Normalmente assegnerei tutto a un array o una raccolta multidimensionale, ma questo mi sembra sia complesso e inutilmente complesso da cercare e ordinare. Le costanti non mi permettono il lusso di definire le relazioni tra di loro (anche se non puoi avere costante A legato a subConstant B per esempio), ed essendo un'app desktop, avere un utente che installa un server di database non è attraente. Stavo pensando di avere tutto nei file xml, ma le regole di base dell'applicazione non sono allettanti grazie alla possibilità di modificare facilmente, e quindi modificare la funzionalità principale del programma che non vorrei essere modificabile.

Qualcuno si è imbattuto in qualcosa di simile, e in tal caso, qual è stata la configurazione che hai usato per la tua soluzione?

EDIT: fammi vedere se riesco a spiegarlo meglio con un esempio. Dì che ho la seguente struttura

category A
  -- action AB
      -- result 1
      -- result 2
      -- result 3
      -- result 4
      -- result 5
      -- result 6

dove se selezionassi la categoria A e l'azione AB, un lancio di un dado selezionasse il risultato da restituire. La categoria, l'azione e il risultato non cambieranno mai sia nel nome che nella relazione (l'azione AB sarà sempre legata alla categoria A, i risultati all'interno dell'azione AB saranno associati all'azione AB e il contenuto dei risultati non cambierà mai)

EDIT: per questa applicazione non ci si attendono usi di rete, come richiesto in una delle risposte.

data-structures project-structure

posta canadiancreed 13.09.2013 - 16:40

fonte

2 risposte

1

Anche se la domanda è un po 'confusa, posso provare a proporre una soluzione.

Come già accennato da Neil, qui può essere utile una struttura dati ad albero. Immagino, se non è necessario modificare i valori (quelli sono costanti?), Quindi è solo questione di non esporli all'utente finale.

La soluzione leggera potrebbe essere la serializzazione binaria degli hash (oggetti, dizionari, array associativi - la terminologia dipende dalla lingua / framework / piattaforma). Se è necessario tenerli separati dal programma, esistono archivi di valori-chiave semplici ed efficienti (come Berkeley DB). È possibile utilizzare l'approccio basato su SQL anche con sqlite - se non sbaglio, anche il browser Firefox ne usa uno sotto il cofano: non è necessario alcun server di database. Con sqlite è possibile anche la ricerca full-text. Sqlite funziona bene anche con il backend in memoria, nel caso sia necessario.

Ciò che è ancora meglio, le preferenze dell'utente possono anche essere memorizzate in sqlite, in un file diverso.

Da nessuna parte si dice che tali costanti devono essere condivise sulla rete, ma è possibile utilizzare anche l'approccio di serializzazione.

risposta data 13.09.2013 - 17:05

fonte

Leggi altre domande sui tag data-structures project-structure

QFS (Quantcast file system): scalabile per problemi di "big data" di media o solo per estremamente grandi Ricerca di tutti i punti che si trovano su una riga nel sistema di coordinate 2D

score 1 · Accepted Answer

Crea classi o interfacce per categorie, azioni e risultati. Inizia con un elenco per categorie. (Avrai bisogno dell'accesso casuale, quindi questo dovrebbe forse essere un dizionario / mappa, anche se puoi identificarli con interi che un ArrayList potrebbe fare.) Ogni categoria avrà un elenco simile di istanze Action, e ogni azione avrà un elenco delle istanze dei risultati. (In realtà, se si tratta di interfacce anziché di istanze, ciascuna istanza può avere codice completamente diverso tra loro, come meglio si adatta al proprio scopo e gli elenchi possono essere diversi o addirittura inesistenti. È possibile scegliere i risultati con un'istruzione IF in un'unica azione e un array in un altro.)

Ora crei un nuovo risultato creando una nuova istanza di una sottoclasse della classe desiderata, che implementa l'interfaccia necessaria. (Per casi semplici è possibile saltare un passaggio o due.) Si crea un'azione in modo simile, quindi si aggiungono risultati. E una categoria è la stessa, e aggiungi azioni ad essa.

Il punto chiave qui è la flessibilità. Puoi fare praticamente tutto e tutto. Array in un posto, switch in un altro, if-elses da qualche altra parte. Anche dizionari basati su stringhe, ecc. Ecc. Mentre ogni categoria guarda e lavora, per gli estranei, identici tra loro, internamente possono essere completamente diversi.

(Naturalmente, per i casi più semplici un semplice costrutto if-else potrebbe fare l'intero lavoro altrettanto bene.)