Primera Clase de Cañón

¿De qué hablamos? Anotamos en el pizarrón

  • Annotations: meta-datos de un programa, que el compilador puede chequear (ofrece un contrato más fuerte que el simple comentario: @Deprecated vs. "NO USAR. Este método ya fue")
  • Unit testing, y relacionado con eso
    • ventajas respecto a un main (Verde / rojo vs sysout sysout sysout de mensajes por consola)
    • TDD: testeo unitario: puedo programar un test. Puedo escribir primero el test y después el requerimiento (o hacerlo de la manera tradicional)
    • Por qué mejor varios tests y no un único main (o un único test)
    • para programar el test tengo que entender qué necesito y qué espero (el input + la interfaz y el output)
    • Cómo generar casos de prueba: fixtures, efecto colateral

 * el testeo es unitario pero necesito entender algo del negocio para programar el test

Casos de prueba posibles:
Caso Resultado esperado
Cantidad de maldad de “Que Pablito le dio la mano con moco a Matute (30 puntos de gravedad) y se arrepintió” 15 (porque se arrepintió)
Cantidad de bondad de “Que Pablito le dio la mano con moco a Matute (30 puntos de gravedad) y se arrepintió” 0
Cantidad de maldad de “Que Fernandito ayudó a cruzar la calle a la anciana Eduviges (100 puntos de importancia)” 0
Medir el nivel de bondad de Fernandito el año actual 110 (ver punto siguiente)
Cantidad de bondad de “Que Fernandito ayudó a cruzar la calle a la anciana Eduviges (100 puntos de importancia)” 110 (la anciana fue mala este año, le aumenta un 10% de 100 = 10 + 100 = 110)
Saber si Eduviges fue mala el año actual
Saber si Fernando fue malo el año actual No
Saber si Matute fue bueno el año actual
Saber si Pablito fue bueno el año actual, sabiendo que su nivel de bondad en el 2010 fue de -35 Sí, porque está tratando de mejorar, -35 en el 2010 vs. -15 en el 2011
  • Intro básico a errores: cuando hay un error hay que mirar el stack trace. La pila de ejecución me muestra el encadenamiento de mensajes entre objetos (la peli en el momento en que se rompió todo)
  • Tiempo de compilación y tiempo de ejecución
  • Por qué es importante una IDE para diseñar: Ctrl + 1
  • Principales shortcuts de la IDE: Format, Organize imports, Find class, Create class, Create interface, Generate accesors
  • Repaso de Collection, que nos permite
    • representar relaciones 1 a n, conjunto de objetos.
    • Colecciones tipadas. Uso de generics: las colecciones admiten tipos parametrizables: puedo decir esta colección es de rabanitos o de clientes.
  • Uso del debugger para poder inspeccionar los objetos en runtime: sirve a veces cuando tenemos que entender cómo es la estructura interna de algunos objetos o para encontrar un error puntual, pero abusar del debugger induce a trabajar a "prueba y error". El test permite automatizar las pruebas y detectar errores, el debugger no.

E insistir en algunos temas de diseño:

  • Method lookup: qué pasa cuando envío un mensaje a un objeto. La búsqueda de un método comienza a partir del objeto receptor. Si no existe un método en esa clase, continua buscando en la superclase y así sucesivamente.
  • Cohesión: qué objetivo tiene cada método y cada objeto, los tests detectan baja cohesión. La IDE ayuda a poner cada cosa en su lugar.
  • Acoplamiento: cuánto se conocen los objetos, los tests me ayudan a medir alto acoplamiento
  • Polimorfismo: quién se beneficia, no es el objeto polimórfico sino el que manda mensajes a objetos polimórficos
  • Herencia y qué pasa con los objetos en Runtime

Para el jueves siguiente estaría bueno hablar de:

  • SVN
  • Maven
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License