Directrices para enseñar Orientación a Objetos
con Java
Directriz 1: Primero objetos.
Existe hoy casi un consenso entre los
profesores de OO acerca de que la orientación a objetos se enseña
de mejor manera enseñando acerca de objetos desde el inicio, por
contraposición a empezar con una aproximación de programación
estructurada de pequeña escala y agregar objetos más adelante.
Aunque hay muy poca evidencia científica que respalde esto, la
evidencia anecdótica es tan fuerte que la gran mayoría de
profesores y libros de texto siguen ahora esta aproximación.
Aunque la idea suena bien, no es fácil, con los
ambientes tradicionales, llegar hasta los objetos muy
rápidamente. Para interactuar apropiadamente con un objeto,
típicamente un estudiante tiene que escribir un método main (¡código que hace mención a un método estático y un arreglo de parámetros aparte de otros conceptos!), usar una variable con tipo, crear un objeto y escribir una llamada a un método. Estos no son conceptos triviales y, como resultado, típicamente toma varias horas de instrucción (o varios capítulos en un libro de texto) el alcanzar el punto donde se pueden hacer llamadas a objetos.
Con BlueJ podemos realmente interactuar con
objetos como la primer cosa que hacemos. Puesto que los objetos
pueden ser creados interactivamente, la primera actividad para
los estudiantes debería ser abrir un proyecto existente, crear
unos pocos objetos, hacer llamadas a los métodos de esos objetos
e inspeccionar el estado de esos objetos. De este modo, realmente
interactuamos con los objetos antes de introducir ningún otro
concepto. Los objetos verdaderamente vienen primero.
Esta actividad ilustra algunos conceptos muy importantes:
- Un programa Java tiene clases que
representan los componentes del programa.
- Los objetos son creados a partir de clases.
- Se puede crear muchos objetos a partir de una única clase.
- Todos los objetos de la misma clase tienen
la misma estructura; los objetos de otras clases tienen
diferente estructura.
- El estado (valores de las variables) de
cada objeto es diferente.
- Los objetos tienen operaciones (métodos)
los cuales pueden ser invocados.
- Los métodos pueden tener parámetros y resultados.
Estos conceptos son ilustrados a través
de demostración o actividades guíadas antes de que un estudiante
escriba ningún código. Los estudiantes pueden sentir estos
conceptos a través de interacción directa.
Directriz 2: No empezar con una pantalla en blanco.
Uno de los errores más comunes en la enseñanza
de programación orientada a objetos es dejar a los estudiantes
empezar desde cero.
Empezar con una pantalla en blanco es un
ejercicio muy difícil. Escribir una nueva clase involucra diseño.
Uno tiene que decidir que clase(s) deberían existir y cuales
deberían ser sus métodos. Aún si inicialmente se les dice a los
estudiantes que clases y métodos escribir, ellos aún tienen que
hacer una actividad que en este punto no pueden comprender
completamente. Los estudiantes no pueden reconocer el por qué de las decisiones de diseño que se han tomado.
En su lugar, los estudiantes deberían empezar
haciendo cambios pequeños a código existente. De esta manera,
ellos pueden pasar a través de una secuencia de ejercicios de los
cuales pueden entender cada paso.
Si se espera que ellos escriban algún código
nuevo, lo pueden hacer como parte de una clase existente. Esto ha
sido descrito como un patrón educativo bajo el nombre “Llenar los
espacios en blanco” [1].
BlueJ facilita esto haciendo sencilla la
provisión y ejecución de proyectos que los estudiantes pueden
extender. Los diagramas de clases proveen a los estudiantes con
una visión general de lo que tienen entre manos y los estudiantes
rápidamente se acostumbran a la idea de que algunas clases han
sido ya provistas y no necesitan ser cambiadas.
Directriz 3: Leer código.
Una de los aspectos más enigmáticos de la
manera en la que la programación se enseña generalmente es que
los estudiantes empiezan a escribir código sin haber leído nada
de código.
La programación debe ser una de las pocas
disciplinas (¿la única?) donde esto ocurre. Imagine un curso de
escritura de ensayos. Nos sorprendería muchísimo ver a alguien
que espere que los estudiantes empiecen a escribir ensayos sin
nunca haber leído uno. Sin saber, de hecho, lo que en realidad es
un ensayo.
Pero a menudo es aún peor que eso: los
estudiantes no solo escriben código antes de leerlo sino que a
menudo no leen código para nada. Existen muchos cursos en los
cuales los únicos programas que los estudiantes ven son aquellos
que han escrito ellos mismos. Esto realmente desperdicia una gran
oportunidad. Los estudiantes pueden aprender un montón de
estudiar programas bien escritos y de copiar estilos y modismos.
Es importante, sin embargo, que los ejemplos que los estudiantes
lean estén bien escritos y que valgan la pena copiar.
Directriz 4: Usar proyectos “grandes”.
Un problema serio con la enseñanza de
orientación a objetos a principiantes es que los programas
orientados a objetos tienen algo de sobrecarga u overhead sintáctico. Esta sobrecarga es redondamente proporcional al número de clases (o constante para cada clase).
Este es un problema solo porque la razón para
tener esta sobrecarga no es inmediatamente aparente para los
principiantes. Y el problema parece peor mientras más pequeño es
el programa. Si la intención es ejecutar una solo línea de
código, entonces la sobrecarga sintáctica es, relativamente
hablando, grande pero parece más aceptable en programas más
grandes.
Algunos de los beneficios de la orientación a
objetos solo se vuelven aparentes en programas grandes. Los
artefactos orientados a objetos en un programa de una clase con
un método simplemente no tienen sentido. Esto significa que
mostrar a los estudiantes programas que consisten de un solo
método es mostrarles malos ejemplos (y por tanto contradice
nuestra directriz 3).
Los estudiantes deberían ver ejemplos
razonables desde el comienzo. En particular, deberían ver que una
aplicación Java consiste de un conjunto de clases cooperativas.
Por tanto, deberíamos mostrarles ejemplos “grandes” (en términos
de los estudiantes), los cuales consistan de varias clases con un
número razonable de métodos. El uso de proyectos grandes puede
además tener una variedad de otros beneficios relacionados para
los estudiantes: practicar la lectura de código, entender la
necesidad de que haya claridad en el código y documentación
adecuada, aprender a leer interfaces de clases, quizás trabajo en
equipo, y más [2].
Directriz 5: No empezar con “main”
.
El método “main” de Java no tiene nada que ver
con orientación a objetos. Su única razón de ser es conectar a la
aplicación con el sistema operativo. Contiene código que no
pertenece lógicamente a ninguna clase u objeto. Ciertamente no
implementa una operación de un objeto.
Por tanto, empezar a enseñar sobre orientación
a objetos usando el método “main” es empezar con una excepción a
la regla más que empezar con un ejemplo típico.
Desafortunadamente, la mayoría de ambientes
Java fuerzan a los usuarios a empezar estudiando el método main.
Esto no es cierto con BlueJ. Puesto que cualquier método puede
ser invocado, no hay ninguna necesidad de usar un método “main”.
Esto no significa que no enseñemos nunca sobre
el método “main”. El objetivo sigue siendo que los estudiantes
puedan, al final, escribir programas en cualquier ambiente
estándar. Significa, sin embargo, que un profesor puede ahora
elegir cuando introducir el método “main” en lugar de verse
forzado a hacerlo como la primerísima cosa. Normalmente, uno no
debería elegir introducir conceptos como métodos estáticos o
arreglos en la primera clase.
En nuestro curso, tomamos una semana hacia el
final del primer semestre para cubrir como escribir y ejecutar
Java fuera de BlueJ. Esto se hace con una conferencia y
ejercicios guiados. Para ese momento, los estudiantes conocen los
métodos estáticos, los modificadores de acceso, los parámetros y
los arreglos de manera que ellos conocen realmente los detalles
necesarios para entender apropiadamente el método “main”.
Directriz 6: Mostrar la estructura del programa.
Al discutir la programación orientada a
objetos, las clases y sus relaciones son una cuestión central. La
estructura de la aplicación es crucial para la calidad de la
solución. Pero en la mayoría de ambientes de desarrollo, la
estructura interna del programa no es visible.
Es muy difícil discutir temas de una manera
completamente abstracta. El visualizar la estructura de clases es
crucial para que los estudiantes desarrollen una comprensión de
los conceptos importantes.
Si los ambientes de programación no proveen la
funcionalidad para desplegar esa estructura, los profesores deben
tener mucho cuidado para ofrecer representaciones visuales por
otros medios como una base para la discusión. BlueJ facilita esta
discusión pues automáticamente calcula y despliega el diagrama de
clases.
Directriz 7: Tener mucho cuidado con la interfaz de usuario.
Esta directriz se preocupa de la interfaz del
código temprano de los estudiantes. ¿Cómo deberían hacerse
visibles los resultados del trabajo de los estudiantes y cómo
deberían ingresarse los parámetros?
Hay tres alternativas comúnmente usadas: E/S
textual, interfaces gráficas de usuario (GUIs) o applets.
Cada una de las tres tiene sus propios problemas asociados.
La salida textual no tiene problemas. Es simple
y fácil de entender. El problema con E/S textual es la entrada
textual. La lectura de texto desde una terminal requiere el uso
de clases y métodos de biblioteca no triviales. Además requiere
una buena comprensión de tipos de datos y moldeado (casting)
de tipos. Claramente no es posible que los estudiantes puedan
tener una buena comprensión de todas estas cuestiones para el
momento en que deseamos que produzcan su primera sección de
código. Esperar que los estudiantes principiantes escriban
métodos de ingreso de texto invariablemente lleva a un montón de
manos levantadas y tener que decirles a los estudiantes que
simplemente digiten un patrón de código dado sin que entiendan
completamente lo que están haciendo.
Las GUIs proveen una distracción seria de las
cuestiones reales que subyacen los conceptos de programación
generales y no sirven bien para ilustrar principios generales. El
código GUI es un ejemplo muy específico de una estructura de
objetos que tiene características muy idiosincrásicas que
no son comunes a la OO en general.
La construcción de GUIs además distrae de
pensar acerca de tópicos importantes. Los estudiantes tienden a
considerar más importante aquellas cosas que les toman más tiempo
hacer y la construcción de interfaces gráficas demanda mucho
tiempo. Con frecuencia, los estudiantes terminan gastando un
montón de tiempo moviendo botones en la pantalla en lugar de
trabajar en la funcionalidad o la estructura de una
implementación. Como consecuencia, a menudo no desarrollan una
apreciación de la estructura del programa y el diseño de la
implementación.
Los applets, a veces usados como una manera
rápida de construir una interfaz, tampoco ayudan mucho a
simplificar las cosas. Los applets solo remueven el marco de alto
nivel de construcción de una GUI, que en este caso es provisto
por el visor de applets o el navegador. Esta es además una
distracción de principios fundamentales de programación temprana.
Lo que deja una pregunta: ¿Qué hacemos en lugar de todo esto?
Enfrentándonos con la E/S
Para evitar los problemas asociados con estos
tres tipos de interfaces, podemos usar una de dos posibles
soluciones.
La primera es específica de BlueJ: puesto que
BlueJ permite la ejecución de métodos arbitrarios y el paso
interactivo de parámetros, este mecanismo de invocación puede ser
usado para ejecutar código del estudiante y proveer entrada. Los
resultados están además disponibles a través del ambiente (los
resultados de los métodos se despliegan en diálogos). Este es el
mejor estilo de interacción con el usuario para ejemplos
tempranos. Todo el código que los estudiantes escriben está en
métodos Java estándar – uno de los conceptos más centrales de la
orientación a objetos.
La segunda solución está relacionada con la
directriz 4 (“usar proyectos grandes”). Nótese que el problema no
yace en que los estudiantes usen (indirectamente) E/S textual o
GUIs, sino en el hecho de que los estudiantes tengan que escribir
o entender el código que lo hace. Entiendo esto, se puede dar a
los estudiantes proyectos parcialmente implementados que ya
provean la interfaz de usuario, textual o gráfica. La tarea del
estudiante puede entonces ser trabajar en partes del proyecto que
no estén relacionados con E/S. Por tanto, el código del
estudiante otra vez se comunica con su ambiente exclusivamente a
través de llamadas a métodos.
Esta solución es más adecuada una vez que los
estudiantes tienen un buen manejo de algunos de los conceptos
importantes.
|