Standard per l'implementazione di GUI per utilità della riga di comando

Ciò che è più favorevolmente considerato penso sia in realtà scrivere SweetApp e libsweetapp insieme, con l'applicazione della riga di comando SweetApp un wrapper CLI completo ma minimalista attorno alla libreria. Quindi, la grafica GSweetApp o KSweetApp utilizza quella lib per creare l'applicazione GUI.

Oltre a ciò, non esiste uno standard autorevole e in definitiva qualunque cosa faccia il lavoro alle persone è tutto ciò che conta. Quello che ho descritto e tutte e due le possibili soluzioni sono comuni.

Non posso darti esempi rappresentativi di applicazioni ampiamente utilizzate con GUI e CLI ma, come regola generale di buona architettura, la logica del tuo programma dovrebbe essere disgiunta dalla logica di interazione dell'utente. Anche se si intende fornire un'interfaccia utente singola, questo tipo di modularità sarà ancora molto prezioso per il test dell'unità.

I dettagli potrebbero dipendere dal tipo di applicazione, ma la soluzione più pulita sembra essere quella di mettere tutta la logica del programma in una libreria che viene poi utilizzata (collegata a) dalla propria applicazione CLI e GUI. Nota come questo apre anche l'opportunità di usare il tuo strumento senza alcuna interfaccia utente come libreria.

Tuttavia, se il tuo strumento è piuttosto semplice e ti ritroverai più a tuo agio nella codifica della GUI in un'altra lingua rispetto all'applicazione CLI, potrebbe essere preferibile scrivere semplicemente la GUI come script di wrapper attorno alla CLI. Ciò presenta tuttavia degli svantaggi, poiché la comunicazione tra i processi richiede che tutti i parametri siano correttamente caricati e non indirizzati al / dal testo e che gli errori di comunicazione tra i processi siano generalmente più complicati. Alcuni programmi CLI offrono quindi contrassegni speciali che consentono loro di accettare / produrre input / output in un formato più appropriato per l'elaborazione della macchina.