Nella pagina Completa codice 25, si dice che è una buona idea poter sostituire facilmente le normali classi di interfaccia utente con una riga di comando.
Conoscendo i suoi vantaggi per i test, per quanto riguarda i problemi che potrebbe portare?
Questo lavoro extra sarà davvero vantaggioso per i progetti web e mobili? Che dire di piccoli e medi progetti; si applicano le stesse regole? Cosa succede se rende il tuo progetto più complesso?
Essere in grado di riutilizzare la funzionalità in diverse interfacce (es. GUI vs CLI vs REST) non è sempre necessaria, ma è bello avere e abilitare riutilizzo fortuito per un sistema, in quanto altre persone trovano nuovi modi per interagire con esso.
Questo ha alcuni svantaggi che devono essere ponderati:
Detto questo, nella mia esperienza l'implementazione di questi livelli ha sempre finito col pagare lo sforzo. In un paio di casi sono riuscito a distribuire i sistemi in tempo perché abbiamo finito per dover scambiare i media (ad esempio dall'integrazione dei servizi Web all'IU) alcune settimane prima della data di scadenza.
Completamente a parte i test, l'ovvio vantaggio di questo approccio è che renderà il tuo progetto automatizzabile e scriptabile . Se sono in grado di inviare comandi da riga di comando a un programma, posso scrivere uno script per eseguire compiti complicati molto più facilmente (e in modo più affidabile!) Di quanto potrei creare una macro per automatizzare la stessa cosa su una GUI. / p>
Indipendentemente dal fatto che valga la pena o meno, ovviamente, dipende interamente dal fatto che tu abbia molti utenti che vorranno automatizzare il tuo programma.
Non è un lavoro extra, solo un lavoro diverso . Se lo fai bene, non solo non lo renderà più complesso, ma lo renderà più semplice perché ti costringerà a disaccoppiare il tuo design. Che tu stia implementando o meno la CLI, il tuo design andrà meglio per renderlo possibile.
Un vantaggio chiave che non sembra essere stato menzionato è che essere in grado di fare questo impone un rigoroso disaccoppiamento dell'interfaccia utente dal codice sottostante. Un vantaggio chiave di questo è che significa che se è necessario modificare in modo significativo la GUI (ad esempio, gli standard iOS per gli standard OSX o un motore grafico su un altro), è tutto che è necessario modificare, poiché il codice sottostante non dipende dal layout dell'interfaccia utente. non può essere, perché se lo fosse, gli strumenti da riga di comando non funzionerebbero.
Oltre a questo, essere in grado di automatizzare i test è un vantaggio chiave.
Sì, è quasi sempre una buona idea.
Se segui questo approccio non avrai probabilmente una logica di business o accesso ai dati nello stesso thread della GUI e dietro qualche gestore della GUI. Vale la pena investire in questo motivo.
Penso che sia una buona idea. Inoltre, essendo in grado di scrivere un secondo front end a riga di comando, in definitiva dimostra che la logica di business è totalmente disaccoppiata rispetto a qualsiasi particolare architettura di application server.
L'unico pericolo che vedo nel fare questo è che per ottenere una certa parte nell'interfaccia utente, l'utente deve normalmente attraversare altre parti dell'interfaccia utente.
Dove lo sviluppatore può semplicemente eseguire l'interfaccia utente direttamente. Ho visto situazioni in cui uno sviluppatore non è riuscito a riprodurre un problema degli utenti fino a quando non ha effettivamente utilizzato il prodotto.
Quindi considera anche questo durante la creazione di test.
No. Terribile consiglio.
È un po 'yagni (non ne avrai bisogno)
L'esposizione di un'interfaccia a riga di comando non equivale a strutturare l'app in modo da supportare il test delle unità, o aderire a qualsiasi parte di SOLID o qualsiasi pratica di programmazione che consiglierei.
Non funziona per nessuna interfaccia utente che non si adatti a un'interfaccia della riga di comando. MS Paint è un'app davvero semplice, ma come, in qualsiasi situazione, vedresti un vantaggio nell'essere in grado di controllarlo da una riga di comando?
Non ti aiuterebbe a implementare lo scripting. In realtà ostacolerebbe qualsiasi progresso in quella direzione.
L'unica cosa positiva è che è apparsa a pagina 25, quindi almeno ricevi un avvertimento che il resto del libro potrebbe essere ... puzzolente. L'ho letto molto tempo fa e non mi è piaciuto, quindi sono di parte.
Notare nuovamente la frase: "[E 'una buona idea essere in grado di sostituire facilmente le normali classi di interfaccia utente con una riga di comando". Ciò non significa che devi scrivere una CLI, solo che potresti farlo facilmente.
Quindi, quello che dice è che l'interfaccia utente dovrebbe essere disaccoppiata dal resto del codice.
Dipende e quando dico che dipende, non è solo questione di avere un paio di casi limite, ma dipende molto dall'applicazione e dal pubblico di destinazione. Supponendo che stiamo eliminando i giochi dall'equazione, c'è ancora una vasta gamma di applicazioni che potresti scrivere dove un comando è improbabile o non verrà mai implementato. In cima alla mia testa, qualsiasi applicazione destinata a un dispositivo mobile (ad esempio, iOS, Android, ecc.) È destinata a rientrare in questa rubrica.
Tenendo presente questo, nello spazio software generale, qualsiasi applicazione che dipende in larga misura dalla visualizzazione (ad esempio PowerPoint, Maya , ecc.) È improbabile che venga mai implementata una sostituzione della riga di comando. Infatti, nel caso di software di grafica come Maya, è discutibile un buon esercizio mentale per determinare come funzionerebbe una versione a riga di comando completa e corretta e potrebbe non essere possibile farlo da un punto di vista dell'utente. Pertanto, è chiaro che ci sono applicazioni definitivamente comuni che possono essere incontrate laddove è improbabile che venga mai vista un'interfaccia simile a comandi, o desiderabile anche se lo scripting dell'applicazione può essere desiderabile.
Successivamente, se consideriamo la forma di suggerimento dal punto di vista dell'architettura generale del software, posso vedere dove avrebbe senso chiedervi periodicamente "Come posso accedere a questa funzione senza l'interfaccia utente?" In generale, se non c'è modo di farlo e non interagisce direttamente con l'utente (ad es. Input gestuale), è probabile che si abbia una situazione in cui è necessario migliorare l'architettura generale. Per facilitare la verifica, è necessario poter accedere direttamente al comando senza passare attraverso l'interfaccia utente, anche se non possono essere invocati tramite una riga di comando. Ciò significa in genere che deve essere presente una solida API e in teoria una buona API dovrebbe consentire l'accesso tramite riga di comando o interfaccia utente. Inoltre, a lungo termine, risparmierai tempo se dovessi aggiungere una nuova interfaccia utente all'applicazione.
Alla fine della giornata, penso che ciò che il suggerimento sta cercando di ottenere abbia senso (es. Avere una buona API e costruire l'interfaccia utente fuori da quella) ma la selezione delle parole potrebbe essere stata un po 'meglio per ottenere il punto di fronte.
Basandosi su ciò che ha detto Mason Wheeler, essere in grado di interagire con un'applicazione tramite una riga di comando rende molto facile automatizzare le attività.
Questo è particolarmente utile nei test.
Per dare un esempio pratico, se voglio eseguire test automatici su un'applicazione, potrei voler installare l'applicazione automaticamente. Per fare questo, potrei passare i seguenti parametri, "myApplication.exe / silentinstall".
Potrei programmarlo in modo tale che quando si specifica questa opzione della riga di comando, un'installazione venga eseguita in modo silenzioso in background, senza il programma di installazione della GUI. Qualsiasi input per l'installer (come la directory di installazione) potrebbe essere prelevato da un file XML, forse.
Fai un altro esempio. La GUI di Microsoft Test Manager (fornita con Visual Studio) consente agli utenti di avviare le esecuzioni di test dall'interfaccia della GUI, ma fornisce anche un'interfaccia della riga di comando per fare la stessa cosa (utilizzando una combinazione di switch e input della riga di comando). Ciò significa che posso combinare uno script PowerShell o DOS per automatizzare l'avvio di test e quindi creare un'attività pianificata in modo che gli script vengano eseguiti ogni notte, forse.
Alcune applicazioni dispongono di opzioni della riga di comando che specificano l'apertura di un'applicazione con determinate opzioni (ad esempio, potrei usare '/ maxim' per aprire l'applicazione in una finestra ingrandita).
Esistono molti scenari in cui potrebbe essere utilizzata un'interfaccia della riga di comando. Questi sono solo alcuni esempi.
Dipende.
Spesso partizioniamo i nostri programmi come modello / vista / controllori o modello / vista / vista / modello. Sembra che il modello dovrebbe consentire l'accesso alla riga di comando, ma non sono sicuro del controller. Naturalmente, la vista è ciò che viene sostituito.
Alcune differenze possono esistere in base alla catena di strumenti. Code Complete è un libro di Microsoft Press, quindi forse stai usando le tecnologie Microsoft per questa GUI? In tal caso, penso che potrebbe esserci una casella di controllo quando crei l'app per esporre le interfacce tramite COM o DCOM. Per alcune tecnologie Microsoft, penso che le tabelle delle risorse e il passaggio dei messaggi siano strettamente associati a qualsiasi cosa che i Wizard possano aiutarti a prototipare rapidamente. Penso che stia migliorando, ma se stai mantenendo MFC o moduli, potrebbe farti male un po '.
In alcuni casi il tuo programma basato su GUI potrebbe essere un involucro attorno a un'interfaccia di gestione o potrebbe avere una logica così piccola, che non c'è molto da controllare tramite l'interfaccia a riga di comando. La creazione di un'app console separata potrebbe essere più veloce e consentire comunque di eseguire script, test o l'utilizzo di ciò che è importante.
Il punto chiave credo sia che il suggerimento non è una regola. Se lo segui, dovresti ottenere un test dell'unità e di accettazione più semplice o un'interfaccia fallback per quando tu o un cliente potresti preferire la digitazione invece di fare clic. Se paga da solo, fallo. Buona fortuna.
Dipende dall'utilità del programma da riga di comando. Alcune cose, come tracciare un percorso su una mappa o giocare a un gioco 3-d, non si prestano a un'interfaccia della riga di comando. Ma altre cose, come gli strumenti di sistema, sono molto meglio dalla riga di comando che da una GUI, per il semplice motivo che possono essere programmate.
Dr. Richard Hipp una volta disse che il suo sistema operativo GUI ideale era un desktop vuoto con un'icona per aprire le finestre di comando e un'altra icona per aprire un browser web. Mi sento quasi allo stesso modo. Se fosse utile come un programma da riga di comando, e non troppo difficile da costruire in quel modo, lo farei. La GUI potrebbe essere un programma completamente separato, forse costruito da qualcun altro!
In questi giorni (almeno per Java) sembra che prima o poi tutti i programmi aggiungano un servizio web (SOAP o Ajax o entrambi) prima o poi. Quindi, in generale, si pensi in questo modo, ma un front end del servizio web è più probabile di una riga di comando se si desidera una migliore metafora mentale ... e più probabile.
C'è un modo diverso di guardare alle cose. Piuttosto che assumere che una linea di comando sia l'unica strada da percorrere, perché non assumere che invece sia possibile utilizzare il controllo vocale? Quindi è necessario un paradigma completamente diverso.
Prima che Jobs prendesse il controllo di Apple, erano stati esplorati meccanismi di controllo vocale molto sofisticati. Apple lo ha schiacciato a favore di cose come Siri.
Sigh.
Popolare e ovvio non sono sempre "i migliori".
Questa è generalmente una buona idea, sì.
Per metafora, le persone potrebbero pensare a questo come a una forma di progettazione RESTful. .... non è, di per sé, come una tipica (G) UI potrebbe coinvolgere complesse transazioni multi-stage come la creazione di account.
Better that one stays away from multi-stage complexity through shopping-cart-like models for transactional setup.
Una volta ho programmato una metafora dell'interfaccia utente drag'n'drop nel browser. Regole di interazione molto complesse sul back-end per rendere naturale l'UX. Ho risolto questo problema rendendo il sito un'API e la GUI era un'app completa che generava eventi dopo l'azione. Un modulo ha rilevato questi eventi e, in un timer, li ha raggruppati in "chiamate API" (per l'efficienza della rete).
Il risultato è stato un sistema core completamente RESTful. Il secondo risultato è stato che avevo un'interfaccia per terze parti, che potevo esporre utilizzando i profili di affiliazione secondo il modello di business.
Un vantaggio è che sarai costretto a pensare al flusso dell'interfaccia utente dal punto di vista dell'utente. (Cosa sto cercando di ottenere? Quale contesto devo impostare? Dato quel contesto, come raggiungo l'obiettivo?)
C'è una grande differenza tra "crea conto bancario" e "scrivi ms word document". Anche se non si costruisce una CLI, potrebbe aggiungere valore solo per considerare il "contesto CLI" necessario. I modelli non vivono solo nel modello di oggetti di business!
Leggi altre domande sui tag design architecture user-interface command-line