Esta discusión se tuvo hace algunos años en un grupo de personas que se interesan por la enseñanza de las ciencias de la computación, intentando echar la culpa de algunos males a la programación orientada a objetos. La programación es inherentemente difícil de enseñar, por ahora. Recordemos que muchas materias como la física, álgebra, química hace mucho tiempo eran materias de gran estudio en la universidad. Hoy en dia forman parte de un legado mínimo de conocimiento de una gran cantidad de seres humanos. Michael Kolling, uno de los creadores de BlueJ, da su opinión sobre la enseñanza de la programación usando primero objetos en una publicación de su blog denominada I Object (cuyo título es excelentemente adecuado en muchas interpretaciones posibles).
No sé si la POO estará por mucho tiempo más dando vueltas alrededor de nosotros, pero por ahora ha demostrado estar resolviendo algunos problemas. No va a resolver todo, pero tiene herramientas de abstracción mejoradas respecto a otros paradigmas populares en la enseñanza y en la práctica profesional. Dado que es uno de las formas más comunes de empaquetar la administración de la funcionalidad de muchas aplicaciones actuales merece la pena ser enseñada y cultivada desde el primer semestre para carreras de formación de profesionales en computación.
Palabras clave: enseñanza programación, programación orientada objetos
Comentarios
Lo escrito por M. Colling es muy interesante,.... tan interesante como las pruebas y argumentos para señalar las dificultades de enseñar POO desde el nivel inicial. Supongo que este asunto es un debate que no acabará en un corto tiempo. aqui mi opinion personal.
No creo que POO sea más difícil o mas fácil que PP (procedural), PP se impartió bastante bien prescindiendo de herramientas sofisticadas (tal el caso de BlueJ para POO) y creo que contribuye bastante o refuerza ciertos aspectos que POO los pasa superficialmente (como el caso de orden de ejecución, la idea ordenada de algoritmo, etc) pero es débil a tiempo de resaltar la: comunicación o colaboración, la estructura y la arquitectura en general. Estas debilidades son suficientemente importantes como para pensemos que PP es insuficiente..... la alternativa que refuerza aquello que se busca es sencillamente POO: otorga claridad en la estructura y por consiguiente guia implícitamente la idea de arquitectura (en estos tiempos hacer diseños sin arquitectura es como hacer agricultura con un arado tirado por un esclavo), POO da la idea de estructura, da la idea de comunicación, la idea de colaboración, pese a las dificultades actuales en impartir su enseñanza, estos aspectos son sumamente importantes descubrir en los desarrolladores actuales.
POr otro lado, impartir PP como primer encuentro con la programación corre el riesgo de "traumar" negativamente a los estudiantes, que luego tendrán que estudiar POO indefectiblemente. (me pongo como ejemplo de un estudiante traumado por el cambio tecnológico...... aún tengo problemas por el simple hecho de haber tenido a AtariBasic, Qbasic, y Pascal como mis primeros lenguajes, la edad media paso con Fox, Dbase, TurboPascal, ANSI C..... el renacimiento vino con SQL, Gofer, LIsp, C++, java, y ahora Hakell.)
Es cierto, estudiar POO es algo que no se le puede escapar a nadie que sea de CS. Y por tal motivo es buena idea enseñar POO desde el principio. POO ha demostrado ser un paradigma maduro y que puede resolver, sino todos, pero la gran mayoría de los problemas.
Además, he podido ver que es menos traumante aprender PP luego de ver POO.
La respuesta? ... es un rotundo NO.
Por el contrario, por instinto de programador, diría que es beneficioso y bueno.(POO no es perfecta pero es un paso hacia adelante).
El día de ayer, cuando leía este post, mi respuesta instantánea fué NO más bien beneficioso , pero no he querido sólamente poner mi humilde opinión de programador sobre la marcha; tampoco he querido hacer referencia directamente a M. Kolling (aunque más adelante es inevitable), uno de los impulsores de OO desde un inicio.
La primera suposición es que programadores inexpertos en OO tendrán una mala experiencia en un curso introductorio de POO desde cero. Es necesario haber adquirido destrezas en POO. De hecho, todas las experiencias que conozco de enseñar POO desde cero han fracasado; primero para el profesor y por consecuencia para los estudiantes. Tambien debo reconocer que mi primera experiencia, hace ya varios años (alrededor del 2001), de enseñar POO temprano tuvo bastantes falencias, y he tenido que aprender de los errores (los profesores que no han querido reconocer que deben aprender y/o que se sienten en la incapacidad de hacerlo han terminado atacando las nuevas experiencias y obstruyendo al evolución).
La segunda suposición es que programar ya no sólamente es escribir código, más bien incluye el diseño y el código. Si se omite alguno se deja de ser programador (en la actualidad). Si uno es programador OO inevitablemente PROGRAMA diseñando y codificando, BlueJ es un buen ejemplo.
En OO se programa en pedazos pequeños (clases) que siguen reglas de cooperación y composición (comunicación entre clases) en lugar de pedazos monolíticos y grandes como en Procedural. Una idea intuitiva que he tenido y me alegra encontrar respaldo en Martin Fowler (UML Distilled: A Brief Guide to the
Standard Object Modeling Language de M. Fowler en la tercera edición)
El artículo "Fundamental Concepts of CS1: Procedural vs. Object Oriented Paradigm - A Case Study " de Vilner, Zur y Gal-Ezer en ITiCSE'07, June 23–27, 2007, Dundee, Scotland, United Kingdom. ACM. Da la razón que POO temprano es mejor que Procedural. Obviamente se puede encontrar posiciones opuestas, que en su mayoría vulneran las tres suposiciones anteriores o al menos una de ellas.
En el artículo mencionado se toma le experiencia de un curso introductorio a programación dividido en dos grupos: procedural (C++) y OO (Java). Se comentan los resultados obtenidos por conocimiento y destrezas obten idas, donde los estudiantes del grupo OO obtuvieron ventajas en habilidades para resolver problemas más complejos; gracias a sus destrezas en diseño guiadas por los conceptos OO.
En lo que respecta al manejo de algoritmos, su uso en la resolución de problemas, Vilner, Zur y Gal-Ezer concluyen que no hay aventajados entre los Procedurales y los OO. Los que inician su vida de programadores con OO organizan los algoritmos a través de la comunicación entre objetos, encapsulación, cooperación y composición.