Come gestire i dati "statici" del sistema in java

Question

Come gestire i dati "statici" del sistema in java

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

1

Mi stavo chiedendo se esiste un modo migliore per gestire i dati di configurazione "statici" del sistema. Supponiamo che tu abbia un sistema che offre diverse operazioni che sono tradotte in codice in codice operativo, ma è necessario conservare altre informazioni correlate a tale operazione come descrizione, priorità ecc. Il modo brutto che ho visto sono le costanti finali statiche pubbliche. Il modo migliore che stavo usando prima era creare una classe, ad esempio:

public abstract Codebook{
private int id;
private String description;
... getters setters
}

Quindi per la categoria data - in questo caso OperationalCode:

public class OperationalCode extends Codebook{}

Le istanze di questa classe sono state create con i dati di BD. Ora non posso usare DB quindi ho pensato di creare delle fabbriche che popoleranno le classi con un determinato set di parametri. MA tutto è hardcoded alla classe di fabbrica che non mi piace.

C'è una soluzione migliore su come affrontare questo caso perché credo di non essere il primo a risolverlo. Qualche pratica struttura o ...

Non ero probabilmente abbastanza chiaro. Sono pienamente consapevole della funzionalità delle proprietà in java ma non corrisponde ai criteri. Lasciatemi spiegare di più: Quando dico configurazione intendo configurazione aziendale. Non sai mai quanti oggetti possibili otterrai. Ad esempio nel sistema bancario è possibile annullare il contratto e si è costretti a fornire un motivo per la risoluzione: elenco predefinito che include testo, codice nel sistema e traduzione in codici di sistemi di terze parti in cui il sistema deve eseguire anche un'operazione di annullamento. Queste possibilità devono essere esternalizzate dal tuo sistema in quanto probabilmente si spegneranno. I file di proprietà non sembrano una scelta giusta e il sito opposto - usando Buisiness Rule Systems (ad esempio Drools) mi sembra eccessivo. L'uso di enumerazioni con proprietà specificate non si adatta bene alla chiusura perché di volta in volta è necessario essere in grado di riconoscere che è la configurazione e non solo normale enum. Che il motivo dell'ereditarietà di classe - l'operatore instanceof risolva questo problema.

java business-logic configuration-management

posta jaksky 11.09.2013 - 18:05

fonte

2 risposte

Leggi altre domande sui tag java business-logic configuration-management

Come devo implementare un metodo generale che possa essere utilizzato su più modelli di vista? Termine accettato per metodo che chiama semplicemente un altro metodo

score 4 · Answer 1

Memorizza i valori costanti in un file properties chiamato application.properties (ad esempio) ...

property1.value=Hello
property2.value=World
property3.value=Another property

Il contenuto deve corrispondere al modello key=value e inoltre, i parametri sono supportati.

property.with.parameter=My name is {0}.

Se il file è archiviato nella cartella principale del progetto, puoi leggere ognuno di essi in questo modo:

Properties properties = new Properties();

try {
    properties.load(new FileInputStream("application.properties"));
    System.out.println(properties.getProperty("property1.value"));
    System.out.println(properties.getProperty("property2.value"));
    System.out.println(properties.getProperty("property3.value"));
 } catch (IOException ex) {
    ex.printStackTrace();
 }

Puoi leggere ulteriori informazioni su Properties nei tutorial ufficiali Oracle .

score 0 · Answer 2

Alcune lingue hanno un grado di metaprogramming che ti permettono di costruire classi arbitrarie che ereditano da una classe base al volo . Qualcosa sulla falsariga di Ruby (solo un esempio) di (e non pretendo di scrivere un codice rubino valido, anche se se lo si volesse darebbe un'idea del modo in cui guardare):

# get lines of file, or hardcode... whatever
lines.each do |line|
    process line
    cls = Class.new(Object) do
        self.instance_variable_set(name,value)
    end
end

Hai un file di configurazione seduto da qualche parte (in un database?) e lo carica, e fai tutte le classi al volo. Dai un'occhiata a enumerazioni in rubino se vuoi un altro pensiero su come farlo con esso lì.

Java non ha un ricco set di programmazione meta disponibile. Puoi creare classi anonime, ma non sono esattamente delle classi anonime arbitrarie ... e nemmeno quello che vuoi veramente.

Iniziamo con una lezione. Lo chiamo terminationReason . È astratto e ha tutte le logiche di business associate se ne ha bisogno. Ha un costruttore e tu hai la tua fabbrica. Sì, questo è l'approccio che non ti piace - la Factory diventerebbe davvero piuttosto monolitica con tutti i suoi vari valori.

Invece, facciamo diventare terminationReason astratto. Quindi hai le classi che lo implementano. Hai latePayment extends terminationReason . Se non c'è nulla di speciale in latePayment , consiste in un costruttore che ha i valori impostati e questo è tutto. Non vedo alcun problema abbagliante con questa struttura di codice. Non è così flessibile, ma se non si ha bisogno di flessibilità, è possibile regolare alcuni bit della logica per un motivo particolare e si può avere la sicurezza del tipo (è necessario passare un latePayment ad un altro metodo). Voglio sottolineare che questo in realtà non è significativamente migliore rispetto all'utilizzo di un enum. Hai una configurazione codificata rigida in molte piccole classi discrete anziché in enum. È molto più difficile fare cose come "mostra un elenco di opzioni a discesa"

Ciò che potrebbe essere meglio è una combinazione di file di dati strutturati (json, xml o simili) e la fabbrica. Chiedi alla fabbrica di leggere i dati associati e costruisci gli oggetti secondo necessità. Ciò aggiunge un certo grado di flessibilità nel codice: è possibile modificare gli oggetti ei parametri che vengono creati senza ricompilare l'applicazione (si noti 'Le possibilità devono essere esternalizzate dal sistema in quanto probabilmente cambieranno spesso' nella domanda). / p>

C'è un strong caso in cui l'uso di instanceof per separare la funzionalità del codice è un odore di codice. Vedi evitando instanceof in Java o Strumento del codice di istruzioni e polimorfismo o Istanza di In condizionali . E mentre hai ragione che l'ereditarietà è una buona cosa, usare l'instanceof e i condizionali associati per determinare la funzionalità è una brutta cosa.

Se stai pensando di lanciare o sistemi simili, potresti voler dare un'occhiata a lungo e considerarlo di nuovo. Poche applicazioni si riducono di portata col passare del tempo. È anche abbastanza sicuro dire che pochi mantengono lo stesso scopo. Se ti ritrovi a scrivere codice personalizzato che avrebbe dovuto essere fatto in sbavature, o reimplementare la logica che in futuro avrebbe fatto molto più facilmente ... Non so se sbavare sia la cosa giusta per te. So che ho visto molti progetti in cui solo una regola si trasforma in qualcosa che si gonfia in enormi dimensioni in un secondo momento e un sistema di gestione delle regole aziendali potrebbe aver salvato centinaia di ore di codice personalizzato e debugging.