Mi cursada - UNQ‎ > ‎Clases‎ > ‎Bitácoras‎ > ‎Bitácoras 2011 S1‎ > ‎Bitacoras 2012 1c‎ > ‎

Clase 2 - 21/3/2012

publicado a la‎(s)‎ 21 mar. 2012 15:46 por gisela decuzzi   [ actualizado el 21 mar. 2012 15:46 ]
Arrancamos haciendo un pequeño repaso de lo que ya vimos, consultando dudas teóricas y prácticas.
Luego repasamos dos cosas de Objetos 2:
  • Excepciones
  • El patrón Observer
  • Comunicación bidireccional en objetos, por ejemplo, clase subclase, o bien interfaces.
Y luego nos metemos en la Unidad 2.

Model-View-Controller

La importancia de un modelo de dominio

Dijimos que era muy importante tener un modelo de dominio separado de la tecnologia o lo que querramos hacer.
Discutimos el por que de esta separacion y pensamos que pasaria si no la tuvieramos y mezclaramos por ejemplo logica de dominio con la presentacion, esto nos llevaria a alejarnos de nuestro problema y en vez de concentrarnos en el problema (haciendo las abstracciones que se encuentran en el) pensar en problemas inherentes de la tecnologia produciendo sistemas confusos y poco escalables, tendiendo a repetir codigo y a distribuir mal las responsabilidades. Ademas recalcamos el hecho de que hace mas dificil escribir tests unitarios.


Objetos necesarios para modelar una ventana

Definimos que vamos a construir interfaces de usuario orientadas a objetos. Para eso, introducimos nuestro ejemplo del conversor de monedas y presentamos una pantalla tentativa. 
Nos preguntamos qué objetos podrían conformar esa pantalla:
  • Los obvios son los controles visuales: botones, campos de texto, ventanas.
  • Menos obvios son los layouts, que indican cómo se organizan espacialmente los objetos.
  • Y también tenemos que pensar en el objeto que tiene el comportamiento, por debajo de la ventana, al que vamos a llamar modelo de dominio.

Relación entre la interfaz de usuario y el dominio

Definimos como un objetivo la separación entre los controles visuales y el modelo de dominio
Es importante entender qué formas de relación podemos admitir entre ambos y qué formas no. Existe una relación entre ambos, no podemos pretender que no tengan "ninguna relación entre sí", eso seria engañarnos.

Según nuestra definición, el dominio no puede tener referencias explícitas a la interfaz de usuario, pero sí puede:
  • Contestar preguntas.
  • Tirar excepciones.
  • Lanzar eventos.
La interfaz de usuario sí puede tener referencias al dominio y mandarle mensajes, pero no debe tomar decisiones propias del dominio
Para entender sobre las decisiones, pensamos en las validaciones necesarias al hacer una transferencia. ¿A quién le corresponde cada validación?
  • La cuenta no puede quedar con saldo negativo.
  • El texto ingresado debe ser un número.
  • El monto de la transferencia no puede ser negativo.
Comparamos esta definición con el concepto de capas.

Como regla general, vamos a pensar que (casi siempre) cada ventana va a tener un único objeto que es responsable del comportamiento asociado a esa ventana. A ese objeto lo llamamos el modelo de la ventana. Múltiples ventanas pueden estar relacionados con un único modelo.

Eventos

El otro concepto fundamental de la forma de comunicación que vamos a utilizar es el Evento. Un evento produce una forma de interacción muy desacoplada, ya que el que informa sobre el evento conoce sólo sobre sí mismo, no sabe a quién le está informando.

Los eventos permiten enterarnos de las acciones del usuario, por ejemplo podemos hacer que la UI nos avise cuando el usuario presiona un botón, y pedirle que invoque un mensaje específico.

Los eventos y las configuraciones asociadas son el primer ejemplo que vemos del tercer rol fundamental en el diseño de una interfaz de usuario: el controller. Al decir esto podemos terminar nuestro dibujo de MVC. De a poco vamos a ver controllers más complejos, por ahora van a ser muy simples.

Binding

Ahora, ¿cómo hacemos para obtener la información que el usuario ingresó en la ventana? 
Nuestras reglas dicen que no podemos pedírsela a la ventana, pero lo que sí podemos es escuchar algún evento que nos avise cuando cambia el valor y nos reenvíe el valor nuevo. Como este tipo de comportamiento es muy común, existe una forma especial de evento que llamamos binding. El binding puede ser unidireccional o bidireccional.

Y con eso tenemos todo para construir interfaces de usuario sencillas.

Tarea y más información

Comments