2013-08-13 11 views
10

Mi è stato chiesto di scrivere una GUI per un programma shell/cmdline esistente scritto in Java e voglio creare un livello di astrazione tra la GUI e il programma originale che faciliti l'aggiunta di una GUI diversa (un web interfaccia, ad esempio, piuttosto che un'applicazione desktop). Al momento, la struttura del programma è il seguente:.Quali sono i pro e i contro dell'uso di XML per trasferire i dati in questo programma Java?

Le opzioni della riga di comando vengono immediatamente tradotti in una tabella hash Java (prendendo un'opzione come -f opt per l'hash "-f=>opt" Queste opzioni vengono poi utilizzati . impostare l'oggetto environment, che il programma utilizza

la struttura ho in mente è:

Seguendo le linee continue, ciò significa che la GUI produce un file XML che contiene le stesse informazioni delle opzioni shell/cmdline, che viene quindi utilizzato per impostare l'opzione environment.

Il fatto è che non sono del tutto sicuro se questo è il modo migliore per far funzionare le cose (da cui le linee tratteggiate, a significare strutture alternative) e anche io non so se XML è la scelta giusta qui.

Allo stato attuale, le parti del programma che configurano l'oggetto environment dallo options si trovano negli stessi metodi delle parti che utilizzano lo environment per ottenere i risultati. Quindi sarebbe più semplice implementare qualcosa che alimentasse gli argomenti shell/cmdline direttamente nel programma piuttosto che implementare una struttura in cui le informazioni venivano passate come un file XML. Certamente non voglio creare il file XML e quindi tradurlo in opzioni shell e trasferirle al programma, ma potrebbe avere più senso per la GUI generare le stesse opzioni della shell piuttosto che creare un XML.

Il vantaggio principale di utilizzare un file XML per quanto posso vedere è che rende più semplice il lavoro degli sviluppatori futuri in quanto possono utilizzare le librerie esistenti per creare i file XML piuttosto che preoccuparsi di ottenere la sintassi -a opt1 -b opt2 -c opt3 [...] corretta .

D'altra parte, ho sentito dire che il tentativo di creare il proprio linguaggio XML è not to be taken lightly (se il programma così com'è memorizza i dati in file XML senza DTD o addirittura uno schema, per quanto posso dire).

Il mio approccio è più o meno giusto? O sto usando strumenti completamente inappropriati per il lavoro che sto cercando di fare?

+2

Una domanda ben presentata, tuttavia ho votato a chiudere perché sembra essere soggettiva/basata sull'opinione pubblica. –

+0

xml potrebbe essere un po 'pesante, potresti prendere in considerazione l'uso di YAML o JSON. –

+1

YAGNI & KISS - generalizza quando hai una seconda GUI concreta non sulla speculazione di ciò che potrebbe venire, fino a quel momento che cosa non va con il 'HashTable' che è già in uso. –

risposta

2

Nell'approccio XML, occorrerebbe scegliere le opzioni utente, creare un XML, passarlo al programma principale, analizzare l'XML ed estrarre i valori per impostare l'ambiente.Questi sforzi saranno eccessivi a meno che non si passino le opzioni da un processo a un altro processo o via cavo (anche in questo caso è possibile utilizzare json)

Se si tratta di un singolo processo in cui vengono passate queste opzioni tramite GUI o riga di comando, possiamo semplicemente incapsulare questi parametri in un oggetto Java, popolarlo usando la riga di comando/GUI e passarlo al programma principale. Per esempio riga di comando o GUI -> Popolare EnvironmentOptions oggetto -> Programma principale

E per fornire richiedono astrazione, è possibile creare un'interfaccia dire IEnvironmentOption e utilizzarlo per impostare le proprietà richieste.

interface IEnvironmentOption { 
    public static final String OPTION_NAME = "-t"; 

    public void setOption(String name, String value); 

    public String getOption(String name); 
} 

class EnvironmentOptions implements IEnvironmentOption { 
    private Properties envProperties; 

    @Override 
    public void setOption(String name, String value) { 
     envProperties.setProperty(name, value); 
    } 

    @Override 
    public String getOption(String name) { 
     return envProperties.getProperty(name); 
    } 
} 
+0

Cosa succede con la riga 'public final final String OPTION_NAME =" -t ";'? –

2

Sembra che tu abbia un piano solido. È un paradigma piuttosto comune per caricare opzioni da argomenti della riga di comando e/o un file di configurazione. Non c'è alcun problema nell'usare XML, ma JSON e YAML sono un paio di alternative con la sintassi di terser che funzionerà altrettanto bene.

Java ha già Properties e Preferences, che può essere utilizzato per realizzare questo. Dovresti dare un'occhiata a quelli prima di reinventare la ruota.

+0

Grazie. La creazione/caricamento dei file di configurazione rallenta molto il programma? Dovrei tenerne conto? Penso che stiamo pianificando di aggiungere una GUI che chiamerà il programma molte volte, quindi le prestazioni sono un problema. –

+0

@ Donkey_2009 È difficile darti una risposta generica. Non sarà necessariamente un problema di prestazioni, ma dipende molto da come lo si codifica. Devi eseguire il programma in un processo separato dalla GUI? Probabilmente sarebbe meglio farlo riferimento come un file libreria/jar in modo che la GUI possa istanziare direttamente oggetti e chiamare i metodi di cui ha bisogno. – elevine

+0

Alla fine, vogliamo sviluppare un'interfaccia web che ci invierà informazioni e riceverà i risultati, quindi sarà necessario un buon modo per incapsulare le informazioni e inviarle a un processo separato che la analizzerà. Ma per ora sto scrivendo un'applicazione desktop con Swing che potrebbe facilmente essere eseguita nello stesso processo del programma stesso (al momento, crea dinamicamente le opzioni della riga di comando e le inserisce direttamente nel programma, ma ovviamente non è un soluzione molto elegante). –

Problemi correlati