Contents |
Es todo lo que permite a un usuario interactuar con el sistema. Una interfaz se implementa por lo general con una pantalla, pero no es el único dispositivo posible.
Es todo lo que permite a un usuario interactuar con el sistema: esto incluye componentes lógicos (software) y físicos (hardware). Interfaz de Usuario también se puede abreviar por sus siglas en inglés: UI (User Interface) y en general se suele hablar de la interfaz gráfica como la parte de presentación de una aplicación.
Naturalmente, el objetivo de la materia es aprender a programar y diseñar interfaces de usuario. Sin embargo, la construcción de interfaces de usuario presenta muchos aspectos distintos y por eso conviene entender en cuáles vamos a hacer foco.
En primer lugar, cuando decimos “diseño”, nos referimos tanto al diseño de software como al diseño gráfico:
Si bien una materia del ámbito de las TIC está más relacionada con el primer punto, no es menor la preponderancia que adquiere últimamente el diseño gráfico, ya sea porque es una responsabilidad directamente delegada a quien construye la UI o bien constituye una actividad interdisciplinaria con un especialista.
Nuestro objetivo también es concentrarnos en producir aplicaciones que se destaquen por sus cualidades de mantenibilidad, flexibilidad, claridad, robustez, entre otras. En el ámbito específico de las interfaces de usuario, un criterio importante será separar la responsabilidad correspondiente a la interfaz de usuario de la lógica de dominio. Repasemos entonces de qué hablamos cuando hablamos de “dominio” o “negocio”.
Cuando le pedimos al sistema que haga algo, hay reglas que rigen el negocio que manejamos.
Si el cliente sólo puede pagar con cheque a 30/60/90 días, hay una regla de negocio que lo dice. Si un alumno no puede anotarse en un final porque debe una correlativa, hay otra regla de negocio que lo dice. Si un empleado cobra un 10% del sueldo básico por presentismo, hay otra regla de negocio que lo dice.
Lo que forma parte del dominio de mi aplicación es encontrar
Home
Artículos
public void pagar(TipoPago tipoPago, BigDecimal monto)
donde se resuelva esa responsabilidad
public void inscribirseAFinal(Materia materia)
donde se resuelva esa responsabilidad
O sea,
Pongamos por caso esta interfaz conocida de Twitter:
El caso de uso “Twittear” parecería no tener una UI tan compleja, aun así, la página chequea todo el tiempo la cantidad de caracteres que escribo y en una forma gráfica está mostrando el estado de mi tweet, e incluso debe deshabilitar el botón de “Enviar tweet” si excedo el máximo permitido.
Por otra parte, una vez validado, el mensaje que recibe el negocio es algo como:
twitter.agregarTweet(nuevoTweet)
que debería incorporar ese nuevo tweet a la colección (la persistencia requiere de un objeto arquitectural que normalmente está fuera del alcance del objeto de dominio).
En general, la lógica de la presentación suele ser siempre mucho más compleja que la del negocio, aun cuando el negocio pueda (y debería) ayudar a la UI a agregar funcionalidades que mejoren la experiencia de usuario.
Corolario: no es verdad que si el dominio está bien construido la presentación se hace sola, y la implementación de la presentación debería estar a cargo de la gente con más experiencia, algo que lamentablemente no siempre sucede
Por supuesto que ande, pero además vamos a priorizar ciertas cualidades de diseño: mantenibilidad, flexibilidad, claridad, robustez, entre otras. En particular tratar de no mezclar ideas de presentación con negocio. O sea, separar la lógica para definir la interacción con el usuario y la lógica propia del dominio. ¿Por qué?
Volviendo al ejemplo de Twitter,
Mantener separados estos concerns facilita el cambio de tecnologías de la UI, el testeo unitario de ese dominio, entre otras cosas.
¿Dónde interviene el acoplamiento al programar la UI? El componente de UI va a tener que conocer al componente que maneja la lógica de dominio, de otra manera la aplicación no va a funcionar. Pero tampoco es bueno que la interfaz defina lógica que es propia del cliente, o de la factura, o de un empleado o de un alumno (para más información ver Interacción entre la UI y el dominio del sistema). Es cierto que agregar un atributo que el usuario deba visualizar o modificar a través de la interfaz fuerza inevitablemente a un cambio en la UI, pero cambios en la lógica de negocio no deberían necesariamente afectar la UI. Así que otro de nuestros objetivos será minimizar el acoplamiento, no por ser puristas, sino porque nos traerá como beneficio no vernos impactados por cualquier tipo de cambio.