DirectricesOO

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.

 

[Grupo Ecuador] [Manifiesto] [WeBlio] [Miembros] [Recursos] [DirectricesOO] [Links] [Eventos] [TODOs] [Contáctanos]