user interface - usuario - ¿Cómo diseñar un programa de línea de comandos reutilizable para un futuro desarrollo de una GUI?

que es interfaz grafica de usuario gui (4)

Estarás tomando entrada, ejecutando una acción y presentando salida. Podría ser una buena idea usar un mecanismo de devolución de llamada (como los controladores de eventos, pasar un método como parámetro o pasar este / self a la clase llamada) para desacoplar los métodos de entrada y salida de la ejecución de la acción.

Aparte de esto, programe una interfaz, no una implementación, la esencia de MVC / MVP, como mencionó klausbyskov. por ejemplo, no llamar directamente a file.write (); haga que myModel.saveMyData () llame a file.write, para que otra persona pueda crear un somebodysModel.saveMyData () que escriba en una base de datos.

¿Cuáles son algunas de las mejores prácticas que se deben tener en cuenta al desarrollar un programa de script que podría integrarse con una GUI, probablemente por otra persona, en el futuro?

Posible escenario:

Desarrollo un programa CLI de python de lujo que raspa todas las imágenes de unicornio de la web
Decido publicarlo en github
Un programador de fan unicornio decide tomar las fuentes y construir una GUI en ellas
Se rinde porque mi código no es reutilizable.

¿Cómo evitar que el paso cuatro permita que el programador de fans de Unicorn construya su GUI sin demasiados problemas?

Esto suena como una pregunta sobre cómo escribir código utilizable.

Cuando se considera la posibilidad de reusabilidad del código, en general, se debe tratar de:

funcionalidad separada en módulos
tener una interfaz bien definida

Separando funcionalidad en módulos.

Uno debe tratar de separar el código en partes que tienen una responsabilidad simple. Por ejemplo, un programa que sale a internet para raspar imágenes de unicornios puede separarse en secciones que a) raspa la web en busca de imágenes, b) determina si una imagen es un unicornio yc) almacena dichas imágenes de unicornio en algunas ubicación.

Tener una interfaz bien definida.

Tener una interfaz bien diseñada, una API (interfaz de programación de aplicaciones), será crucial para proporcionar una forma de reutilizar o extender una aplicación.

Proporcionar puntos de entrada en cada funcionalidad permitirá a otros programadores escribir una nueva interfaz de usuario para la funcionalidad proporcionada.

La solución a este tipo de problema es muy simple, pero en la práctica, muchos programadores junior tienen problemas con este patrón. Aquí está la solución:

Usted diseña una API que raspa unicornio. Este es el paso difícil; un buen diseño de API es increíblemente difícil, y no hay muchos ejemplos para estudiar. Una API que creo que vale la pena estudiar es la del libro C Interfaces e Implementaciones de Dave Hanson.
Entonces diseñas tu interfaz de línea de comandos. Si la funcionalidad que está exponiendo no es complicada, no es demasiado difícil. Pero si es complicado, es posible que desee pensar seriamente sobre la administración de su API utilizando un lenguaje de scripts integrado como Lua o Tcl y diseñar una interfaz para scripts en lugar de la línea de comandos.
Finalmente, escribe el código de procesamiento de la línea de comando y pega todo junto.

Su hipotético sucesor construye su GUI de una o dos maneras: usando los lenguajes de scripting incrustados, o directamente sobre su API.

Como se señaló en otras respuestas, el modelo / vista / controlador puede ser un buen patrón para usar en el diseño de su API.

Lo hace aplicando una buena parte de capas (tal vez implementando el patrón MVP) y tratando su CLI como una UI por derecho propio.

ACTUALIZAR

Este texto del artículo de wikipedia sobre el patrón Model-View-Presenter explica bastante bien.

Model-view-presenter (MVP) es un patrón de diseño de interfaz de usuario diseñado para facilitar las pruebas unitarias automatizadas y mejorar la separación de inquietudes en la lógica de presentación.
El modelo es una interfaz que define los datos que se mostrarán o que se actuarán en la interfaz de usuario.
La vista es una interfaz que muestra datos (el modelo) y enruta los comandos (eventos) del usuario al presentador para actuar sobre esos datos.
El presentador actúa sobre el modelo y la vista. Recupera los datos de los repositorios (el modelo), los conserva y los formatea para mostrarlos en la vista.

El punto principal es que necesita trabajar en la separación de preocupaciones en su aplicación. Su CLI sería una implementación de una vista , mientras que el fanático del unicornio implementaría otra vista para un cliente rico. El fanático del unicornio basaría su opinión en los mismos presentadores que su CLI. Si esos presentadores no son suficientes para su cliente rico, podría agregar más fácilmente, porque cada presentador se basa en los datos del modelo. El modelo, a su vez, es donde se basa toda la lógica central de su aplicación. Diseñar un buen modelo es todo un tema en sí mismo. Es posible que le interese leer, por ejemplo, sobre Diseño impulsado por dominios , aunque no sé qué tan bien se aplica a su aplicación actual. Pero es interesante la lectura de todos modos. Como puede ver, el artículo de wikipedia sobre MVP también habla acerca de la capacidad de prueba, que también es crucial si desea proporcionar un marco sólido para que otros puedan construir. Para alcanzar un alto nivel de comprobabilidad en su base de código, a menudo es una buena idea usar algún tipo de marco de inyección de dependencia .

Espero que esto te dé una idea general de las técnicas que debes emplear, aunque entiendo que puede ser un poco abrumador. No dudes en preguntar si tienes más dudas.

/ Klaus