¿Comienzas a escribir la clase GUI primero o al revés?

Quiero escribir mi primer programa Java, por ejemplo, Phonebook, y me pregunto qué hacer primero. Mi pregunta es ¿debería escribir primero las clases GUI o las clases util? Soy desarrollador de bases de datos y quiero conocer las mejores prácticas en la creación de programas.

En teoría, hay al menos cinco enfoques posibles.

De arriba hacia abajo:

Comience con simulacros de UI o un prototipo en papel. Conviértalos en diálogos reales y avance desde los controladores de botones y otros controles hacia abajo a través de la lógica y la base de datos.

De abajo hacia arriba:

Comience con las estructuras de datos (probablemente el esquema de la base de datos). Luego agregue lógica (modelado de procesos del mundo real); Finalmente, su interfaz de usuario es solo una interfaz para activar la lógica y mostrar los resultados.

Lógica primero:

Comience con la lógica del programa, implementando el acceso a datos y una interfaz de usuario rudimentaria según sea necesario. Luego formalice y endurezca las estructuras de datos, y finalmente desarrolle la interfaz de usuario correctamente.

Encontrarse en el medio:

Comience con el esquema de la base de datos y la interfaz de usuario, y simultáneamente trabaje hacia el punto donde se encuentran. Con este enfoque, la lógica es lo último.

Expansión horizontal:

Comience por identificar la cantidad mínima absoluta de funcionalidad que haría algo interesante, e implemente toda la pila (estructuras de datos, lógica e interfaz de usuario) para esta parte. Podría ser solo un ciclo CRUD básico con un cuadro de diálogo de edición simple para una sola entidad. Luego comience a agregar más características, implementando la pila completa para cada característica (por lo tanto, 'horizontal').

Cada uno de estos tiene pros y contras.

De arriba hacia abajo le brinda algo visible al principio del proceso y le permite verificar su diseño funcional con las partes interesadas: los simulacros a menudo le dicen a los usuarios más sobre un diseño que los diagramas de flujo o las paredes de texto.

De abajo hacia arriba le da la oportunidad de diseñar un esquema de base de datos sólido como una roca antes de comprometerse con algo; dado que un esquema de base de datos es notoriamente difícil de modificar una vez publicado, desea que esta parte sea correcta: el impacto de modificar una interfaz de usuario es mucho menor y produce errores cada vez menos graves.

Logic-first significa que puede probar la lógica antes de pasar mucho tiempo en la base de datos y la presentación, lo cual es especialmente interesante si su lógica va a ser realmente compleja.

Meet-in-the-middle combina las ventajas de abajo hacia arriba y de arriba hacia abajo, pero tendrá que saltar de un lado a otro entre dos tareas, y corre el riesgo de terminar con una lógica que es más compleja de lo necesario porque sus dos extremos No te encuentres naturalmente.

La expansión horizontal va bien con un flujo de trabajo iterativo, y tiene la ventaja adicional de que, si prioriza bien, tendrá una aplicación en funcionamiento en cualquier momento dado, por lo que si no cumple un plazo, tendrá una versión que tiene menos funciones, pero sigue siendo completamente funcional, a diferencia de una versión que tiene una base de datos completa, pero sin interfaz de usuario.

Entonces, cuál elija depende de su estilo personal y de las circunstancias.

Si usted es un desarrollador de bases de datos, creo que debería comenzar con un modelo de datos y crear una buena capa de abstracción para que sea fácil definir su interfaz de usuario (ya sea GUI o no).

Personalmente, analizaría las preocupaciones de los usuarios e iría desde allí. Idealmente, el aspecto de la aplicación que requiere la mayor cantidad de trabajo debería comenzar primero.

En este escenario, me enfocaría en las simulaciones de UI como foco principal. El cliente ha expresado su preocupación por apoyar a un grupo diverso de usuarios finales, especialmente aquellos con impedimentos visuales, y distribuir el sistema a través de líneas culturales. Por lo tanto, aunque tener un sistema funcional y estable será crítico, la importancia de tener una interfaz que permita a los usuarios realizar fácilmente el trabajo tiene prioridad.

Este escenario me haría centrarme en la lógica del dominio. El cliente ha solicitado un sistema con complejas interacciones comerciales. Almacenará grandes cantidades de estructuras de datos complejas. Por lo tanto, el trabajo inicial para descubrir e implementar la lógica empresarial con el almacenamiento de la fuente de datos conducirá a un proyecto exitoso.

Si el sistema es un proyecto personal, concéntrese en lo que desea aprender del proyecto. Si estoy probando una nueva tecnología, trato de concentrarme en un pequeño pico con ella y aislar la tecnología en sí para poder comprender mejor cómo funciona. Sin embargo, un proyecto personal que atraviese todas las etapas tendrá el beneficio de prepararlo mejor para proyectos "reales". En ese caso, describiría algunos objetivos importantes y los usaría como un trampolín. Si esta aplicación de la guía telefónica es un proyecto personal suyo, sugeriría trabajar primero a través de la interfaz de usuario. Como desarrollador de bases de datos, supongo que usted sabe cómo conectar bases de datos a la lógica de dominio y aproximadamente cómo escribir la lógica de dominio, pero no ha explorado tanto las tecnologías de interfaz de usuario; Por lo tanto, trabajar en la interfaz de usuario debería beneficiar su aprendizaje más que comenzar desde la fuente de datos o la lógica de dominio.

Comience con la parte del proyecto que le parezca más interesante. Si comienza con la parte que no le gusta, puede abandonar antes de avanzar. El punto de partida es principalmente una cuestión de preferencia, por lo que también puede elegir en qué más desea trabajar.

Comience con el dominio o lo que llama 'clases de utilidad'. Pruébelo independientemente de su implementación de UI. De esa manera, usted comprende mejor cómo se comporta (o debería comportarse) su aplicación, cómo se desarrolla la lógica independientemente de qué marco de la interfaz de usuario, MVC o no, herramientas y estilos que planea utilizar al final.

Atentarse a una implementación de IU específica suele ser una mala idea. No estoy diciendo que no debas considerarlo por adelantado. Estoy diciendo que su aplicación no debería depender de ella. La interfaz de usuario tiende a cambiar MUCHO en el transcurso de un proyecto y si su dominio está vinculado a él, también cambiará mucho su dominio.

Casi todos tendrán un método diferente de desarrollo que se adapte a su estilo. Por ejemplo, una persona puede encontrar que es más fácil diseñar su GUI si ha definido la arquitectura subyacente y el almacenamiento de datos. Sin embargo, otra persona puede descubrir que jugar con la GUI y obtener un borrador inicial puede ayudarlos a organizar mejor su sistema de almacenamiento y codificar su programa de una manera más organizada. La tarea que tendrá ante usted será descubrir qué método (o quizás algún híbrido de los dos) funciona mejor para usted. Para mí, prefiero hacer una maqueta inicial de cómo creo que se verá la GUI, y luego comenzar a trabajar en los aspectos básicos de la aplicación. Una vez hecho esto, normalmente vuelvo y hago cambios en la GUI según sea necesario.

Este es un proyecto bastante sencillo donde yo diría que no es tan importante. En muchos proyectos, aunque no va a estar claro de inmediato exactamente cómo desea que se vea y funcione la GUI, y una vez que lo haga, alguien puede pedirle que lo cambie. Es bueno hacer maquetas rápidas de la GUI para que usted o quien esté a cargo pueda tomar una decisión concreta sobre cómo debería ser y luego esto le ayudará a ver algunos de los datos correlativos que necesitará para rastrear eso Es posible que no lo haya notado si hubiera comenzado con el diseño de datos.

Más importante aún, NO desea que su diseño de datos controle su interfaz de usuario. Relativamente hablando, creo que arreglar implementaciones de GUI deficientes es mucho más fácil que arreglar implementaciones de datos deficientes. Así que definitivamente voto por comenzar con la GUI.

Y yo soy más un tipo de base de datos, solo para tu información.