El documento presenta los argumentos a favor de enseñar programación orientada a objetos (POO) desde el primer día en las titulaciones de informática. Los autores afirman que la POO es actualmente el mejor paradigma disponible y está ampliamente aceptado. Aunque reconocen que no es la solución óptima, creen que es lo mejor disponible y los planes de estudio incluyen su enseñanza. Argumentan que si la POO es el objetivo, es mejor empezar directamente con ella en lugar de enseñar primero programación estructurada y luego

1. Reflexiones y experiencias sobre la enseñanza de POO como
único paradigma
Daniel Gayo Avello, Agustín Cernuda del Río, Juan Manuel Cueva Lovelle,
Marián Díaz Fondón, Mª Pilar Almudena García Fuente, José Manuel Redondo López
Departamento de Informática
Universidad de Oviedo
C/Calvo Sotelo s/n 33007 Oviedo
e-mail: {dani, guti, cueva, fondon, almu, redondo}@lsi.uniovi.es
Con este artículo no pretendemos echar más
Resumen leña al fuego; somos conocedores de los incon-
venientes de ambas opciones, pero el hecho es que
En la actualidad el paradigma de orientación a forzosamente hay que decantarse por una y asumir
dichos inconvenientes. Aquí pretendemos sim-
objetos (en adelante OO) está ampliamente
aceptado y todos los Planes de Estudios modernos plemente describir por qué y cómo estamos ense-
consideran necesario impartir una o más ñando a alumnos de primer curso de Ingeniería
asignaturas relacionadas con el análisis, el diseño Técnica en Informática POO desde el primer día
sin encontrar más dificultades de las que se
y la programación orientados a objetos en las
titulaciones universitarias en informática. encontraban al enseñar programación estructurada
Sin embargo, existe un candente debate sobre y con unos resultados provisionales que juzgamos
el momento de presentar a los alumnos la pro- bastante satisfactorios.
En primer lugar partiremos de la hipótesis de
gramación orientada a objetos (en adelante POO).
Algunos docentes consideran problemático empe- que el paradigma OO, sin ser la panacea, es la
zar directamente con POO y creen necesario ense- mejor opción disponible en este momento para el
ñar previamente programación estructurada. Otros desarrollo de software. Sobre esa base, argumen-
profesores opinan de manera totalmente opuesta. taremos que si la OO es un objetivo deseable es
En este artículo expondremos nuestros argu- conveniente afrontarlo desde el primer momento y
mentos a favor de una enseñanza temprana de la de la forma más directa posible. A continuación
POO, así como los contenidos teóricos y prácticos definiremos lo que entendemos por “introducción
impartidos en una asignatura de Introducción a la a la programación” y la forma en que semejante
Programación (OO) de primer curso, además de definición encaja en el programa de una asignatu-
los resultados y las conclusiones alcanzadas en ra de primer cuatrimestre. Posteriormente, descri-
este primer año de andadura. biremos la manera en que se conducen las clases,
se expondrán algunos ejercicios llevados a cabo
con los alumnos y se comentarán brevemente los
1. Introducción resultados parciales que se han obtenido, así como
las impresiones de alumnos que han experimenta-
Desde hace algún tiempo se viene debatiendo la do en cursos anteriores la enseñanza de programa-
forma de introducir la POO en las enseñanzas ción estructurada como paso previo a la POO.
universitarias en informática. Se trata de un debate
fuertemente polarizado. En un lado nos 2. ¿Es útil la orientación a objetos?
encontramos aquellos que consideramos que es
necesario comenzar a explicar a los alumnos OO
desde el primer día. En el otro se sitúan los que Muchos conceptos básicos de la OO se remontan
creen que se debe empezar por la programación a finales de los años 60 (lenguaje Simula) y 70
estructurada para, después, enseñar OO. (Smalltalk) y es a mediados de los años 80 cuando
la OO comienza a despuntar. Hoy en día la OO es

2. 2 No escribir nada
considerada por la inmensa mayoría de las 3. Orientación a objetos en los planes de
personas involucradas en el desarrollo de software estudio
como el mejor paradigma disponible para
construir sistemas informáticos. En resumen, la OO y los lenguajes, métodos y
Sin embargo, el hecho de que un grupo herramientas asociados no son una solución
numeroso afirme que algo es cierto no implica que óptima, pero es lo mejor que hay disponible y el
necesariamente lo sea. En el OOPSLA 2002 se ce- mercado demanda profesionales formados en estas
lebró un debate en torno al fracaso de los objetos. técnicas. Esta necesidad ha afectado finalmente a
Apoyaba esta tesis R.P. Gabriel y la refutaba G.L. la forma en que se plantean los planes de estudio
Steele Jr., ambos de Sun Microsystems. de las titulaciones en informática.
Entrar en detalles sobre tan interesante El Computing Curricula 2001 de ACM e IEEE
discusión no es el objeto de este escrito pero Computer Society [1] señala la OO como un
puede resultar ilustrativo mencionar algunos cambio tecnológico relevante en la enseñanza uni-
puntos allí tratados. versitaria de la informática. Considera que la pro-
Gabriel argumenta el fracaso de los objetos gramación, el análisis y el diseño OO deben for-
apoyándose en la incapacidad de la OO para mar parte de cualquier plan de estudios en infor-
modelar de manera adecuada futuros requisitos mática y plantea varios enfoques para su enseñan-
(funcionamiento distribuido, ubicuidad y coo- za, interesándonos especialmente los denominados
peración entre componentes), en la pérdida de la “Primero imperativo” y “Primero objetos”. En el
simplicidad de los lenguajes originales, en el siguiente apartado argumentaremos por qué consi-
escaso índice de reutilización así como en la falsa deramos conveniente aplicar el segundo
sensación de facilidad de aprendizaje cuando “en planteamiento.
realidad (programar) es tan difícil como siempre”
[7]. Sin embargo, la principal crítica que hace a la
OO es que “asfixia” la investigación y desarrollo 4. ¿Por qué empezar por objetos?
de nuevos paradigmas de programación.
Por su parte, Steele [13] afirma que la OO es Hemos establecido que la OO es un paradigma
un éxito: la mayor parte de los desarrolladores extendido, con un amplio soporte por parte de la
emplean lenguajes OO y los objetos son un buen industria y que debe ser conocido por cualquier
modelo para la mayoría de entidades del mundo estudiante universitario de informática. Así pues,
real. Señala que el énfasis en procesar entradas de la cuestión no es si se debe enseñar OO sino en
datos para transformarlas en salidas es una debili- qué momento se debe presentar; básicamente, se
dad de la programación procedimental que ha trata de elegir entre las dos opciones planteadas en
hecho que la OO fuese la respuesta a muchos pro- el mencionado informe de ACM/IEEE.
blemas que la primera difícilmente podía resolver. Este el centro del debate que mencionábamos
Naturalmente, acepta que la OO no puede resolver en la introducción: “¿Se debe enseñar desde el
todos los problemas de la programación, que la primer día POO?” Sin embargo, creemos que la
evolución del paradigma no se ha completado (y pregunta que se formula en semejante debate de-
tal vez nunca se haga) y que los lenguajes actuales bería replantearse como: “¿Se debe enseñar desde
no son los mejores lenguajes OO posibles. el primer día POO sabiendo que la OO es un obje-
Por nuestra parte, estamos de acuerdo en que tivo fundamental de una titulación universitaria en
es necesario desarrollar más el paradigma OO y informática?”
otros nuevos; sin embargo, estamos con Steele Entendemos que la primera pregunta, al estar
cuando afirma que “la POO es como el dinero: no planteada incorrectamente, ofrece muchas posibi-
lo es todo, pero es mucho mejor que las otras lidades de polémica. Sin embargo, si aceptamos
opciones”. Por otro lado, también coincidimos con que la OO es un paradigma útil y que los alumnos
Gabriel en que la POO no es más sencilla, sólo deben comprenderlo y manejarlo con soltura es
igual de difícil que la programación necesario, en nuestra opinión, comenzar desde el
procedimental. primer momento con la POO (en especial, en titu-
laciones de ciclo corto como la impartida en
nuestra Universidad).

3. IX Jornadas de Enseñanza Universitaria de la Informática 3
4.1. Posturas opuestas a un enfoque temprano datos que serán procesados y transformados, a su
vez, en nuevos datos. Así pues, en la programa-
Muchos autores consideran un error iniciar la ción procedimental el algoritmo es lo que cuenta y
enseñanza de la programación comenzando con la los datos son algo secundario, circunstancia poco
OO. Tan sólo en JENUI 2002 se presentaron frecuente en el mundo real.
cuatro ponencias que desaconsejaban tal opción. En parte, esta debilidad de la programación
Así, Fernández Muñoz et al ([5] y [6]) señalan procedimental ha facilitado el camino de la POO.
los siguientes problemas: sobrecarga de conceptos Ésta no busca en primer lugar soluciones a los
teóricos o sobresimplificación, utilización de bi- problemas sino que trata de modelar el sistema
bliotecas de clases, utilización de interfaces grá- como objetos que tendrán un comportamiento, un
ficos o entornos de desarrollo artificiosos. García estado y unas relaciones de colaboración entre los
Molina et al [9] proponen retrasar las asignaturas mismos.
de POO hasta el tercer curso de la titulación. Por Por ello, aun cuando los lenguajes OO sean
su parte, Gómez Albarrán [10] propone una asig- imperativos y se puedan establecer ciertos símiles
natura de introducción a la programación que co- entre métodos y subrutinas o entre objetos y TAD,
mienza con la descomposición funcional para lo cierto es que la forma en que se desarrolla un
pasar, posteriormente, a la OO. Todas estas pro- sistema informático para resolver un problema del
puestas pueden encuadrarse en la línea de “objetos mundo real es muy diferente según el paradigma
más tarde”. que se emplee; de ahí el problema del cambio de
paradigma y la afirmación tajante de Bergin de
4.2. ¿Qué paradigma enseñar si la OO es el que el paradigma procedimental es la opción equi-
objetivo? vocada si lo que se quiere es enseñar OO. No po-
demos por menos que estar de acuerdo con su
postura.
Las propuestas anteriores plantean algo en
apariencia muy sencillo: primero se enseña a los
alumnos el paradigma procedimental así como 5. Una propuesta para la introducción a
TAD’s. Una vez han asimilado los conceptos la programación
deberían aprender fácilmente POO puesto que
“puede considerarse un paradigma construido Un aspecto interesante de todas las propuestas
sobre la base del paradigma imperativo” [8]. mencionadas en el apartado 4.1 es que el citado
Sin embargo, en la práctica es frecuente que problema del “cambio de paradigma” no parece
los alumnos se encuentren con el problema del producirse. Sería muy interesante estudiar qué
“cambio de paradigma”. Stroustrup [14] asegura aspectos de la actividad docente de los respectivos
que un programador experimentado en el autores permiten evitar tal problema, pero en
paradigma procedimental necesita entre 6 y 18 nuestro caso lo hemos sufrido de forma clara y
meses para adaptarse al paradigma OO. reiterada, hasta el punto de que lo consideramos
Probablemente sea pedir demasiado que nuestros una premisa en las decisiones que tomamos.
alumnos se adapten mejor que un profesional. Debido en parte a nuestra experiencia y
Hay otras razones de peso que aconsejan convencidos de la importancia de la OO para los
comenzar por la OO si es el objetivo perseguido alumnos se decidió aprovechar la entrada del
en la formación de los estudiantes. Todas ellas se nuevo Plan de Estudios1 para construir una asigna-
derivan de una premisa muy simple: a pesar de las tura de introducción a la programación donde el
similitudes no puede decirse que la OO sea una único paradigma que estudiaría el alumno fuese la
mera extensión del paradigma procedimental. OO.
Bergin [2] señala que el problema de enseñar Desde nuestro punto de vista el objetivo pri-
el paradigma procedimental como paso previo a la mordial de tal asignatura sería proporcionar a los
POO radica en que las estrategias de resolución de alumnos conocimientos y estrategias básicos para
problemas de ambos paradigmas son radicalmente poder enfrentarse a un problema del mundo real
distintas. Así, la programación procedimental fo- susceptible de ser solucionado informáticamente,
menta la división de problemas en subproblemas
que deben ser resolubles a partir de una serie de 1
http://www.euitio.uniovi.es/nuevoplan/spanish

4. 4 No escribir nada
determinar los objetos que podrían modelar tal información en un ordenador y los distintos tipos
sistema, describir con una notación precisa el de lenguajes de programación existentes.
modelo a construir e implementar dicho modelo 1. ANTECEDENTES
mediante un lenguaje de programación OO. 1.1. Historia de la Informática
1.2. Lenguajes de programación
En el caso que nos ocupa, dicha asignatura, 2. INTRODUCCIÓN A LA PROGRAMACIÓN ORIENTADA A OBJETOS
2.1. Paradigma OO.
denominada Introducción a la Programación, 2.2. Encapsulación y ocultación de información.
2.3. Abstracción y genericidad.
consta de 3 créditos de teoría, 1 crédito de 2.4. Comportamiento de los objetos.
prácticas de tablero y 2 créditos de prácticas de 2.5. Constructores y destructores.
2.6. Recolección de basura.
laboratorio y se imparte en el primer cuatrimestre. 3. ESTADO DE LOS OBJETOS
3.1. Tipos de datos. Tipos primitivos.
A la hora de elaborar el programa y 3.2. Declaración de atributos
3.3. Expresiones y asignación.
seleccionar las herramientas a emplear se trataron 3.4. Comprobación de tipos.
de alcanzar los siguientes objetivos: 4. COMPORTAMIENTO DE LOS OBJETOS
4.1. Métodos.
1. Seguir, hasta donde fuera posible, las propues- 4.2. Paso de parámetros.
4.3. Declaración de variables
tas “objetos primero” de ACM/IEEE [1]. 4.4. Sobrecarga de métodos.
5. ESTRUCTURAS DE CONTROL
2. Lograr que el alumno aprendiese POO y no las 5.1. Propiedades de las estructuras de control.
peculiaridades del lenguaje de programación 5.2. Estructura secuencial.
5.3. Estructuras alternativas.
elegido. 5.4. Estructuras repetitivas.
6. CLASIFICACIÓN DE OBJETOS
3. Presentar los contenidos teóricos de manera que 6.1. Clases y subclases.
se facilitase su comprensión y aprendizaje pro- 6.2. Interfaces.
6.3. Herencia de clases e interfaces. Redefinición de métodos.
gresivo y, a la vez, permitiese el desarrollo de 6.4. Jerarquías de clases.
7. ESTRUCTURAS DE DATOS FUNDAMENTALES
ejercicios prácticos desde el primer momento. 7.1. Arrays.
7.2. Cadenas de caracteres.
4. Minimizar el impacto de la herramienta de
desarrollo en la realización de los ejercicios. Figura 1. Temario teórico de “Introducción a la
5. Presentar a los alumnos técnicas básicas de Programación”
análisis y diseño orientado a objetos así como Prácticas de tablero
los elementos mínimos de la notación UML.
1. INTRODUCCIÓN A LA PROGRAMACIÓN ORIENTADA A OBJETOS
6. Evitar, en la medida de lo posible, problemas 2. ESTADO DE LOS OBJETOS
3. COMPORTAMIENTO DE LOS OBJETOS
habituales en este tipo de iniciativas como la 4. ESTRUCTURAS DE CONTROL
utilización de entornos artificiosos, el énfasis en 5. CLASES DE OBJETOS
6. ESTRUCTURAS DE DATOS FUNDAMENTALES
el desarrollo de aplicaciones gráficas o la
Prácticas de laboratorio
presencia excesiva de bibliotecas de clases.
1. PRESENTACIÓN DEL ENTORNO DE DESARROLLO.
En base a tales objetivos y teniendo en cuenta 2. COMPORTAMIENTO DE LOS OBJETOS (I).
el tiempo disponible se elaboró el programa de la 3.
4.
DOTANDO DE ESTADO A LOS OBJETOS.
COMPORTAMIENTO DE LOS OBJETOS (II).
asignatura cuyos bloques teóricos y prácticos prin- 5. JERARQUÍAS DE CLASES.
6. DESARROLLO DE UNA APLICACIÓN COMPLETA.
cipales se muestran en Figura 1 y Figura 2. En los
apartados siguientes se explicará de forma Figura 2. Temario práctico de “Introducción a la
detallada la forma en que se están impartiendo Programación”
estos contenidos. Una vez los alumnos han asimilado el concep-
to de algoritmo es posible plantearles sencillos
5.1. Contenidos teóricos problemas para los que se puede encontrar un al-
goritmo sin demasiadas dificultades. Sin embargo,
Los contenidos teóricos de la asignatura se la finalidad de esos ejemplos no es explicar el pa-
reparten en siete bloques. El primero permite radigma procedimental sino exponer sus
presentar a los alumnos una serie de conceptos debilidades.
fundamentales (en especial el de algoritmo) así Para ello, se pide a los estudiantes que traten
como la forma en que la informática ha de imaginar un algoritmo que resuelva un proble-
evolucionado para resolver la antigua necesidad ma muy complejo (por ejemplo, gestionar un sis-
de realizar cálculos y procesar datos de manera tema de control de tráfico aéreo). Naturalmente,
automatizada. Además, se explica a los coinciden en que desarrollar semejante algoritmo
estudiantes el funcionamiento de la arquitectura puede resultar muy arduo.
Von Neumann, la forma en que se representa la A continuación se pide a los alumnos que tra-

5. IX Jornadas de Enseñanza Universitaria de la Informática 5
ten de identificar objetos que sean relevantes en el varias clases, empleando adecuadamente relacio-
ámbito de dicho problema, así como el comporta- nes de herencia y asociaciones con multiplicidad.
miento que mejor los defina. Esta tarea no les
resulta demasiado complicada y sí bastante 5.2. Lenguaje de programación elegido
motivadora.
Tras este contacto intuitivo con el paradigma Para el desarrollo de las prácticas era posible
se dedican al menos tres sesiones a explicar los elegir entre muchos lenguajes: Smalltalk, Eiffel,
conceptos básicos del mismo. Aquí se tocan los C++, Java, etc. Todos presentan inconvenientes a
temas fundamentales de manera breve y tratando la hora de ser empleados como un lenguaje para
de mantener una visión global: diferencias entre enseñanza, resultando la opción “menos mala”
clase y objeto, comportamiento y estado, métodos Java [11].
y atributos, constructores, herencia, etc. Como argumentos a favor del uso de Java
La mayoría de los alumnos no comprenden de podemos citar los siguientes:
una forma clara muchos de los conceptos más 1. Es un lenguaje OO prácticamente puro.
difíciles; es necesario insistir en que lo funda- 2. La sintaxis es sencilla y legible, y permite
mental en este momento no es comprenderlo todo expresar la mayor parte de conceptos OO de
sino saber de su existencia y conocer, a grandes una manera simple.
rasgos, las relaciones entre los distintos conceptos. 3. Es un lenguaje relativamente pequeño.
Una vez se ha presentado una panorámica de 4. Los alumnos pueden trabajar con él sin tener
la POO se puede comenzar a entrar en detalles que conocer un número excesivo de clases de la
referentes a estado y comportamiento. Así, al biblioteca.
explicar el concepto de estado es posible 5. Sólo permite herencia simple.
introducir los conceptos de tipos de datos, tipos 6. El alumno no tiene que preocuparse de la
primitivos, declaración de variables miembro, etc. reserva y liberación de memoria.
Al explicar el comportamiento de los objetos 7. Es ampliamente utilizado por la industria y
deberían tocarse temas especialmente relevantes facilita la transición a otros lenguajes OO.
como definición de métodos, variables locales, Obviamente, Java presenta una serie de incon-
paso de parámetros, sobrecarga, etc. junto con las venientes, entre los que se pueden mencionar:
estructuras de control básicas. 1. La existencia de tipos simples puede confundir
Finalmente se explicarían de manera muy sen- al principio a los estudiantes.
cilla herencia, interfaces, redefinición de métodos 2. La entrada/salida requiere la utilización de
y se introduciría brevemente el polimorfismo. clases de la biblioteca del lenguaje y resulta,
Por último, se explicarían los principales mé- cuando menos, engorrosa.
todos de la clase String y arrays. La razón para 3. Hasta que los alumnos se acostumbran a que es
retrasar hasta el final de la asignatura el concepto un lenguaje sensible a mayúsculas las clases
de array es simple. Mientras los alumnos no ma- contenedoras de tipos simples como Boolean,
nejen adecuadamente los conceptos de clase y Integer o Float pueden causar más de un
objeto además del mecanismo de herencia no es problema.
posible desarrollar ejercicios relativamente com- 4. El método main es totalmente ajeno a los
plejos; y será en dichos ejercicios donde los
conceptos OO y precisa entre una y dos clases
arrays sean verdaderamente útiles para poder
para ser correctamente explicado obligando,
implementar de una forma básica relaciones 1..n.
además, a introducir el concepto de métodos
Respecto a la forma de representar los con-
estáticos muy pronto.
ceptos de cara a su explicación hemos optado por
De los problemas anteriores los más graves
emplear la notación UML. Sin embargo, no hemos
son el segundo y el cuarto; a continuación se
hecho ningún esfuerzo específico por enseñar la
describirá la forma en que hemos tratado de
notación a los alumnos; simplemente hemos ido
solucionarlos en la asignatura que impartimos.
introduciendo símbolos a medida que eran nece-
Para llevar a cabo entrada y salida en Java
sarios. En estos momentos en los que la asignatura
sería necesario, en principio, explicar a los
está prácticamente finalizada los alumnos son ca-
alumnos en un momento muy temprano la
paces de desarrollar por sí solos modelos con
existencia de la biblioteca de clases de Java para

6. 6 No escribir nada
poder emplear los métodos de las clases Por supuesto, es necesario indicar a los
System.out y System.in. Para evitar esto alumnos que el método main es ajeno al
optamos por construir un paquete Consola que paradigma OO y que el código que se coloque en
implementa las clases Pantalla y Teclado y su interior debería ser siempre el menor posible.
explicamos los métodos para dichas clases (por
ejemplo, escribir o leerFlotante). 5.3. Herramientas de desarrollo
Las diferencias pueden parecer triviales pero
son importantes para los alumnos: Un problema común a la hora de impartir una
1. El alumno percibe perfectamente que asignatura de programación se plantea en el
Pantalla y Teclado son elementos ajenos momento de seleccionar el entorno de desarrollo,
al lenguaje; después de todo fueron escritas por especialmente si se trata de un lenguaje no
los profesores y tienen “nombres en español”. orientado al ámbito académico.
Esta tarea no es tan sencilla al emplear clases En nuestro caso debíamos seleccionar un
aportadas por la biblioteca de Java. entorno2 que permitiese el desarrollo de
2. La sentencia import es relativamente sencilla aplicaciones OO en Java y satisficiese, en la
de entender si se explica en términos de medida de lo posible, los siguientes criterios [12]:
directorios y subdirectorios. facilidad de uso, entorno integrado (editor,
3. Es posible presentar las clases Pantalla y compilador y depurador), IGU con soporte para
Teclado en una lección de teoría para que los manipulación de objetos y libre disponibilidad
alumnos vean qué es exactamente un objeto, la para los estudiantes.
forma en que proporciona un comportamiento Las opciones que se plantearon fueron las
para cumplir con sus responsabilidades así siguientes: Kawa, BlueJ, Borland JBuilder
como la forma en que se invocan mensajes. Personal y Visual J++.
Explicar el método main de una manera Kawa3 era un sencillo IDE proporcionado por
razonable es algo más complicado. En primer Macromedia; sin embargo, actualmente carece de
lugar, requiere que el alumno comprenda soporte y no tenía sentido animar a los estudiantes
perfectamente el concepto de algoritmo, la a utilizar una herramienta sin futuro.
arquitectura Von Neumann y la forma en que ésta BlueJ4 es la única de las herramientas
permite ejecutar algoritmos. anteriores específicamente pensada para su
Una vez estos conceptos están claros es utilización académica. Es gratuita, muy fácil de
necesario explicar las diferencias entre lenguajes usar y permite trabajar en un modo “visual”
de bajo y de alto nivel así como el papel jugado empleando UML. Además, el alumno puede
por los distintos tipos de traductores. instanciar objetos y enviarles mensajes
En ese momento se puede explicar de un directamente, con lo cual dos problemas de Java
modo muy sencillo la forma en que Java depende se solucionan de una forma sencilla: la
de una máquina virtual (JVM) y cómo el código entrada/salida y el método main.
fuente Java es traducido a bytecode que será Borland JBuilder Personal5 es una versión
ejecutado por la JVM que, a su vez, se ejecutará muy reducida de la herramienta Borland JBuilder
sobre una arquitectura Von Neumann.
Si todo esto queda claro a los alumnos (lo cual 2
¿Por qué no utilizar simplemente el JDK? Puede resul-
puede llevar toda una sesión de teoría) pueden tar muy instructivo enfrentarse a compiladores y depura-
entender que, de algún modo, aunque Java sea un dores en línea de órdenes. Sin embargo, la finalidad de
lenguaje OO tiene que acabar siendo traducido a la asignatura es aprender POO empleando Java y no
código de bajo nivel que se ejecutará en una aprender Java per se; por ello, el uso didáctico del JDK
arquitectura Von Neumann. Puesto que dicha carecía de sentido. Además, requeriría enseñar a la ma-
arquitectura requiere que un algoritmo tenga un yoría de los alumnos MS-DOS consumiendo un tiempo
punto de inicio y las instrucciones se ejecutan precioso. Por último, aun cuando fuesen capaces de em-
plear el JDK, la ausencia de entorno les distraería de lo
secuencialmente no les resulta difícil aceptar que
realmente importante: la POO.
de alguna forma es necesario indicar en el propio 3
http://www.macromedia.com/software/kawa
código Java qué método de qué clase será el 4
http://www.bluej.org
primero en ejecutarse. 5
http://www.borland.com/jbuilder/personal

7. IX Jornadas de Enseñanza Universitaria de la Informática 7
siendo, por tanto, muy similar a otros IDE’s por los profesores. Este ejercicio se entregará el
comerciales. La principal ventaja de esta herra- mismo día del examen escrito.
mienta es que cualquier usuario puede obtener una
licencia de uso personal de manera gratuita. 5.5. Resultados parciales
Visual J++ es similar aunque más complicado,
razón por la que fue descartado. En estos momentos la asignatura está a punto de
Así pues, había dos opciones: BlueJ y finalizar; los alumnos ya han realizado un control
JBuilder. Por motivos didácticos la opción más teórico y se ha evaluado el primer ejercicio
deseable era BlueJ. No obstante, su utilización práctico, estando pendientes el examen escrito, la
planteaba dudas sobre posibles problemas por entrega del segundo ejercicio práctico y el examen
parte de los alumnos al tener que cambiar a un práctico para quienes no sean evaluables mediante
IDE “real”. el sistema de evaluación continua.
Si dicho cambio se produjese en un nuevo El citado control se llevó a cabo tras apenas 6
curso habríamos elegido BlueJ; sin embargo, por semanas de clase y abarcó los tres primeros
diversas razones la asignatura “Interacción bloques del temario. El 85% de los matriculados
Persona-Ordenador” (IPO) se imparte en el se presentaron al examen y se obtuvieron los
segundo cuatrimestre del primer curso. Al no resultados que se muestran en Figura 3. En cuanto
encontrarse ningún entorno sencillo para el diseño a la evaluación de la primera práctica se han
de IGU’s que pudiese ser integrado con BlueJ nos obtenido los siguientes resultados: la han
vimos obligados a emplear Borland JBuilder presentado el 81% de los matriculados, el 9% de
Personal para no obligar a los alumnos a aprender los ejercicios eran “fraudulentos” (copias,
una herramienta distinta en cada cuatrimestre. prácticas en equipo, etc), de las prácticas válidas
Fueron necesarias dos sesiones prácticas para un 14% suspendieron, un 33% aprobaron, un 28%
presentar el entorno y muchos alumnos no obtuvieron notable y un 25% sobresaliente.
comenzaron a manejarlo de manera autónoma Además, tras ocho semanas de clase se realizó
hasta la tercera o la cuarta sesión. una encuesta entre el alumnado que había cursado
Metodología de la Programación I (una asignatura
5.4. Ejercicios prácticos del anterior Plan de Estudios que comenzaba con
programación estructurada y finalizaba con
Para superar la asignatura los estudiantes deben algunos conceptos de POO). Los resultados se
aprobar un examen práctico o bien superar con muestran en Figura 4.
éxito dos ejercicios que son desarrollados en gran
parte durante las sesiones prácticas y finalizados
fuera del horario docente.
El objetivo del primer ejercicio es consolidar
dos conceptos básicos de la POO como son estado
y comportamiento. Para ello el alumno parte de
una clase básica denominada Inichi que
implementa una sencilla mascota virtual [3].
Para superar el ejercicio el alumno debe
añadir a su mascota una serie de métodos y
atributos que la doten de un comportamiento más
complejo. Una parte importante de la evaluación
de este ejercicio obliga al alumno a realizar, bajo
condiciones controladas, una pequeña ampliación
que requiere algunos atributos y métodos nuevos.
En el segundo ejercicio [4] el alumno debe
desarrollar una aplicación completa que requiere
el uso de varias clases. Para ello puede optar por
Figura 3. Resultados del control teórico
desarrollar su propio modelo de clases o bien
ampliar uno de los distintos modelos propuestos

8. 8 No escribir nada
¿Dificultad
Factores [5] Fernández Muñoz, L., Peña, R., Nava, F.,
Paradigma ¿Dificultad influyen Velázquez Iturbide, A. Análisis de las pro-
práctica
preferido teoría POO? percepción
POO? puestas de la enseñanza de la programación
dificultad
orientada a objetos en los primeros cursos.
37% Cambio
30% Más 19% Más JENUI 2002. Cáceres, España.
78% OO de Pascal a
difícil difícil
Java [6] Fernández Muñoz, L., Peña, R., Nava, F.,
49% Velázquez Iturbide, A. Enfoque diacrónico
6% Indiferente 22%Similar 23% Similar Comenzar con
POO
para la enseñanza de la programación
40% Haber
imperativa. JENUI 2002. Cáceres, España.
16% Progr.
48% Más fácil 58% Más fácil
estudiado [7] Gabriel, R.P. Objects have failed.
Estructurada antes http://www.dreamsongs.com/NewFiles/Objec
programación tsHaveFailed.pdf
Figura 4. Resultados de la encuesta entre repetidores [8] García Molina, J. ¿Es conveniente la
Orientación a Objetos en un primer curso de
programación? Novática 154, 2001.
6. Conclusión [9] García Molina, J., Menárguez Tortosa, M.,
Moros Valle, B. Una propuesta para
Esta experiencia de enseñanza de la OO como organizar la enseñanza de la Orientación a
único paradigma de programación está resultando Objetos. JENUI 2002. Cáceres, España.
muy positiva. Creemos que no resulta más difícil [10] Gómez Albarrán, M. Metodología basada en
para el alumno que la programación estructurada descomposición funcional y orientación a
y, además, el grado de satisfacción de los alumnos objetos en la introducción a la programación.
con el enfoque, el lenguaje y la herramienta de JENUI 2002. Cáceres, España.
desarrollo son altos. Creemos que esto se debe a [11] Kölling, M. The Problem of Teaching Object-
una serie de factores motivadores: el alumno Oriented Programming, Part 1: Languages.
aprende un lenguaje que se emplea en la industria, Journal of Object-Oriented Programming,
utiliza una versión de una herramienta profesional Vol. 11 No. 8, 8-15, 1999.
http://www.mip.sdu.dk/~mik/papers/oo-
y se siente especialmente motivado por el propio languages.pdf
paradigma. No pensamos que esto se deba a que la [12] Kölling, M. The Problem of Teaching Object-
OO sea más intuitiva o sencilla que la Oriented Programming, Part 2:
programación estructurada; simplemente es más Environments. Journal of Object-Oriented
potente a la hora de enfrentarse a problemas reales Programming, Vol. 11 No. 9, 6-12, 1999.
y creemos que esta percepción de poder por parte http://www.mip.sdu.dk/~mik/papers/oo-
de alumnos de primer curso es lo que les alienta. environments.pdf
[13] Steele Jr., G.L. Objects have not failed.
http://www.dreamsongs.com/ObjectsHaveNot
Referencias FailedNarr.html
[14] Stroustrup, B. The Design and Evolution of
[1] ACM/IEEE. Computing Curricula 2001. C++. Addison-Wesley, 1994.
http://www.computer.org/education/cc2001
/report
[2] Bergin, J. Why Procedural is the Wrong First
Paradigm if OOP is the Goal.
http://csis.pace.edu/~bergin/papers/Whyn
otproceduralfirst.html
[3] Díaz Fondón, M., García Fuente, A., Gayo
Avello, D. Desarrollo de una mascota virtual.
http://www.euitio.uniovi.es/~ip/practica
09.pdf
[4] Díaz Fondón, M., García Fuente, A., Gayo
Avello, D., Redondo López, J.M. Evaluación
de conductores con dispositivos PDA.
http://www.euitio.uniovi.es/~ip/practica
10.pdf