Come progettare un programma da riga di comando riutilizzabile per uno sviluppo futuro di una GUI?

Question

Quali sono alcune best practice da tenere a mente quando si sviluppa un programma di script che potrebbe essere integrato con una GUI, probabilmente da qualcun altro, in futuro?

Possibile scenario:

1. ho sviluppare un programma CLI pitone di fantasia che raschia ogni immagini unicorno dal web
2. decido di pubblicarlo su github
3. Un programmatore fan unicorno decide di prendere i sorgenti e costruire una GUI su di loro
4. lui/lei rinuncia perché il mio codice non è riutilizzabile

Come t o prevenire il passaggio quattro lasciando che il programmatore di fan di unicorno costruisca la sua GUI senza troppi problemi?

Answer 1

Lo si fa applicando una buona porzione di stratificazione (magari implementando il pattern MVP) e trattando la CLI come un'interfaccia utente a sé stante.

UPDATE

Questo testo dalla voce di Wikipedia sul modello Model-View-Presenter spiega abbastanza bene.

Model-view-presentatore (MVP) è un utente interfaccia modello di progettazione progettati per facilitare il test unità automatizzata e migliorare la separazione degli argomenti in logica di presentazione.

• Il modello è un'interfaccia che definisce i dati da visualizzare o altrimenti dato seguito nel interfaccia utente.

• La vista è un'interfaccia che visualizza i dati (il modello) e percorsi comandi utente (eventi) al presentatore di agiscono tali dati.

• Il relatore agisce sul modello e sulla vista. Recupera i dati dai repository (il modello), lo mantiene e lo formatta per la visualizzazione nella vista.

Il punto essere principale che è necessario lavorare sulla separazione di preoccupazione nella vostra applicazione. Il CLI sarebbe un'implementazione di una vista , mentre la ventola unicorno implementerebbe un'altra vista per un client ricco. Il fan dell'unicorno, baserebbe il suo punto di vista sugli stessi presentatori della tua CLI. Se questi presentatori non sono sufficienti per il suo ricco cliente, potrebbe facilmente aggiungerne altri, perché ciascun presentatore si basa sui dati del modello. Il modello, a sua volta, è il luogo in cui si basa tutta la logica di base della tua applicazione. Progettare un buon modello è un intero argomento in sé. Potresti essere interessato alla lettura, ad esempio, di Domain-Driven Design, anche se non so quanto si possa applicare alla tua attuale applicazione. Ma è comunque interessante leggere. Come puoi vedere, l'articolo su wikipedia su MVP parla anche di testabilità, che è anche cruciale se vuoi fornire un solido framework per gli altri su cui costruire. Per raggiungere un alto livello di testabilità nel tuo codice base, è spesso una buona idea usare un qualche tipo di framework Dependency Injection.

Spero che questo ti dia un'idea generale delle tecniche che devi impiegare, anche se capisco che potrebbe essere un po 'schiacciante. Non esitate a chiedere se avete ulteriori dubbi.

/Klaus

Answer 2

Sembra una domanda su come scrivere codice utilizzabile.

Quando si considera reusablility di codice, in generale, si dovrebbe cercare di:

• funzionalità separata in moduli
• hanno un'interfaccia ben definita-

funzionalità separazione in moduli

Si dovrebbe provare a separare il codice in parti che hanno una risposta semplice bilità. Ad esempio, un programma che esce su Internet per raschiare le immagini di unicorni può essere separato in sezioni che a) raschia il web per le immagini, b) determina se un'immagine è un unicorno e c) memorizza le suddette immagini di unicorno in alcune specifiche Posizione.

hanno un'interfaccia ben definita

Avere un'interfaccia ben progettata, un'API (Application Programming Interface), sta per essere cruciale per fornire un modo per riutilizzare o estendere un'applicazione.

Fornire punti di ingresso in ogni funzionalità consentirà ad altri programmatori di scrivere effettivamente una nuova interfaccia utente per la funzionalità fornita.

Answer 3

prenderete in ingresso, l'esecuzione di un'azione, e la presentazione di uscita. Potrebbe essere una buona idea usare un meccanismo di callback (come i gestori di eventi, passare un metodo come parametro, o passare questo/self alla classe chiamata) per disaccoppiare i metodi di input e output dall'esecuzione dell'azione.

Oltre a ciò, programma un'interfaccia, non un'implementazione, l'essenza di MVC/MVP, come menzionato da klausbyskov. ad esempio, non chiamare direttamente file.write(); make myModel.saveMyData() che chiama file.write, così qualcun altro può creare somebodysModel.saveMyData() che scrive su un database.

Answer 4

La soluzione a questo tipo di problema è molto semplice, ma in pratica, molti programmatori junior hanno problemi con questo modello. ecco la soluzione:

• a progettare un unicorno-scraping API. Questo è il passo difficile; la buona progettazione dell'API è faticosamente difficile e non ci sono molti esempi da studiare. Un'API che penso valga la pena di studiare è quella del libro di Dave Hanson C Interfaces and Implementations.

• Quindi si progetta l'interfaccia della riga di comando. Se la funzionalità che stai esponendo non è complicata, non è troppo difficile.Ma se è complicato, potresti pensare seriamente alla gestione dell'API utilizzando un linguaggio di scripting incorporato come Lua o Tcl e progettando un'interfaccia per gli script piuttosto che per la riga di comando.

• Finalmente si scrive il codice di elaborazione da riga di comando e si incolla tutto insieme.

vostro ipotetico successore costruisce la sua GUI in uno dei due modi: utilizzando i linguaggi di scripting embedded, o direttamente in cima alla vostra API.

Come indicato in altre risposte, modello/vista/controller può essere un buon modello da utilizzare nella progettazione dell'API.