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

Clase 3 - 28/03/2012

publicado a la‎(s)‎ 28 mar. 2012 17:11 por gisela decuzzi   [ actualizado el 28 mar. 2012 17:11 ]
Hicimos un repaso de algunos temas y hablamos de testing y manejo de errores, dijimos cosas como:
  • Hacer los test con un fin y acotado, cada test prueba una sola cosa y no cinco
  • Los tests son codigo y es algo que no tenemos que olvidar, a ese codigo tambien hay que cuidarlo, y aplica todo lo que vimos en programacion
  • Si el sistema tiene que fallar que falle lo antes posible
  • No hay que tener miedo a que las cosas "se rompan"
  • Peor que falle avisandonos es que falle y nunca diga nada :(
Para ver el por que de estas cosas y mucho mucho mas es realmente muy sano que sigan leyendo sobre estos temas, particularmente les dejamos dos apuntes para que lean, sobre:

Despues de eso nos metimos de lleno en el tema de la clase: Adapters y Validaciones
Antes hicimos una pausa y hablamos de inner clases en Java, y despues si finalmente empezamos a hablar de...

Validaciones

Quisimos agregarle una validacion a nuestro querido Conversor, queremos que: No convierta numeros negativos
Dijimos que eso es una nueva regla de negocio.
Entonces empezamos...
Donde ponemos la validacion y por que?
  • En la vista (ConversorWindow)?
    • Surgio la idea de que: al modelo solo le lleguen datos validos, entonces la vista parece un gran lugar para poner esa regla
  • En el controlador (Un action propio)?
  • En el modelo?
    • Surgio la idea de que: la imposibilidad de convertir es una regla propia de mi dominio, entonces en el modelo es un gran lugar
De las dos opciones validas, por cual vamos? Para responder esto hablamos de que es una validacion,y dijimos que hay dos cosas destancables de una validacion:
  • Una regla: algo que tenemos que cumplir
  • La ejecucion de esa regla
Dijimos que no confundamos esas cosas, en nuestro caso la imposibilidad de convertir numeros negativos es independiente de la vista, y es algo bien intrinsico a nuestro problema. Nosotros NUNCA vamos a convertir numeros negativos, y eso es logica de mi modelo entonces nos convencimos de ponerlo ahi, por lo que elegimos el modelo como su lugar. Hablamos de reutilizacion y nos imaginamos que queriamos un test, definimos que esa regla era digna de un test y nos alegramos de haber puesto esa regla porque ahora la podemos testear de ahi.


Despues nos pusimos el sombrero de usuario del conversor y hablamos modestamente de su usabilidad y lo que nos gustaria, dijimos cosas como:
  • Que si ingresamos un valor invalido nos informe mientras tipeamos (sin necesidad de apretar el boton)
  • Que ni siquiera deje setear el valor si es negativo, aca pasamos la validacion al setter
  • Que no solo nos informe que hubo error sino que deshabilite el boton, lo implementamos con arena usando el metodo disableOnError() de la clase Button.
  • Que ni siquiera me deje escribir cosas invalidas
Aca vimos que hay muchas cosas que dependen del framework que estamos usando, tomamos el ejemplo de habilitar/deshabilitar el boton y lo facil que era, y esto pasaba porque:
  • elegimos validar en el domnio
  • elegimos manejar los errores como le gustan al arena (tirando la excepcion que le gusta)
Despues para poder cumplir con la ultima motita les presentamos un nuevo feature recien salido del horno de Arena que son los TextFilter, vimos su codigo, un solo metodo:
    public boolean accept(TextInputEvent event);
Y lo usamos en nuestro conversor y de paso con una inner class:
millas.withFilter(new TextFilter(){
    public boolean accept(TextInputEvent event){
        return StringUtils.isNumeric(event.getPotenctialTextResult());
    }
});

Despues un poco nos fuimos por las ramas y dijimos, esta regla es simple, la hicimos en una linea, y se nos complico la regla: que admita comas, pensamos en mas cosas que nos pueden pasar y nuestra regla era terrible y no era una linea y tenia sentido usarla en otros lados. En ese momento vimos lo feo que era que solo existiese en esa clase y que en ese momento tener una inner class no estaba bueno, aunque sea lo sacamos a una clase nueva.

Despues nos fuimos todavia mas por las ramas y hablamos de la importancia de contribuir en proyectos de software y no estar solo en la posicion de usuarios comodos y quejarnos de que no se ajusta a nuestras necesidades, y parchear para que funcione y seguir. Tambien hablamos del tride-off y el esfuerzo que eso implica.

Volvimos y revisamos nuestro ejemplo, al final refactorizamos y dijimos:
  • Definitivamente quiero que mi regla de negocio este efectivamente en mi modelo, por lo que volvimos el metodo a la clase Conversor, en un metodo nuevo.
  • Tambien quiero que se ejecute mientras tipea el usuario se valide, entonces queremos el TextFilter y lo que vamos a hacer es que en su implementacion mande el mensaje nuevo de validacion al modelo.
Quisimos categorizar el TextFilter y dijimos dentro del MVC que es? Llegamos a la conclusion que es un controller: porque se comunica con el dominio (le manda un mensaje al modelo) actua sobre la vista (en la pantalla no aparece ese caracter) y justamente esa es la accion del controller.

Conclusion: separemos las reglas de negocio de su ejecucion.


Adapters no llegamos a verlo, con lo que nos quedo para la proxima clase (que ademas es la entrega 1 del tp).

Comments