Entonces, si en otra pantalla queremos poner un conversor, o manejar problemas de conversión de texto a números se nos va a complicar un poco así como lo tenemos armado. Si no queremos repetir las cosas (copiando y pegando), tenemos que aplicar las herramientas de diseño (llevando la conversión a un objeto que esté separado de la vista).
- Si bien la idea de MVC está bastante difundida, a la hora de programar interfaces de usuario es muy común encontrar estos ejemplos como material didáctico y como forma de trabajo en las empresas. Al mercado todavía le cuesta mucho separar modelo de vista y trabajar el binding en forma bidireccional. Y ya hemos hablado que si mezclamos modelo con vista,
- mezclamos lo tecnológico y lo que no lo es
- nos complicamos para hacer el testeo unitario, porque para poder probar la aplicación tenemos que probar todo (desde la perspectiva de usuario, mientras que la prueba unitaria puede automatizarse con facilidad sin depender de las cuestiones tecnológicas)
- también perdemos la oportunidad de subclasificar temas que no tienen que ver entre sí: el modelo y la vista necesitan su propia jerarquía
- en la solución de SWT hay más líneas, porque hay menos objetos. En los ejemplos de Arena aparecen muchos más objetos, eso paradójicamente permite bajar la cantidad de líneas de código.
- en el ejemplo del conversor SWT la vista tiene como atributos (variables private) a los controles de SWT: