Come gestire la configurazione e lo stato in un programma

Question

Come gestire la configurazione e lo stato in un programma

#1 da (3 voti)
#2 da (1 voti)
#3 da (0 voti)

2

Nella mia azienda abbiamo più programmi C # che usano dizionari in una classe di configurazione per tenere traccia della configurazione e dello stato del programma.

Ad esempio,

bool isFoo = config.GetBool("Foo");

Questo mi sembra strano per una serie di ragioni. Per uno, non esiste un modo semplice per sapere cosa c'è nel Dizionario in un dato momento. (È "Foo" una chiave valida? È già stata impostata? È scritta correttamente? È un bool?)

Questi programmi non sono OO. Lo stile di codifica sembra essere più procedurale (?). In generale ci sono molte chiavi (dell'ordine di 100) e da 2 a 3 dizionari che contengono diversi tipi di dati.

C'è qualche ragione per non fare solo queste proprietà? Per esempio. isFoo = config.Foo;

C'è un modo per migliorare questo codice senza riscriverlo completamente?

object-oriented anti-patterns design-patterns configuration paradigms

posta Era 14.09.2017 - 19:44

fonte

3 risposte

Leggi altre domande sui tag object-oriented anti-patterns design-patterns configuration paradigms

react-redux (React bindings) vs Virtual Dom e Principio di responsabilità singola Creare un'API dall'università per creare una classe

score 3 · Answer 1

Puoi estendere il dizionario e avere il meglio di entrambi i mondi.

class ConfigDictionary : Dictionary
{
    bool getFoo()
    {
        return getBool("Foo");
    }
}

Ora il programma principale può usare la vecchia sintassi o usare una proprietà dedicata e precoce.

score 1 · Answer 2

For one, there is no easy way of knowing what is in the Dictionary at any given time.

Perché no? if(!config.ContainsKey("Foo")) dovrebbe funzionare bene.

Is "Foo" a valid key?

Per questo, è necessario avere l'elenco delle chiavi valide da qualche parte. Dove si ottiene questa meta informazione dipende in gran parte dalla fonte della configurazione e da dove è definita. Se dici che ti aiuterà a definire questa meta informazione una volta e nel contesto della classe di configurazione, renderla una proprietà ti aiuterà.

Has it been set yet?

In caso contrario, il codice genererà un'eccezione "chiave non trovata" in fase di esecuzione, proprio come config.Foo genererà probabilmente un'eccezione quando la proprietà Foo non è stata inizializzata.

Is it spelled correctly?

Una proprietà Foo , con l'ortografia corretta una volta definita, può aiutarti, in effetti, a evitare errori di ortografia in altri punti del codice.

Is it a bool?

Ancora una volta, questo è ciò che una proprietà può aiutarti.

Is there any reason not to just make these properties?

Ci possono essere dei motivi e devi verificare se si applicano al tuo caso. L'aggiunta di proprietà significa che avrai bisogno di una classe individuale per ogni tipo di configurazione. Ciò rende più difficile avere un codice generalizzato che funzioni su diversi tipi di configurazioni. Inoltre, se esiste un codice che crea dinamicamente le stringhe di chiavi (ad esempio, ma concatenando insieme altre due stringhe), questo non può essere semplicemente mappato direttamente alle proprietà.

Questo potrebbe essere un problema o meno per il tuo caso, devi controllarlo.

score 0 · Answer 3

In casi come questo, penso che la soluzione migliore sia qualcosa come:

bool getBool(String key, bool defaultValue);
int getInt(String key, int defaultValue);

ecc ...

Questo copre le tue preoccupazioni riguardo "non è lì". Se l'ortografia è un problema, le tue chiavi potrebbero essere enumerate.

Aggiunto In risposta ai commenti di @Robert Harvey, sì, questo richiede che tu decida "quale è l'impostazione predefinita". (o usa un tipo che può essere nullo, ad es. in Java Integer invece di int ) Ma anche le altre due soluzioni presentate. Richiederà molto più controllo dei risultati. Se la proprietà è assente, in ultima analisi è necessario ricorrere ad alcune impostazioni predefinite, oppure fallire / lanciare un'eccezione. Penso che sia bello essere espliciti e costringere il progettista a pensare alle impostazioni predefinite ragionevoli.

A seconda della tua lingua potresti essere in grado di approfittare di generici o simili. Ad esempio, in Java, per alcuni tipi, è possibile utilizzare:

<T> getConfig(String key, T defaultValue);

Per un'impostazione di configurazione assolutamente essenziale, puoi aggiungere un metodo getRequiredValue(key) che genera un'eccezione.

** Aggiunto ** In alternativa, è possibile precompilare il dizionario con valori predefiniti, quindi le soluzioni di Doc o John funzionano. Il vantaggio (o lo svantaggio) dei miei è che il tuo valore predefinito di fallback può variare in modo dinamico.