Estoy comenzando un proyecto de grupo escolar en Java, usando Swing. Es una interfaz gráfica de usuario sencilla en la aplicación de escritorio de la base de datos.
El profesor nos dio el código del proyecto del año pasado para que pudiéramos ver cómo hace las cosas. Mi impresión inicial es que el código es mucho más complicado de lo que debería ser, pero imagino que los programadores a menudo piensan esto cuando miran el código que no acaban de escribir.
Espero encontrar razones por las cuales su sistema es bueno o malo. (Le pregunté al profesor y él dijo que vería más tarde por qué es mejor, lo que no me satisface)
Básicamente, para evitar cualquier acoplamiento entre sus objetos persistentes, modelos (lógica de negocios) y vistas, todo se hace con cadenas. Los objetos persistentes que se almacenan en la base de datos son tablas hash de cadenas, y los modelos y vistas se "suscriben" entre sí, proporcionando claves de cadena para los "eventos" a los que se suscriben.
Cuando se activa un evento, la vista o modelo envía una cadena a todos sus suscriptores que deciden qué hacer para ese evento. Por ejemplo, en uno de los métodos de escucha de acción de vistas (creo que esto simplemente establece el bicycleMakeField en el objeto persistente):
else if(evt.getSource() == bicycleMakeField)
{
myRegistry.updateSubscribers("BicycleMake", bicycleMakeField.getText());
}Esa llamada finalmente llega a este método en el modelo del vehículo:
public void stateChangeRequest(String key, Object value) {
... bunch of else ifs ...
else
if (key.equals("BicycleMake") == true)
{
... do stuff ...El profesor dice que esta forma de hacer cosas es más extensible y mantenible que tener la vista simplemente llamando a un método en un objeto de lógica de negocios. Él dice que no hay acoplamiento entre las vistas y los modelos porque no saben de la existencia de los demás.
Creo que este es un tipo de acoplamiento peor, porque la vista y el modelo tienen que usar las mismas cadenas para funcionar. Si elimina una vista o modelo, o comete un error tipográfico en una cadena, no obtendrá errores de compilación. También hace que el código sea mucho más largo de lo que creo que debe ser.
Quiero discutir esto con él, pero él usa su experiencia en la industria para contrarrestar cualquier argumento que yo, el estudiante inexperto, pueda hacer. ¿Hay alguna ventaja en su enfoque que me estoy perdiendo?
Para aclarar, quiero comparar el enfoque anterior, con tener la vista obviamente acoplada al modelo. Por ejemplo, puede pasar el objeto del modelo del vehículo a la vista y luego, para cambiar la "marca" del vehículo, haga lo siguiente:
vehicle.make = bicycleMakeField.getText();Esto reduciría 15 líneas de código que actualmente SÓLO se usan para configurar la marca del vehículo en un solo lugar, en una sola línea de código legible. (Y dado que este tipo de operación se realiza cientos de veces en toda la aplicación, creo que sería una gran victoria para la legibilidad y la seguridad).
Actualizar
El líder de mi equipo y yo reestructuramos el marco de la forma en que queríamos hacerlo usando la escritura estática, informamos al profesor y terminamos ofreciéndole una demostración. Es lo suficientemente generoso como para dejarnos usar nuestro marco siempre y cuando no le pidamos ayuda, y si podemos mantener al resto de nuestro equipo al día, lo que nos parece justo.