Desafio de diseño: objetos inteligentes (resolución)

(continuación de Desafio de diseño: objetos inteligentes)

Hay varias formas de atacar este problema de la “testeabilidad”.

La primera opción que muchas veces viene a la mente, es hacer públicos los métodos privados y testearlos unitariamente. Si desde el punto de vista práctico esta opción puede parecer viable, cuando la miramos desde el punto de vista conceptual resulta incorrecta, pues dichos métodos son conceptualmente privados y no seria correcto cambiar su visibilidad para solo probar la clase. Si estuvieramos trabajando con C# Visual Studio nos ofrece una alternativa basada en reflexion para acceder a miembros privados de la clase, pero conceptualmente esto sigue siendo incorrecto.

Si pensamos el problema un poco más, nos daremos cuenta que puede que la clase tenga algunos problemillas de responsabilidades. Para ser más explícitos, tiene demasiadas responsabilidades: decidir si moverse y en caso positivo hacerlo, decidir si disparar y en caso positivo hacerlo, etc, etc. Bueno, si asumimos este diagnostico entonces hemos dado el primero paso: identificar el problema.

Repensemos la cuestión una vez más. Una clase que toma muchas decisiones (si X, si Y, si X, etc) y hace muchas cosas (X, Y, Z, etc). Cada una de esas cuetiones las hemos encapsulado en un método privado de cara a tener un código más legible. ¿y si fueramos un paso más allá? ¿Que tal si convertimos cada uno de ese métodos privados en una clase? De esta forma tenenemos una clase con la lógica de movimiento, otra clase con la lógica de disparo y asi sucesivamente. Así nuestro objeto inteligente tiene mucho menos código y su responsabilidad está limitada a coordinar “las estrategias” de movimiento, disparo, etc, etc. Al mismo tiempo cada estrategia puede ser testeada independientemente.

Bueno, este ha sido el primer desafio, próximamente vendrán algunos más.

Desafio de diseño: objetos inteligentes

Estaba preparando un ejemplo para algo3 cuando me surgió esta cuestión.

Como ya he mencionado en algo3 solemos programar juegos. En general los juegos tienen ciertos personajes que van actuando autonomamente con el paso del tiempo, a estos objetos es a lo que llamo objetos inteligentes. Por poner un ejemplo, tomemos el clásico juego de naves Gálaga, donde las naves enemigas actuan autonomamente con cierta lógica interna.

Cuando llevamos esto a código siguiendo el paradigma orientado a objetos, estas naves solo debieran tener un método público del tipo actuar, el cual seria invocado desde el GameLoop. Dentro de dicho método, cada nave decidiria si moverse en una determinada dirección, o si disparar, o si hacer ambas cosas al mismo tiempo, etc. Con el fin de que dicho método no quede demasiado largo, generalmente extraeremos varios métodos privados: uno con la lógica de movimiento, otro con la lógica de disparo, etc, etc.

Ahora la cuestión es: ¿como escribir pruebas unitarias para esta clase cuando tiene un solo método con tanta lógica? Es claro que es posible escribir pruebas unitarias para estos casos, pero si intentan hacerlo verán que no les quedará código muy feliz, pues el código de arrange de cada prueba podria resultar bastante largo y engorroso de escribir debido a todos los caminos posibles dentro del método bajo prueba. Una opción para evitar esta situación podria ser hacer públicos los métodos privados y asi escribir pruebas por separado para la lógica de movimiento, para la lógica de disparo, etc, etc, pero esto implicaría poner públicos ciertos métodos que naturalmente seria privados, con el solo fin de hacer pruebas. Definitivamente esta opción me hace ruido.

¿Entonces? Tengo una propuesta, pero será parte de otro post, mientras tanto, los invito a lo que piensen.

Continuará….

Adopción de C# en aumento

Desde hace ya un par de años el Algo3, les permitimos elegir el lenguaje de programación a utilizar en el TP grupal. En un comienzo la elección estaba restringida a Object Pascal (Delphi) o Java y en la actualidad es Java o C#. Históricamente la mayoría de los alumnos se han inclinado por Java en una proporción de 4 a 1 (y estoy siendo generoso con C#).

Pero resulta que este cuatrimestre, particularmente en el curso JT (que es en el que estoy yo) ha habido una adopción masiva de C#, de 9 grupos, al menos 6 han elegido C#. La única explicación que se me ocurre para esta situación particular del curso JT es la influcia de los docentes.

En este curso somos 4 docentes: Pablo, Gabi, Diego y yo. Este cuatrimestre, desde que comenzamos a estudiar lenguajes de tipado estático, la mayoría de las clases las dieron Gabi y Diego, ambos afines a C#, por lo cual casi todos los ejemplos en nuestra clase fueron mostrados en C#. Esto, sumado al buen manejo de Gabi y Diego del Visual Studio, resulta una influencia considerable para los alumnos.

Pero la verdad recien la sabremos al final del cuatrimestre cuando hagamos la clase de cierre.

Tráfico de examenes en la clase de consulta

Ayer hicimos la clase de repaso previa al parcial en Algo3, una práctica que implementamos con muy buen resultado el cuatrimestre anterior.
Esta clase tiene una dinámica especial que difiere de la tradicional clase consulta: pedimos a los alumnos que se separen en grupos, cada grupo tiene 15 minutos para elaborar un set de preguntas sobre una unidad en particular, luego intercambiamos las preguntas entre los grupos para que las contesten y finalmente, hacemos una revisión entre todos de las preguntas y las respuestas.

El dato de color es que durante la clase de consulta de ayer, estábamos con PabloS y veíamos que algunos alumnos recolectaban plata, entraban y salían del aula llevando fotocopias. Esto llamó mi atención y disimuladamente me acerqué a ver de que se trataba. Resulta que el objeto de «tráfico» era un parcial resuelto tomado en un cuatrimestre anterior. En un primer momento me resultó muy chocante, pero luego de unos minutos, recordé que yo también solía hacer eso 🙂 ¿y quien no?.

Comienzo de clases en Fiuba

Esta semana comenzamos en segundo cuatrimestre. Como siempre voy a estar dictando Algo3 y también como suele ocurrir los segundos cuatrimestres, voy a dictar Teoría de algoritmos (TDA). Habiendo transcurrido la primer semana de clase, tengo algunas curiosidades para compartir.

Curiosidad 1: es la primera vez que tenemos más alumnos en TDA que en la práctica 1 de Algo 3.  En TDA tenemos anotadas unas 45 personas, que en caso que todas cursen efectivamente la materia, va a hacer durísima la corrección de trabajos prácticos. Por otro lado en la algo3 tenemos alrededor de 20 alumnos y somos 4 docentes, lo cual es excelente, pues vamos a poder hacer un trabajo mucho más personalizado.

Curiosidad 2: en TDA tenemos dos alumnos de intercambio provenientes de Francia y según comentó DiegoF, en la práctica 2 de algo3 hay una alumna en la misma condición.

Curiosidad 3: bueno, en realidad no es una curiosidad sino una mejora, apenas comenzamos el cuatrimestre y ya tenemos definidos los 3 trabajos prácticos. Sinceramente no recuerdo que hayamos tenido una situación así previamente y es justamente esa la curiosidad.

Respecto de este último punto, como de costumbre en Algo3, procuramos que los trabajos prácticos sean juegos y este cuatrimestre no es la excepción. Los trabajos 1 y 2 son juegos, mientras que el trabajo 0, consiste en la implementación de ciertas leyes de mecánica clásica (velocidad, fuerza, etc, etc) que son necesarias para los trabajos 1 y 2.  Otro punto positivo respecto a esto, es que en esta ocasión resolvimos el TP antes de entregarselo a los alumnos, para validar el alcance y la dificultad del mismo (resolvimos dijo el mosquito, en realidad yo solo sugerí que deberiamos hacerlo y fue Eugenio quien finalmente lo hizo).

Fin.

Planificación 2011-2 algo3@fiuba

Ayer durante la última fecha de examen integrador, realizamos una reunión de cátedra para planificar el próximo cuatrimestre.
Durante la reunión tratamos algunos de los puntos a mejorar detectados durante las retrospectivas del cuatrimestre anterior.
Puntualmente sacamos en concreto la definición de los 3 trabajos prácticos que vamos a dar y también definimos algunos puntos sobre la implementación de mejoras al titiritero.
Personalmente estoy muy contento con los trabajos definidos pues me parecen muy apropiados ya que van a permitir a los alumnos integrar conocimientos de otras materias y modelar problemas en distintos dominios.

Dinámica clase de repaso en algo3

Junto con Pablo ayer dimos una clase de consulta pre-parcial. Decimos probar un nueva dinámica para intentar hacerla más interactiva que la clásica clase de consulta donde el docente se para al frente y contesta las preguntas de los alumnos. (digo nueva porque nunca la habiamos utilizado y fue un «invento» propio).

Comenzamos por pedirles a los alumnos que ANTES de asistir a la clase, repasaran lo que se dio en cada una de las clases intentado identificar los temas más relevantes de cada una.

Ya una vez en la clase les pedimos que se agruparan en grupos de 5 o 6 personas y anotaran en una hoja lo que les parecian los temas más relevantes de la clase 1. Luego de 10 minutos aproximadamente retiramos las hojas y utilizamos los puntos identificados por los alumnos como disparadores de la revisión. Lamentablemente la mayoria de los alumnos se limitó a copiar la agenda de la clase que Carlos suele poner al comienzo de la ppt. De todas formas fuimos hablando de los distintos temas y contestando las consultas que fueron surgiendo.

Luego pasamos a la clase 2, pero en este caso en lugar de pedirles que identificaran los temas más relevantes de dicha clase, les pedimos que formularan 2 preguntas relacionadas a los temas de la misma (10 min). Luego intercambiamos las preguntas formuladas por cada grupo para que las respondienran (10 min). Finalmente tomamos las hojas con las preguntas y respuestas y las fuimos repasando entre todos, verificando/explicando las respuestas. Obviamente como era de esperar varios grupos habian formulado preguntas muy similares. Al mismo tiempo, ocurrio que algunas de las preguntas/respuestas formuladas por los alumnos dispararon otras preguntas.

La clase continuo con la misma dinámica repasando cada una de las clases. La dinámica duró poco más de dos horas y media y luego nos quedamos alrededor de media hora más respondiendo consultas particulares de algunos alumnos.

Con Pablo quedamos muy contentos con como salió la clase y hemos tenido un buen feedback preliminar de los alumnos.

Comienzo de clases en Algo3

Ya van dos semanas de clases y el cuatrimestre pinta muy prometedor. Para este cuatrimestre el equipo docente del curso 1 está conformado por: Pablo, GabiF, GabiD, Victoria y quien escribe.

La clase 1 la comenzamos haciendo la dinámica de la telaraña, haciendo que cada uno se presente diciendo: nombre, materias que cursa en el cuatrimestre y lenguajes de programación que sabe (obviamente los docentes también nos presentamos). Luego de eso, Pablo hizo la tradicional presentación de la material, comentado la dinámica de las clases, el régimen de cursada y las herramientas de trabajo (página web, lista de correo, etc). Finalmente cerramos la clase con la introducción a Smalltalk (Pharo, para ser más precisos) y la presentación del TP0.

La clase 2 comenzó con una breve explicación de algunas particularidades de Pharo y luego estuvo enfocada en el juego de rol de la máquina de café. Este juego tiene como objetivo entender que los objetos cumplen su objetivo a partir del envio de mensajes a otros objetos. Gabriel se encargó de  facilitar la dinámica del juego que duró unos 25 minutos. Para incentivar la participación de los alumnos (ya que el juego requiere de 7 alumnos) decidimos presentar la «lista de alumnos participativos», la idea es que en esta lista anotamos a los alumnos que participan en las clases y a la hora de definir las notas, aquellos alumnos participativos obtiene una consideración especial (puntualmente si la nota es decimal, la redondeamos directamente hacia arriba: si la nota es 6.1, automáticamente es redondeada a 7). A grandes rasgos el juego consiste en que cada alumno participante representa un objeto y como tal, recibe mensajes y tiene que colaborar con otros objetos (enviando mensajes, claro está) para responder a los mensajes recibidos.Luego del juego decidimos codificar en Smalltalk cada una de clases involucradas, para lo cual pedimos otros tantos alumnos volutarios. Esto nos una hora y media, ya que durante la codificación surgieron algunas dudas de diseño  que promovieron el debate. En paralelo a todo esto, el resto del equipo docente corregia los TP0. Al final de la clase entregamos TODOS los trabajos corregidos, excelente!.

Realmente estoy muy contento con el nivel de participación de los alumnos, si sigue así, creo que vamos a tener clases muy entretenidas.

[Algo 3] Reunión de fin de año y retrospectiva interna

Luego de exámen del martes pasado, hicimos la reunión de fin de año. Mientras degustábamos la abundante picada preparada por Pablo y los sandwiches de miga traidos por Diego hablamos de diversos temas incluyendo la acreditación de las carreras de informática, la reforma de los planes de estudio y otras cuestiones que exceden el ambito académico y no vienen al caso en este post. Como era esperar también hablamos de la materia, reflexionando sobre nuestra visión del cuatrimestre y sobre las opiniones recogidas durante las retrospectivas con los alumnos. A partir de esto surgieron algunas ideas para incorporar en próximos cuatrimestres. De estas ideas quiero destacar particularmente 2:

  • Algo3 2.0:  definitivamente vamos a abrir una cuenta de Twitter para publicar noticias durante la cursada y tal vez  twitear en vivo durante las clases. También mencionamos la posibilidad de lleevar un blog para postear lo que vamos vamos viendo en cada clase, pero esto no es seguro (aunque Gabriel estaba muy motivado con implementarlo)
  • Nuevo tipo de TP: durante la materia hacemos mucho incapié en la evolución del software y el hecho de que el código se escribe una vez pero se lee muchas. A pesar de esto nuestros TPs les piden a los alumnos escribir código pero no leer. Es por esto que posiblemente en próximos cuatrimestres incorporemos un nuevo tipo de TP, donde los alumnos partan de una aplicación ya codificada y deban entenderla para luego poder extenderla.

Equipo de Algo3 en la reunión de fin de año.