Strutturazione di un'applicazione che legge da un file .properties

0

Ho un'app Java con tre classi: Foo , Bar e Baz . Tutti e tre dipendono da una serie di costanti attualmente definite in ogni classe al fine di determinare come eseguire. Inoltre, Baz interagisce con un numero di classi builder che devono essere configurate in vari modi.

Mi piacerebbe refactoring tutte le informazioni di configurazione in un file .properties in modo che non debba ricompilare ogni volta che cambio una costante.

Ma non sono sicuro di come strutturarlo:

Ho un ConfigInfoSingleton che contiene tutti i parametri dell'applicazione in proprietà statiche e che altre classi chiedono informazioni quando ne hanno bisogno? Sembra sbagliato, poiché introduce lo stato globale.

Consegno un ConfigInfoMap come parametro a tutte le classi che richiedono tali informazioni? Quindi ho bisogno di avere Foo , Bar e Baz che analizzano le stringhe per decidere cosa faranno e questo sembra molto sbagliato. Soprattutto nel caso di Baz , in cui non posso passare solo i valori, ma ho bisogno di utilizzare le istruzioni di switch sulle informazioni di configurazione per determinare le chiamate al metodo del builder.

Analizzo le informazioni in una classe diversa e chiedo a quella classe di dire agli altri come impostarsi? Poi ho una classe che deve conoscere i dettagli di implementazione di tutti gli altri, che sembra sbagliato, ma meno delle altre opzioni.

Questa sembra una domanda molto semplice, ma non sono sicuro di come procedere in termini di buona progettazione del software, e non ho avuto molta fortuna su Google. Qual è la cosa "giusta" da fare?

    
posta Patrick Collins 31.07.2014 - 21:28
fonte

3 risposte

2

Come menzionato da Doval potresti analizzare il tuo file *.properties e creare una classe che rappresenti le tue proprietà e poi passarla alle tue classi.

Un approccio diverso è anche quello di esaminare un framework in grado di gestirlo per te. Spring non si limita a iniettare le proprie dipendenze, ma gestisce anche le proprietà molto bene. Questa domanda fornisce un buon esempio su come utilizzare Spring insieme a *.properties file.

Sono disponibili anche librerie meno invasive come proprietario che supporta il caricamento in tempo reale delle tue proprietà tra altre cose .

    
risposta data 31.07.2014 - 22:25
fonte
1

Analizza il file di configurazione e crea un oggetto che rappresenta i valori del file di configurazione. Quindi puoi decidere come costruire Foo , Bar e Baz in base ai valori dei campi dell'oggetto.

    
risposta data 31.07.2014 - 21:57
fonte
1

Ci sono stato. Fatto.

Quello che ho fatto quando ho avuto una situazione simile è stato:

Per quanto riguarda la configurazione:

  • Creato un wrapper attorno a una classe Properties , ho chiamato quel wrapper Context
  • Quel wrapper legge e analizza il file delle proprietà
  • Ho creato un'interfaccia ContextDependand con un metodo setContext(Context c)
  • Ho Foo , Bar e Baz implementiamo quell'interfaccia
  • Inserisco quell'oggetto Context nelle mie classi Foo , Bar e Baz in modo che possano accedervi senza essere un Singleton

Riguardo al problema di creazione:

  • Ho usato il Builder pattern
  • Ho creato un'interfaccia Builder con solo un metodo di compilazione
  • Crea un FooBuilder, un BarBuilder, un BazBuilder, ecc. che implementa il Builder e restituisce un oggetto che è una superclasse delle mie altre classi o un'interfaccia che implementa
  • Ho aggiunto ogni builder a una HashMap con una chiave, come map.put('FOOBUILDER',new FooBuilder())
  • Quindi, invece di una lunga struttura case , cerco solo il builder in HashMap e gli faccio compilare l'oggetto per me, oppure attraverso l'hash e li compro tutti
  • In questo modo racconto nei file delle proprietà quali oggetti di una raccolta creare e che possono essere eseguiti senza doverli ricompilare

Se la parte Builder non è desiderata, lo devi provare, almeno prova la proprietà wrapper / context injection part.

    
risposta data 31.07.2014 - 22:42
fonte

Leggi altre domande sui tag