É uma boa ideia projetar uma arquitetura pensando que as classes da interface do usuário podem ser substituídas por uma interface de linha de comando?

Ser capaz de reutilizar a funcionalidade sob diferentes interfaces (por exemplo, GUI vs CLI vs REST) nem sempre é necessário, mas é bom ter e ativar reutilização serendipitous para um sistema, como outras pessoas encontram novas maneiras de interagir com ele.

Isso tem algumas desvantagens que precisam ser ponderadas:

1. Isso exigirá camadas adicionais de abstração (às vezes até camadas). Embora ter essas camadas seja uma boa prática de engenharia, elas têm um custo adicional no desenvolvimento, entendendo que isso pode não reduzir o esforço em outras áreas (por exemplo, manutenção, reutilização, testes), portanto vale a pena refletir um pouco sobre isso.
2. O fluxo ideal para um meio pode ser horrível para os outros. Se a funcionalidade foi projetada para suportar uma GUI, ela pode ser muito falante para a web . Nem todas as funcionalidades valem a pena em todos os meios.
3. Há uma armadilha na tentativa de definir um conversor genérico entre serviços e interface do usuário, para que se possa definir o contrato de serviço e derivar automaticamente (ou tanto quanto possível) a interface do usuário para todas as mídias. Muitos projetos perderam muito esforço tentando criar essas estruturas e adicionando todas as personalizações possíveis à medida que os requisitos mudavam.

Dito isto, na minha experiência, implementar essas camadas sempre acabava pagando o esforço. Em alguns casos, consegui implantar sistemas a tempo, pois acabávamos tendo que trocar a mídia (por exemplo, da integração dos Serviços Web para a interface do usuário) algumas semanas antes da data de vencimento.

Completamente além do teste, a vantagem óbvia dessa abordagem é que ela tornará o seu projeto automatável e programável . Se eu sou capaz de enviar comandos de linha de comando para um programa, posso escrever um script para realizar tarefas complicadas com muito mais facilidade (e mais confiável!) Do que eu poderia criar uma macro para automatizar a mesma coisa em uma GUI. / p>

O fato de valer a pena ou não, é claro, depende inteiramente da existência ou não de muitos usuários que desejam automatizar seu programa.

Não é trabalho extra, apenas trabalho diferente . Se você fizer certo, não apenas não o tornará mais complexo, ele o tornará mais simples porque o forçará a desacoplar seu design. Quer você realmente implemente ou não o CLI, seu projeto será melhor para possibilitar isso.

Uma vantagem importante que parece não ter sido mencionada é que ser capaz de fazer isso praticamente reforça o desacoplamento estrito da interface do usuário a partir do código subjacente. Uma das principais vantagens disso é que isso significa que, se você precisar alterar significativamente a GUI (por exemplo, os padrões iOS para OSX ou um mecanismo gráfico para outro), isso é tudo que você precisa alterar, como código subjacente não depende do layout da interface do usuário. Não não pode ser, porque se fosse, as ferramentas de linha de comando não funcionariam.

Além disso, poder automatizar os testes é uma vantagem fundamental.

Sim, é quase sempre uma boa ideia.

Se você seguir essa abordagem, provavelmente não terá uma lógica de negócios ou acesso a dados em um mesmo encadeamento como GUI e por trás de algum manipulador de GUI. Só esta razão vale a pena investir.

Eu acho que é uma boa ideia. Além disso, ser capaz de escrever um segundo front-end de linha de comando, prova que a lógica de negócios é totalmente desacoplada a qualquer arquitetura de servidor de aplicativos em particular.

O único perigo que vejo em fazer isso é que para chegar a uma determinada parte da interface do usuário, o usuário normalmente tem que percorrer outras partes da interface do usuário.

Onde o desenvolvedor pode apenas executar a interface do usuário diretamente. Já vi situações em que um desenvolvedor não conseguiu reproduzir um problema de usuário até que ele realmente utilizasse o produto.

Então, inclua isso também ao criar testes.

Não. Um conselho terrível.

É um pouco yagni (você não vai precisar disso).

Expor uma interface de linha de comando não é o mesmo que estruturar seu aplicativo de forma a oferecer suporte a testes de unidade ou a qualquer parte do SOLID ou a qualquer prática de programação que eu recomende.

Não funciona para nenhuma interface do usuário que não seja adequada a uma interface de linha de comando. O MS Paint é um aplicativo realmente simples, mas como, em qualquer situação, você veria um benefício em poder controlá-lo a partir de uma linha de comando?

Não ajudaria você a implementar o script. Isso realmente impediria qualquer progresso nessa direção.

A única coisa positiva é que apareceu na página 25, então pelo menos você recebe um aviso de que o resto do livro pode ser ... fedorento. Eu li isso há muito tempo e não gostei, então sou parcial.

Observe a frase novamente: "[É uma boa idéia poder substituir facilmente as classes da interface do usuário regular por uma linha de comando". Isso não significa que você tem que escrever um CLI, apenas que você poderia fazê-lo facilmente.

Então, o que você diz é que sua interface do usuário deve ser dissociada do resto do código.

Depende e quando digo que depende, não é apenas uma questão de ter alguns casos de limites, mas é muito dependente da aplicação e do público-alvo. Supondo que estamos eliminando os jogos da equação, ainda há uma grande variedade de aplicativos que você pode estar escrevendo onde um comando é improvável ou nunca será implementado. Na minha opinião, qualquer aplicativo que segmenta um ambiente para dispositivos móveis (por exemplo, iOS, Android, etc.) provavelmente se enquadra neste título.

Com isso em mente, no espaço geral do software, qualquer aplicativo altamente dependente da visualização (por exemplo, PowerPoint, Maya , etc.) é improvável que alguma vez uma substituição de linha de comando seja implementada. De fato, no caso de softwares gráficos como o Maya, é discutível um bom exercício mental determinar como uma versão completa e apropriada da linha de comando funcionaria e pode não ser possível fazê-lo do ponto de vista do usuário. Assim, é claro que existem aplicações comuns que podem ser encontradas onde um comando como interface provavelmente nunca será visto, ou desejável, mesmo que o script da aplicação seja desejável.

Em seguida, se observarmos a forma de sugestão do ponto de vista da arquitetura geral de software, posso ver onde faria sentido se perguntar periodicamente "Como posso acessar esse recurso sem a interface do usuário?" Em geral, se não houver nenhuma maneira de fazer isso e não estiver interagindo diretamente com o usuário (por exemplo, entrada de gesto), é provável que você tenha uma situação em que a arquitetura geral precise ser melhorada. Para permitir a facilidade de teste, você desejará ser capaz de acessar diretamente o comando sem passar pela interface do usuário, mesmo que eles não possam ser chamados por meio de uma linha de comando. Isso geralmente significa que uma API sólida precisa estar em vigor e, teoricamente, uma boa API deve permitir o acesso via linha de comando ou interface do usuário. Além disso, a longo prazo, você economizará tempo se precisar adicionar uma nova interface de usuário ao aplicativo.

No final do dia, acho que o que a sugestão está tentando fazer faz sentido (ou seja, ter uma boa API e construir sua interface de usuário), mas a seleção de palavras pode ter sido um pouco melhor o ponto do outro lado.

Com base no que o Mason Wheeler disse, poder interagir com um aplicativo por meio de uma linha de comando torna muito fácil automatizar tarefas.

Isso é particularmente útil em testes.

Para dar um exemplo prático, se eu quiser executar testes automatizados em um aplicativo, talvez queira instalar o aplicativo automaticamente. Para fazer isso, posso passar os seguintes parâmetros, "myApplication.exe / silentinstall".

Eu posso programá-lo para que, quando eu especificar esse comutador de linha de comando, uma instalação seja executada silenciosamente em segundo plano, sem o instalador da GUI. Qualquer entrada para o instalador (como o diretório de instalação) pode ser escolhida de um arquivo XML, talvez.

Tome outro exemplo. A GUI do Microsoft Test Manager (fornecida com o Visual Studio) permite que os usuários iniciem execuções de teste a partir de sua interface GUI, mas também fornece uma interface de linha de comando para fazer a mesma coisa (usando uma combinação de opções e entradas de linha de comando). Isso significa que posso combinar um script do PowerShell ou do DOS para automatizar o lançamento de testes e, em seguida, criar uma tarefa agendada para que os scripts sejam executados todas as noites, talvez.

Alguns aplicativos têm opções de linha de comando que especificam a abertura de um aplicativo com certas opções (por exemplo, eu posso usar '/ maximizar' para abrir o aplicativo em uma janela maximizada).

Existem muitos cenários em que uma interface de linha de comando pode entrar em uso. Estes são apenas alguns exemplos.

Depende.

Frequentemente nós particionamos nossos programas como model / view / controllers ou model / view / view / model. Parece que o modelo deve permitir acesso à linha de comando, mas não tenho tanta certeza sobre o controlador. Naturalmente, a visão é o que está sendo substituído.

Algumas diferenças podem existir com base na cadeia de ferramentas. Código Completo é um livro da Microsoft Press, então talvez você esteja usando tecnologias Microsoft para essa GUI? Se assim for, acho que pode haver uma caixa de seleção quando você cria o aplicativo para expor interfaces via COM ou DCOM. Para algumas tecnologias da Microsoft, acho que as tabelas de recursos e a passagem de mensagens são muito intensamente associadas a qualquer coisa que os assistentes o ajudem a criar rapidamente protótipos. Eu acho que está ficando melhor, mas se você está mantendo MFC ou Forms, pode doer um pouco.

Em alguns casos, seu programa baseado em GUI pode ser um wrapper em torno de uma interface de gerenciamento ou pode ter uma lógica tão pequena, que não há muito a ser controlado pela interface de linha de comando. Criar um aplicativo de console separado pode ser mais rápido e ainda permitir que você crie scripts, teste ou use o que é importante.

O ponto-chave, eu acho, é que a sugestão não é uma regra. Se você segui-lo, você deve obter testes mais fáceis de unidade e aceitação ou uma interface de retorno para quando você ou um cliente preferir digitar em vez de clicar. Se se paga, faça isso. Boa sorte.

Depende da utilidade do programa de linha de comando. Algumas coisas, como traçar uma rota em um mapa ou jogar um jogo 3-d, simplesmente não se prestam a uma interface de linha de comando. Mas outras coisas, como as ferramentas do sistema, são muito melhores na linha de comando do que na GUI, pela simples razão de que podem ser roteirizadas.

Dr. Richard Hipp disse uma vez que seu sistema operacional GUI ideal era um desktop vazio com um ícone para abrir janelas de comando e outro ícone para abrir um navegador da web. Eu me sinto quase do mesmo jeito. Se fosse útil como um programa de linha de comando, e não muito difícil de construir dessa maneira, eu faria isso. A GUI pode ser um programa completamente separado, talvez construído por outra pessoa!

Hoje em dia (pelo menos para Java) parece que, mais cedo ou mais tarde, todos os programas adicionam um serviço web (SOAP ou Ajax ou ambos) mais cedo ou mais tarde. Então, em geral, sim, pense assim, mas um front-end de serviço da Web é mais provável do que uma linha de comando se você quiser uma metáfora mental melhor ... e uma mais provável.

Existe uma maneira diferente de ver as coisas. Em vez de assumir que uma linha de comando é o único caminho a seguir, por que não assumir que o controle de fala pode ser usado? Um paradigma totalmente diferente é necessário então.

Antes de Jobs assumir a Apple, mecanismos sofisticados de controle de voz estavam sendo explorados. A Apple esmagou isso em favor de coisas como Siri.

Suspiro.

Popular e óbvio nem sempre são "melhores".

Isso geralmente é uma boa ideia, sim.

Por metáfora, as pessoas podem pensar nisso como uma forma de design RESTful. .... não é, por si só, como uma interface (G) típica pode envolver transações complexas em vários estágios, como a criação de contas.

Better that one stays away from multi-stage complexity through shopping-cart-like models for transactional setup.

Uma vez eu programei uma metáfora de arrastar e soltar no navegador. Regras de interação muito complexas no back-end para tornar o UX mais natural. Eu resolvi isso fazendo do site uma API e a GUI era um aplicativo completo que gerava eventos em ação. Um módulo detectou esses eventos e, em um timer, os agrupou em 'chamadas de API' (para eficiência de rede).

O resultado foi um sistema principal completamente RESTful. O segundo resultado foi que eu tinha uma interface para terceiros, que eu poderia expor usando perfis de afiliação de acordo com o modelo de negócios.

Uma vantagem é que você será forçado a pensar sobre o fluxo da interface do usuário da perspectiva do usuário. (O que estou tentando alcançar? Que contexto preciso configurar? Dado esse contexto, como eu alcanço a meta?)

Existe uma grande diferença entre "criar uma conta bancária" e "escrever um documento do tipo ms". Mesmo se você não construir um CLI, ele poderá adicionar valor apenas para considerar o "contexto CLI" necessário. Modelos não apenas vivem no modelo de objetos de negócios!