Best practice per la creazione di una classe di configurazione 'globale' utilizzata da numerosi componenti

Question

Best practice per la creazione di una classe di configurazione 'globale' utilizzata da numerosi componenti

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

8

Ho un grande progetto con una parte del driver e circa 5 librerie che svolgono varie attività associate. Molte librerie richiedono l'accesso a dati di configurazione "globali" che vengono letti da un database all'avvio dal codice del driver. Per driver intendo solo la parte che contiene la funzione principale.

La mia idea su come gestire questo è stato quello di creare una classe di configurazione con un metodo statico per ottenere gli elementi di configurazione. È questo l'approccio migliore? In che altro modo si potrebbe ottenere ciò?

es:

class config {
 public:
   static get_item(key);

 private:
   static values;
};

Il design singleton è appropriato qui?

c++ static-access

posta user619818 07.05.2013 - 14:26

fonte

2 risposte

1

Penso che questa sia una delle volte in cui un Singleton è effettivamente la cosa giusta da fare.

Per quanto riguarda l'interfaccia della classe stessa, è possibile fare il nome-chiave-chiave o disporre di accessor per i singoli valori di configurazione. Quest'ultimo schema offre una certa comodità (completamento IDE per uno) e consente di trasmettere i valori di configurazione ai propri tipi di dati corretti prima di utilizzarli. Introduce anche una certa separazione tra gli utenti della classe di configurazione e la sua implementazione interna (il fatto che tutti i valori di configurazione siano memorizzati come, ad esempio, stringhe, è un dettaglio di implementazione che l'utente della classe non dovrebbe preoccupare).

risposta data 07.05.2013 - 14:36

fonte

Leggi altre domande sui tag c++ static-access

Come è possibile scrivere il compilatore di un linguaggio di programmazione con quello stesso linguaggio [duplicato] Restituire un IQueryable da un IRepository

score 12 · Accepted Answer

Il modo non singleton consiste nel creare una classe di configurazione regolare con proprietà / membri regolari, creare un'istanza dell'oggetto con le impostazioni corrette dal database nel driver e passare l'istanza a tutte le librerie, probabilmente tramite uno std: : shared_ptr. Questo è un modello di progettazione comune chiamato Iniezione di dipendenza .

In tal modo si evitano tutti i potenziali problemi del modello di progettazione singleton e il codice sarà più testabile in quanto è possibile creare un'istanza della classe di configurazione in qualsiasi modo si desideri, con qualsiasi dato, per il test.