Desarrollo de UI con componentes. Intro a Arena. Disclaimer.


¿Qué es Arena?

Hay muchas formas de diseñar interfaces de usuario, y obviamente no podemos verlas todas. Si intentáramos pasar por todas las variantes, la restricción de tiempo nos obligaría a verlas todas "por arriba" sin profundizar en ninguna, y creemos que eso no sería de mucha utilidad. Por eso, vamos a elegir una estrategia y vamos a dedicar una buena parte del tiempo a ella.

Para comprender la estrategia que proponemos, construimos un framework llamado Arena, que intenta proveer una implementación purista de estas ideas. Arena no es un framework comercial, no está pensado para construir aplicaciones reales, su objetivo es estrictamente educativo: esperamos que nos permita comprender algunos conceptos minimizando las complejidades que surjan por cuestiones tecnológicas. Y es un trabajo en progreso, así que minimizar no significa eliminar :-(

Principios de Arena

La estrategia que elegimos se basa en algunos principios que por ahora sólo vamos a enunciar y luego iremos profundizando:
  • Permite "diseñar", es decir, es una estrategia que intenta maximizar la oportunidad de aplicar todas las herramientas conceptuales que vimos hasta acá, como patrones de diseño, unit testing, etc. En particular, está pensada para poder diseñar con objetos.
  • Es adecuada para construcción de aplicaciones grandes. Otras técnicas parecen más sencillas cuando uno tiene que construir una aplicación unas pocas pantallas, pero no escalan para aplicaciones más grandes. (Esto está muy relacionado con la capacidad para diseñar)
  • Intenta minimizar el acoplamiento entre los componentes tecnológicos (vista, controlador) y los componentes no tecnológicos (modelos). Entre todas las visiones posibles de acoplamiento, elegimos priorizar el que tiene que ver con el impacto tecnológico. Para lograr esto, utilizamos el concepto de evento.
  • Minimizar la burocracia. Creemos que cualquier idea de arquitectura o diseño, para ser viable, debe minimizar la cantidad de código repetitivo mecánico necesario para poder ser utilizada. También creemos que intentar reducir el acoplamiento utilizando intermediarios que sólo transportan datos de un lado para otro es un engaño. Esta estrategia intenta minimizar la necesidad de intermediarios que no aportan valor semántico.
  • Compromiso entre automatismo y didáctica. Después de algunos años de experiencia enseñando con este método, decidimos reducir la cantidad de cosas que el framework resuelve en forma automática. Si bien en la construcción de aplicaciones reales esas herramientas automáticas serían deseables, encontramos que en algunas situaciones el exceso de automatismo puede confundir a alguien que está dando sus primeros pasos. De todas formas, el framework que utilizamos es en general más automático que muchos de los que se utilizan para construir aplicaciones industriales
  • Para los que hayan desarrollado interfaces de usuario en forma profesional, van a notar que la forma que proponemos presenta varias diferencias con algunos de los frameworks más utilizados. Cabe preguntarse entonces si no estamos aprendiendo algo demasiado teórico, y que luego no tenga una aplicabilidad en desarrollos concretos. Por el contrario, creemos que las técnicas que vamos a presentar tiene gran aplicabilidad práctica, como estrategia para intentar organizar una interfaz de usuario construida con tecnologías más precarias. En la última parte de esta unidad (en un par de semanas) vamos a estudiar cómo se trasladan estas técnicas que aprendimos a tecnologías más "reales". Adicionalmente, al estudiar los frameworks de presentación que se han ido popularizando en los últimos años, creemos que la visión que estamos presentando aquí tiene varios puntos de coincidencia con las tendencias a las que apuntan las tecnologías más modernas.

Por último, creemos que la forma más fácil de comenzar a desarrollar UIs es hacerlo pensando en clientes pesados, ya que son los que menos restricciones y complejidades tecnológicas nos van a imponer. Más adelante vamos a abandonar a los clientes pesados y vamos a ver cómo se trasladan los conceptos que vimos a otras tecnologías.

Referencias