La programación orientada a objetos (POO) es un paradigma de programación que empezó a popularizarse a inicios de la década los 90 a raíz de la necesidad de modelizar entidades de la vida real: árboles, personas, balones… A pesar de ser un estilo de programación bastante simple, requiere un mínimo de capacidad de abstracción, y muchos alumnos y alumnas de TIC II de 2º de bachillerato no suelen entenderlo. Es por esto que en este ensayo me he propuesto desarrollar una estructura de actividades de aprendizaje sobre este tema, adecuándolo a las necesidades y conocimientos del alumnado.
En una primera fase, daría una clase magistral explicando el concepto de “clase” y “objeto”, sin programar absolutamente ninguna línea de código (similar al contenido del siguiente vídeo pero evitando las partes de: herencia, polimorfismo y de los lenguajes de programación, pues aún es pronto para hablar de eso).
Después, una vez hubiera explicado el contenido teórico, intentaría reforzar la idea proponiendo un ejemplo sobre los hipotéticos objetos que hay en esa misma aula. Para ello, escribiría en la pizarra las dos siguientes clases con estos atributos y métodos:
Clase “Silla”:
+ Atributo “precio”, que es un número.
+ Atributo “cómoda”, que es verdadero/falso (la única cómoda es la del profe).
+ No tiene ningún método
Clase “Humano”:
+ Atributo “nombre”, que es un texto.
+ Atributo “email”, que es un texto.
+ Atributo “soltero”, que es verdadero/falso.
+ Método “sentarse”, que utilizará objetos de la clase “Silla”.
Y… ¡Voilá! Creo que de esta manera podrían entender a qué es lo que los informáticos llamamos clases u objetos, y de cómo se relacionan entre sí (instancias de “Humanos” utilizan instancias de “Sillas”), modelizando la realidad, objetivo fundamental de este paradigma de programación.
Sin embargo, para saber si lo han entendido, les pediría que se juntaran por grupos de 4 para modelizar el pabellón del instituto, utilizando, al menos, 10 clases diferentes. Al pedirles este ejercicio, que encaja con el aprendizaje basado en problemas (ABP), estaría aplicando varios principios, como:
El principio de información transitoria: estaría bien que hubieran atendido a mi explicación, pero con el ejercicio se verían obligados a aplicar el aprendizaje obtenido.
Principio del problema con solución libre: puede que haya grupos que introduzcan la clase “Humano” en su solución, la cual estaría bien. Pero también estaría bien que introdujeran las clases “Profesor” y “Alumno”. Conclusión: dos modelos distintos (parcial o totalmente) pueden estar bien.
Principio del problema resuelto: los alumnos estarían “tomando prestados” los esquemas asociados con la resolución de la memoria a largo plazo que tengo y les he mostrado a través del pequeño ejemplo. Esto, junto con su memoria de trabajo, debería ser necesario para poder resolver el nuevo problema planteado.
Principio de desvanecimiento de la ayuda: el ejemplo planteado es una ayuda adecuada al nivel de conocimiento del alumnado.
Además, planteando el problema en grupos de 4 personas, desarrollaría sus habilidades comunicativas y de resolución de problemas en grupo. También favorecería que pudieran explicarse entre ellos (interdependencia positiva) los conceptos básicos o la metodología planteada.
Una vez todos los grupos/equipos tuvieran sus modelos, les diría que se encargaran de nombrar a un portavoz por equipo, puesto que en 2-3 minutos empezaría a preguntar cuáles han sido sus propuestas. A partir de este momento, se generaría una situación que deberían gestionar: ¿quién de nosotros se atreve a contar nuestra solución? Puesto que a ellos probablemente les parecería muy subjetiva y de dudosa calidad la solución que habrían planteado al estar acostumbrados a asignaturas en las que solo hay una solución buena: Matemáticas, Física y Química…
Pasados esos 2-3 minutos de tensión, se empezarían a escuchar frases del tipo:
“Nosotros hemos planteado la clase Balón, con los atributos: diámetro, que es un número; pinchado, que tiene valor verdadero o falso…”
Nosotros hemos planteado la clase Portería, con los atributos: altura, que es un número; anchura, que es otro número…”.
Que provocarían otras frases como:
¡Vaya! Pues nosotros no hemos tenido en cuenta que hay porterías.
¡Oye! Y si he puesto la clase “Raqueta”, ¿está bien?
Pues a mí se me ha olvidado poner el atributo “pinchado” en la clase “Balón”.
Esto sería notablemente bueno, y significaría que han estado atentos a las soluciones del resto de compañeros y compañeras. Se diera o no esta situación de incertidumbre, remarcaría que no hay solución mala, siempre y cuando se hayan identificado objetos que de verdad están en el pabellón y se hayan caracterizado con unos atributos y unos métodos adecuados. Todo depende del nivel de detalle que se le quiera dar al modelo, pues es eso, un modelo de la realidad, no la realidad. ¿La clase Humano tiene que tener un atributo ojos? Pues igual no es necesario. Sin embargo, si estamos haciendo software para una óptica, tendremos nuestra clase “Ojo”, que seguro que estará muy bien detallada.
Para concluir, solamente quiero lanzar al aire la pregunta: ¿no sabías qué era la POO y has aprendido, al menos, lo básico? Porque si ha sido así, probablemente esta estructura esté bien planteada, a pesar de que seguramente no hayas realizado la actividad que he propuesto.
Fuentes:
Falcó, C. F. (2021). ¿Cómo Aprendemos? Google Classroom. https://classroom.google.com/u/1/w/MzcyNDg1MjgyNjQ4/t/all
Muy buen ensayo. Me resulta muy interesante que nombres y tengas en cuenta los 4 principios que nombras. Igualmente me ha gustado que has planteado cómo los alumnos pueden reaccionar ante la actividad.
Te respondo a la pregunta que planteas: sí, he aprendido un poco sobre POO y como si una de tus alumnas fuera te lanzo una pregunta: ¿una silla no puede tener el método "permitir sentarse" o "plegarse", por ejemplo?