¿Es una buena idea diseñar una arquitectura pensando que las clases de la interfaz de usuario se pueden reemplazar por una interfaz de línea de comandos?

En Code Complete, página 25, se dice que es una buena idea poder reemplazar fácilmente las clases normales de la interfaz de usuario por una línea de comando.

Conociendo sus ventajas para las pruebas, ¿qué pasa con los problemas que puede traer?

¿Este trabajo extra realmente valdrá la pena para proyectos web y móviles? ¿Qué pasa con los proyectos pequeños y medianos? ¿Se aplican las mismas reglas? ¿Qué pasa si hace que su diseño sea más complejo?

Ser capaz de reutilizar la funcionalidad bajo diferentes interfaces (por ejemplo, GUI vs CLI vs REST) ​​no siempre es necesario, pero es bueno tenerlo y permitir la reutilización fortuita de un sistema, ya que otras personas encuentran nuevas formas de interactuar con él.

Esto tiene algunos inconvenientes que deben ser ponderados:

1. Requerirá capas de abstracción adicionales (a veces incluso niveles). Si bien tener estas capas es una buena práctica de ingeniería, tienen un costo adicional en el desarrollo, entendiendo que puede no reducir el esfuerzo en otras áreas (por ejemplo, mantenimiento, reutilización, prueba), por lo que vale la pena reflexionar un poco al respecto.
2. El flujo óptimo para un medio puede ser horrible para otros. Si la funcionalidad fue diseñada para admitir una GUI, puede ser demasiado hablador para la web . No toda la funcionalidad vale la pena en todos los medios.
3. Hay una trampa al tratar de definir un convertidor genérico entre los servicios y la interfaz de usuario, por lo que uno puede definir el contrato de servicio y derivar automáticamente (o tanto como sea posible) la IU para todos los medios. Muchos proyectos desperdiciaron demasiado esfuerzo tratando de construir dichos marcos y añadiéndole todas las personalizaciones posibles a medida que cambiaban los requisitos.

Dicho esto, en mi experiencia, la implementación de tales capas siempre terminó pagando el esfuerzo. En un par de casos, logré implementar sistemas a tiempo porque terminamos teniendo que intercambiar medios (por ejemplo, desde la integración de servicios web a la interfaz de usuario) unas semanas antes de la fecha de vencimiento.

Completamente aparte de las pruebas, la ventaja obvia de este enfoque es que hará que su proyecto sea automatizable y programable . Si puedo enviar comandos de línea de comandos a un programa, puedo escribir un script para realizar tareas complicadas mucho más fácilmente (¡y de manera más confiable!) De lo que podría crear una macro para automatizar lo mismo en una GUI.

Si vale la pena hacerlo o no, por supuesto, depende completamente de si tienes muchos usuarios que quieran automatizar tu programa.

No es trabajo extra, solo trabajo diferente . Si lo hace bien, no solo no lo hará más complejo, sino que lo hará más simple porque lo obligará a desacoplar su diseño. Independientemente de si implementa o no la CLI, su diseño será mejor para que sea posible hacerlo.

Una ventaja clave que no parece haber sido mencionada es que ser capaz de hacer esto impone un desacoplamiento estricto de la interfaz de usuario del código subyacente. Una ventaja clave de esto es que significa que si necesita cambiar significativamente la GUI (por ejemplo, los estándares de iOS a los estándares de OSX, o un motor gráfico a otro), eso es todo lo que necesita cambiar, ya que el código subyacente no depende de El diseño de la interfaz de usuario. No puede ser, porque si lo fuera, las herramientas de línea de comando no funcionarían.

Aparte de eso, poder automatizar las pruebas es una ventaja clave.

Sí, casi siempre es una buena idea.

Si sigue este enfoque, es probable que no tenga una lógica de negocios o acceso a datos en un mismo hilo que la GUI, y detrás de algún controlador de GUI. Solo vale la pena invertir en esta razón.

Creo que es una buena idea. Además, al poder escribir un segundo front-end de línea de comandos, se demuestra que la lógica empresarial está totalmente desacoplada a cualquier arquitectura de servidor de aplicaciones en particular.

El único peligro que veo al hacer esto es que para llegar a cierta parte de la interfaz de usuario, el usuario normalmente tiene que atravesar otras partes de la interfaz de usuario.

Mientras que el desarrollador solo puede ejecutar la interfaz de usuario directamente. He visto situaciones en las que un desarrollador no pudo reproducir un problema de los usuarios hasta que realmente usaron el producto.

Así que tenga eso en cuenta también al crear pruebas.

No. Terrible consejo.

Es un poco yagni (no lo vas a necesitar).

Exponer una interfaz de línea de comandos no es lo mismo que estructurar su aplicación de una manera que admita pruebas unitarias o cumpla con cualquier parte de SOLID o cualquier práctica de programación que recomiendo.

No funciona para ninguna interfaz de usuario que simplemente no se adapte a una interfaz de línea de comandos. MS Paint es una aplicación realmente simple, pero ¿cómo, en cualquier situación, verías un beneficio de poder controlarlo desde una línea de comandos?

No le ayudaría a implementar secuencias de comandos. De hecho, obstaculizaría cualquier progreso en esa dirección.

Lo único positivo es que apareció en la página 25, así que al menos recibes una advertencia de que el resto del libro podría ser ... maloliente. Lo leí hace mucho tiempo y no me gustó, así que soy parcial.

Sobre la base de lo que dijo Mason Wheeler, poder interactuar con una aplicación a través de una línea de comandos hace que sea muy fácil automatizar las tareas.

Esto es particularmente útil en las pruebas.

Para dar un ejemplo práctico, si quiero ejecutar pruebas automatizadas en una aplicación, es posible que desee instalar la aplicación automáticamente. Para hacer esto, podría pasar los siguientes parámetros, "myApplication.exe / silentinstall".

Podría programarlo para que cuando especifique este modificador de línea de comandos, una instalación se realice de forma silenciosa en segundo plano, sin el instalador de la GUI. Quizás cualquier entrada al instalador (como el directorio de instalación) podría recogerse de un archivo XML.

Toma otro ejemplo. Microsoft Test Manager GUI (viene con Visual Studio) permite a los usuarios iniciar ejecuciones de prueba desde su interfaz GUI, pero también proporciona una interfaz de línea de comandos para hacer lo mismo (usando una combinación de entradas y cambios de línea de comandos). Esto significa que puedo crear un script de PowerShell o DOS para automatizar el inicio de las pruebas, y luego podría crear una tarea programada para que los scripts se ejecuten todas las noches, tal vez.

Algunas aplicaciones tienen modificadores de línea de comandos que especifican que una aplicación se abra con ciertas opciones (por ejemplo, podría usar '/ maximizar' para abrir la aplicación en una ventana maximizada).

Hay muchos escenarios en los que podría usarse una interfaz de línea de comandos. Estos son solo algunos ejemplos.

Observe la frase nuevamente: "[Es una buena idea poder reemplazar fácilmente las clases normales de la interfaz de usuario por una línea de comando". No significa que tenga que escribir una CLI, solo que podría hacerlo fácilmente.

Entonces, lo que dice es que su interfaz de usuario debe estar desacoplada del resto del código.

Depende y cuando digo que depende, no se trata solo de tener un par de casos extremos, sino que depende mucho de la aplicación y del público objetivo. Suponiendo que estamos eliminando juegos de la ecuación, todavía hay una amplia gama de aplicaciones que puede estar escribiendo donde un comando como es poco probable o nunca se implementará. Fuera de mi cabeza, cualquier aplicación dirigida a un entorno móvil (p. Ej., IOS, Android, etc.) probablemente caiga bajo este encabezado.

Con eso en mente, en el espacio de software general, es poco probable que cualquier aplicación que dependa en gran medida de la visualización (por ejemplo, PowerPoint, Maya , etc.) vea que se implemente un reemplazo de línea de comando. De hecho, en el caso de software de gráficos como Maya, es discutible un buen ejercicio mental para determinar cómo funcionaría una versión completa y adecuada de la línea de comandos y es posible que no sea posible desde el punto de vista del usuario. Por lo tanto, está claro que definitivamente se pueden encontrar aplicaciones comunes en las que es poco probable que se vea un comando como la interfaz, o sea deseable, incluso si las secuencias de comandos de la aplicación pueden ser deseables.

A continuación, si observamos la forma sugerente desde el punto de vista de la arquitectura de software general, puedo ver dónde tendría sentido preguntarse periódicamente "¿Cómo puedo acceder a esta función sin la interfaz de usuario?" En general, si no hay forma de hacerlo y no está interactuando directamente con el usuario (por ejemplo, entrada de gestos), entonces es probable que tenga una situación en la que la arquitectura general necesita ser mejorada. Para facilitar las pruebas, querrá poder acceder directamente al comando sin pasar por la interfaz de usuario, aunque no se puedan invocar a través de una línea de comando. Esto generalmente significa que se necesita una API sólida y, en teoría, una buena API debería permitir el acceso a través de la línea de comandos o la interfaz de usuario. Además, a la larga,

Al final del día, creo que lo que la sugerencia está tratando de obtener tiene sentido (es decir, tener una buena API y construir su interfaz de usuario a partir de eso), pero la selección de palabras podría haber sido un poco mejor para transmitir el punto .

Depende.

A menudo dividimos nuestros programas como model / view / controllers o model / view / view / model. Parece que el modelo debería permitir el acceso a la línea de comandos, pero no estoy tan seguro sobre el controlador. Naturalmente, la vista es lo que está siendo reemplazado.

Puede existir alguna diferencia basada en la cadena de herramientas. Code Complete es un libro de Microsoft Press, por lo que quizás esté utilizando las tecnologías de Microsoft para esta GUI. Si es así, creo que podría haber una casilla de verificación cuando cree la aplicación para exponer interfaces a través de COM o DCOM. Para algunas tecnologías de Microsoft, creo que las tablas de recursos y el paso de mensajes se combinan de manera bastante intensa con cualquier cosa que los Wizards le ayuden a crear prototipos rápidamente. Creo que está mejorando, pero si mantiene MFC o Forms, podría doler un poco.

En algunos casos, su programa basado en GUI puede ser una envoltura alrededor de una interfaz de administración o puede tener tan poca lógica propia, que no hay mucho que controlar mediante la interfaz de línea de comando. La creación de una aplicación de consola separada puede ser más rápida y aún así permitirle escribir, probar o usar lo que es importante.

El punto clave, supongo, es que la sugerencia no es una regla. Si lo sigue, debería obtener pruebas más sencillas de unidad y aceptación o una interfaz alternativa para cuando usted o un cliente prefieran escribir en lugar de hacer clic. Si se paga solo, hágalo. Buena suerte.

Depende de cuán útil sea el programa de línea de comandos. Algunas cosas, como trazar una ruta en un mapa o jugar un juego tridimensional, simplemente no se prestan a una interfaz de línea de comandos. Pero otras cosas, como las herramientas del sistema, son mucho mejores desde la línea de comandos que desde una GUI, por la sencilla razón de que pueden ser programadas.

El Dr. Richard Hipp dijo una vez que su sistema operativo GUI ideal era un escritorio en blanco con un icono para abrir ventanas de comandos y otro icono para abrir un navegador web. Me siento casi de la misma manera. Si fuera útil como un programa de línea de comandos, y no fuera demasiado difícil de construir de esa manera, lo haría. ¡La GUI podría ser un programa completamente separado, tal vez construido por otra persona!

En estos días (al menos para Java) parece que tarde o temprano todos los programas agregan un servicio web (SOAP o Ajax o ambos) tarde o temprano. Entonces, en general, sí, piense de esa manera, pero es más probable que un front end de servicio web que una línea de comando si desea una mejor metáfora mental ... y una más probable.

Hay una forma diferente de ver las cosas. En lugar de suponer que una línea de comando es el único camino a seguir, ¿por qué no asumir que el control del habla podría usarse en su lugar? Entonces se requiere un paradigma completamente diferente.

Antes de que Jobs se hiciera cargo de Apple, se estaban explorando mecanismos de control de voz muy sofisticados. Apple aplastó esto a favor de cosas como Siri.

Suspiro.

Lo popular y lo obvio no siempre son "los mejores".

Generalmente es una buena idea, sí.

Por metáfora, la gente puede pensar en esto como una forma de diseño RESTful. .... no es, per se, ya que una interfaz de usuario (G) típica podría involucrar transacciones complejas en varias etapas como la creación de cuentas.

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

Una vez programé una metáfora de interfaz de usuario de arrastrar y soltar en el navegador. Reglas de interacción muy complejas en el back-end para que el UX se sienta natural. Resolví esto haciendo del sitio una API y la GUI era una aplicación completa que generaba eventos tras la acción. Un módulo captó estos eventos y, en un temporizador, los incluyó en 'llamadas API' (para la eficiencia de la red).

El resultado fue un sistema central completamente RESTful. El segundo resultado fue que tenía una interfaz para terceros, que podía exponer usando perfiles de afiliación según el modelo de negocio.

Una ventaja es que se verá obligado a pensar en el flujo de la interfaz de usuario desde la perspectiva del usuario. (¿Qué estoy tratando de lograr? ¿Qué contexto necesito establecer? Dado ese contexto, ¿cómo puedo lograr el objetivo?)

Hay una gran diferencia entre "crear cuenta bancaria" y "escribir documento de Word ms". Incluso si no crea una CLI, puede agregar valor solo para considerar el "contexto de CLI" necesario. ¡Los modelos no solo viven en el modelo de objeto de negocio!