¿La programación orientada a objetos ha cumplido sus promesas de reutilización de código superior?

No, realmente no. Si miras hacia atrás a las afirmaciones de cuando la orientación a objetos se estaba convirtiendo en la corriente principal, por ejemplo, el byte de agosto de 1986 que probablemente fue mi primera exposición a estas ideas, dos cosas se destacan. En primer lugar, se alegó que las clases arbitrarias escritas en un estilo orientado a objetos podrían reutilizarse. En segundo lugar, se afirmó que el mecanismo principal a través del cual sucedería la reutilización era la herencia. Ninguna de estas afirmaciones ha resistido la prueba del tiempo, y aunque probablemente tengamos más reutilización de software ahora que la que teníamos entonces, podría decirse que la orientación a los objetos es un obstáculo y no una ayuda para la reutilización que realmente tenemos.

En general, no es posible reutilizar código orientado a objetos que no fue diseñado explícitamente para ser reutilizado, porque los grupos de clases escritos para trabajar juntos generalmente tendrán dependencias circulares. Algunas personas le dirán que esto es una mala práctica, pero las mismas personas generalmente recomendarán técnicas de análisis que resultan en descomposiciones de problemas con este tipo de dependencias. Lo más trivial es que si toma relaciones similares a las de una base de datos y las representa en un lenguaje OO, resultan en dependencias bidireccionales que hacen que ambas clases dependan de la otra. Esto se puede evitar, por supuesto, mediante la inyección de dependencias y las técnicas de diseño del marco, pero eso requiere esfuerzo. El código OO típico no es reutilizable fuera de la aplicación para la que fue escrito y otros se derivan explícitamente de él.

Cuando vemos código que está explícitamente diseñado para ser reutilizable, el mecanismo a través del cual se reutiliza no es la herencia. Normalmente, si el código que se reutiliza es del todo complejo, define los requisitos del código que se reutiliza, por ejemplo, a través de interfaces o mecanismos menos formales, pero en realidad no proporciona ningún comportamiento diseñado para integrarse en subclases. Los lenguajes con mecanismos de herencia múltiple limpios como Eiffel o Scala pueden hacer que algunos comportamientos estén disponibles para las subclases, pero generalmente depende del código de reutilización en lugar del código reutilizado para proporcionar la mayor parte de la implementación detallada. Cuando observa estos mecanismos, el único elemento de orientación a objetos realmente en juego para promover la reutilización es el polimorfismo. Podría decirse que los beneficios del polimorfismo podrían realizarse en cualquier lenguaje con algunas abstracciones funcionales, incluso sin el mecanismo formal real. La herencia no ayuda a reutilizar mucho, y la encapsulación realmente se interpone en el camino,

La encapsulación hace que cada proyecto orientado a objetos sea su propio lenguaje de dominio privado. Al hacerlo, evita activamente la reutilización. Si pensamos en un ejemplo trivial, si creo un paquete de gráficos con las clases Edge y Vertex, y un algoritmo de primera búsqueda de profundidad y creas otro con clases de Arc y Node y un algoritmo de búsqueda de primera respiración, los dos algoritmos de búsqueda no se pueden volver a utilizar. -utilizado con el otro paquete, porque tienen nombres de clase (y función y variable) incrustados en ellos. En lenguajes puramente tipados, tal vez podría salirse con la suya creando algunas clases de contenedor, pero incluso eso es un ejercicio no trivial. El problema clave aquí es que la encapsulación alienta activamente a los desarrolladores a crear abstracciones muy especializadas que solo permiten la aplicación de funcionalidades muy especializadas. Esto evita usos indebidos que rompen invariantes, pero también evita usos inesperados que son válidos.

Los sistemas que se basan en abstracciones menos especializadas y muy potentes fomentan la reutilización mejor. Los lenguajes funcionales nos permiten escribir funciones que operan sobre un dominio general de funciones y valores. SQL nos permite escribir consultas que manipular valores de datos arbitrarios. En ambos casos, las poderosas abstracciones generales nos permiten reutilizar el código donde las abstracciones encapsuladas altamente especializadas no lo harían.