¿Cómo diseñar un programa de línea de comando reutilizable para un futuro desarrollo de una GUI?

Question

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

escenario posible:

1. que desarrollar un programa CLI pitón de fantasía que raspa cada imágenes unicornio de la web
2. decido publicarlo en github
3. Un programador ventilador unicornio decide tomar las fuentes y construir una interfaz gráfica de usuario en ellos
4. él/ella se da por vencido porque mi código no es reutilizable

Cómo t o ¿evitar que el paso cuatro permita al programador de fanáticos del unicornio construir su GUI sin demasiada molestia?

Answer 1

Lo hace aplicando una buena porción de capas (quizás implementando el patrón MVP) y tratando su CLI como una IU por sí misma.

ACTUALIZACIÓN

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

Modelo-Vista-presentador (MVP) es una interfaz de usuario patrón de diseño por ingeniería genética para facilitan automatizado unidad de pruebas y mejorar la separación de las preocupaciones en lógica de presentación.

• El modelo es una interfaz de la definición de los datos a visualizar o actuaron en contrario en el interfaz de usuario.

• La vista es una interfaz que muestra datos (el modelo) y enruta los comandos del usuario (eventos) al presentador para actuar sobre esos datos.

• El presentador actúa según el modelo y la vista. Recupera los datos de los repositorios (el modelo), lo persiste y lo formatea para mostrar en la vista.

El ser principal punto de que es necesario trabajar en la separación de preocupación en su aplicación. Su CLI sería una implementación de una vista , mientras que el ventilador de unicornio implementaría otra vista para un cliente rico. El fanático del unicornio basaría su punto de vista en los mismos presentadores que su CLI. Si esos presentadores no son suficientes para su cliente rico, fácilmente podría agregar más, ya que 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 un tema completo en sí mismo. Le puede interesar leer, por ejemplo, aproximadamente Domain-Driven Design, aunque no sé qué tan bien se aplica a su aplicación actual. Pero es interesante leer de todos modos. Como puede ver, el artículo de wikipedia sobre MVP también habla sobre 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 capacidad de prueba en su código base, a menudo es una buena idea usar algún tipo de marco Dependency Injection.

Espero que esto le dé una idea general de las técnicas que necesita emplear, aunque entiendo que puede ser un poco abrumador. No dude en preguntar si tiene más dudas.

/Klaus

Answer 2

Parece una pregunta sobre cómo escribir código utilizable.

Al considerar reusablility de código, en general, uno debe tratar de:

• funcionalidad separada en módulos
• tienen una interfaz bien definida-

funcionalidad separación en módulos

Uno debe intentar separar el código en partes que tienen un simple respons ibilidad. Por ejemplo, un programa que sale a Internet para raspar imágenes de unicornios puede separarse en secciones que: a) raspa la red en busca de imágenes, b) determina si una imagen es unicornio yc) almacena dichas imágenes de unicornio en algún lugar especificado ubicación.

tener una interfaz bien definida

Tener una interfaz bien diseñada, una API (interfaz de programación de aplicaciones), va a ser crucial para proveer una manera de reutilizar o extender una aplicación.

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

Answer 3

que usted toma de entrada, la ejecución de una acción, y la presentación de salida. Puede ser una buena idea utilizar un mecanismo de devolución de llamada (como 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 llame directamente a file.write(); make myModel.saveMyData() que llama a file.write, para que otra persona pueda crear somebodysModel.saveMyData() que escribe en una base de datos.

Answer 4

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:

• a diseñar un API unicornio raspado. Este es el paso difícil; un buen diseño de la API es terriblemente difícil, y no hay muchos ejemplos para estudiar. Una API que creo que vale la pena estudiar es la del libro de Dave Hanson C Interfaces and Implementations.

• Luego, diseña la interfaz de línea de comandos. Si la funcionalidad que está exponiendo no es complicada, esto 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ñando una interfaz para scripts en lugar de la línea de comandos.

• Finalmente, escribe el código de procesamiento de la línea de comandos y lo pega todo.

Su sucesor hipotética construye su interfaz gráfica de usuario en una de dos maneras: utilizando los lenguajes de script incrustado, o directamente en la parte superior de la API.

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