Best practice per propagare le preferenze dell'applicazione

Question

Best practice per propagare le preferenze dell'applicazione

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

0

Qual è il tuo approccio con la propagazione a tutte le classi / finestre di preferenze / impostazioni della tua applicazione?

Condividete la classe preference_manager a tutte le classi / finestre che ne hanno bisogno o create variabili in ogni classe / windows e aggiornate manualmente ogni volta che vengono cambiate le impostazioni?

Attualmente ho una classe PreferencesInterface che contiene tutte le preferenze ed è responsabile di default tutti i valori con un metodo dedicato chiamato su create e quando necessario, tutti i valori sono pubblici, quindi non getter / setter, anche esso ha% virtuale co_de metodi% / SavePreferences .

Quindi ho LoadPreferences che si estende da PreferencesManager ed è responsabile dell'attuazione effettiva di PreferencesInterface / SavePreferences . L'ho fatto fondamentalmente per multipiattaforma in modo che ogni piattaforma possa avere un'implementazione differente dell'archiviazione reale (registro, ini, plist, xml, qualunque ).

design programming-practices class-design

posta Shebuka 28.09.2012 - 11:12

fonte

3 risposte

1

Tra le opzioni che offri, schiererei sicuramente il primo.

Avere una singola classe o un oggetto che è responsabile della conservazione delle informazioni sulle preferenze degli utenti, che viene interrogata dalle parti interessate, è molto più gestibile che avere una classe che potrebbe essere interessata a duplicare la memorizzazione di queste impostazioni e dover compilare un elenco sempre crescente di parti che devono essere aggiornate ogni volta che qualcosa cambia.

risposta data 28.09.2012 - 11:27

fonte

0

L'unico inconveniente della propagazione di PreferencesManager che vedo è che non puoi davvero sapere che ad un certo punto la classe esiste ancora (il puntatore non punta semplicemente su una memoria sporca), ma l'enorme il vantaggio è che le impostazioni vengono applicate a tutte le applicazioni al volo .

L'altro approccio è più sicuro perché sei veramente sicuro che le variabili siano accessibili in qualsiasi momento, ma è più propositivo propagare le modifiche.

Non so davvero cosa c'è di meglio ...

risposta data 28.09.2012 - 13:27

fonte

Leggi altre domande sui tag design programming-practices class-design

Persuadere la gestione che il codice di refactoring è una buona idea [duplicato] Migrazione del vecchio progetto Asp.net 1.1 in mvc 3 o 4

score 2 · Accepted Answer

Sarebbe positivo avere una classe Preferences e una classe PreferenceManager che estenda / usi Preferences dove il primo avrà metodi getter per tutte le preferenze e quest'ultimo aggiungerà setter per lo stesso. Il primo può essere condiviso con tutte le parti dell'app che hanno bisogno di accedere alle preferenze. Quest'ultimo sarà usato solo dal contesto (i) che può modificare / ha accesso in scrittura alle preferenze.