Cronicas de un Mundo Gris

Siguiendo con el post anterior. Esto me recuerda uno de los mitos más difíciles de desterrar de la programación orientada a objetos, y uno de los más polémicos. En general un buen diseño en objetos te asegura un buen grado de reusabilidad, pero no es una garantía. Decir que trabajar con objetos te asegura la reusabilidad es una exageración, una falacia. No alcanza con usar programación orientada a objetos para hacer tu código reusable, y tampoco un lenguaje que no provee features del OOP está menos predispuesto a la reusabilidad solo por el hecho de no soportar OOP.

Por ahí acá resulta medio contradictorio lo que digo, siendo que es inevitable para mi hablar de reusabilidad cuando hablo del paradigma de objetos. En parte esto es porque no considero como un uso apropiado del paradigma aquello que no busque una buena reusabilidad de los algoritmos creados. Sin embargo hay que evitar enseñar a los que introducen en este paradigma que la reusabilidad se obtiene sin costo alguno. En particular hay que evitar dar a entender la reusabilidad como una característica del OOP. Se puede hacer tanto código reusable como pasta-code en OOP como en paradigma procedural o en el paradigma funcional.

En pocas palabras, la reusabilidad no es una característica del OOP, no hay garantías de ello prácticamente en ningún paradigma. PERO, diseñar a partir de simular los procesos reales (característico de OOP), sumado a un cuidado diseño orientado a la reusabilidad, generalmente concluyen en un sistema fácilmente mantenible.

En el foro de ADVA tuvimos con algunos usuarios una discusión bastante acalorada sobre el lenguaje C++ y en general sobre ciertos aspectos del paradigma de objetos. Uno de los temas tocados fue sobre la reusabilidad. Quiero extraer algunos fragmentos de esta discusión. Por ejemplo acá comento sobre la crítica academica al OOP en temas de reusabilidad y la propuesta del GoF y los patrones de diseño:

Algo en lo que insisto siempre es en destronar el mito del OOP como facilitador de la reusabilidad. Usar OOP no garantiza reusabilidad, por el contrario, una de las críticas académicas más fuertes al OOP es que la reusabilidad por herencia resulta en malas prácticas que afecta la mantenibilidad (esa palabra es un trabalenguas) del sistema. En contraposición, el paradigma procedural tiene un modelo de reusabilidad mucho más organizado, que genera una mayor independencia entre componentes.

Sobre esto, el “Grupo de los Cuatro” (Gang of Four) popularizo los términos de “white-box reuse” (reusabilidad a caja abierta) y “black-box reuse” (reusabilidad a caja cerrada). La reusabilidad a caja abierta, o reusabilidad por herencia, es la que es criticada por generar dependencias entre los componentes a la hora de hacer tareas de mantenimiento. La reusabilidad a caja cerrada, o reusabilidad por interfases, es la usada en el paradigma procedural y la que el GoF propone recuperar en el paradigma OO mediante patrones de diseño.

Ahí tengo que admitir que elegí mal las palabras. Puntualmente el OOP, bien usado, puede resultar un facilitador de la reusabilidad. El punto importante es que la reusabilidad no es una garantía, en ningún paradigma de la programación. En particular es una crítica académica que el OOP favorece practicas incorrectas de reusabilidad, pero esto está originado en el mismo ámbito académico que enseña mal el paradigma de objetos.

Acá hay otro extracto de esa discusión donde observo los comentarios de Stroustrup sobre el lenguaje C++ y el paradigma de objetos:

Me tome el tiempo de releer los capítulos iniciales del libro de Stroustrup. En ningún momento plantea el paradigma de objetos como una mejora a la reusabilidad, lo cual era de esperarse, sería una promesa ridícula. En el prefacio habla del OOP como una técnica de abstracción de datos más “flexible y eficiente”, lo cual es cierto. Dice “Cuando se les utiliza bien, estas técnicas producen programas más cortos y más fáciles de comprender y mantener”. Esto último es en general cierto con el paradigma de objetos. El punto clave es el “buen uso”. Después habla del type safety sobre todo.

En el primer capítulo hace una reseña filosófica sobre el lenguaje, donde dice que el lenguaje C está pensado como un “lenguaje cercano a la máquina”, y los agregados que se hicieron en C++ son para hacer un “lenguaje cercano al problema a resolver”. Hace una reseña bastante interesante que quiero compartir:

“El lenguaje proporciona al programador un conjunto de herramientas conceptuales; si éstas resultan inadecuadas para una tarea, sencillamente se las ignorara. (…) No se puede garantizar el buen diseño y la ausencia de errores sólo por la presencia o ausencia de características específicas del lenguaje.”

Es rescatable esto último que dice Stroustrup, y sobre como la intención de C++ es acercar al programador al problema a resolver, esto es en realidad cierto no solo para C++ sino para el paradigma de objetos en general.

Continuo más adelante sobre el tema para no alargar innecesariamente el post.