Trampas de la programación orientada a objetos (2009) [pdf]

Artículo original ↗ Discusión en Hacker News ↗

La programación orientada a objetos se examina tanto como modelo conceptual como compensación de rendimiento, y muchos sostienen que su énfasis en la identidad, el estado mutable y la herencia suele añadir complejidad sin beneficios claros frente a diseños más simples orientados a los datos o funcionales. Los comentaristas contraponen la visión original de Alan Kay sobre los objetos, basada en el envío de mensajes, con la forma en que se practica hoy la POO dominante (p. ej., Java, C++), destacando problemas como grafos de objetos poco favorables a la caché, jerarquías de herencia frágiles y el uso excesivo de la idea de “todo es un objeto”. Un tema recurrente es que ningún paradigma basta por sí solo: los sistemas eficaces mezclan objetos, funciones y modelos relacionales o basados en conjuntos, usando la POO de forma selectiva donde el estado encapsulado y el comportamiento polimórfico realmente ayudan, como en partes del código de interfaz de usuario.

Qué es “realmente” la POO

  • Varios comentarios sostienen que la definición de Wikipedia de “datos + métodos juntos” es engañosa.
  • Una postura dice que la esencia es identidad más estado mutable: dos objetos pueden ser “el mismo” aunque difieran en sus campos.
  • Otra postura enfatiza envío de mensajes + despacho dinámico: distintos objetos responden de forma diferente al mismo mensaje; la mutabilidad y la identidad son comunes, pero no esenciales.
  • Ambas visiones coinciden en que la disposición de la memoria es incidental, no definitoria.

POO frente a otros paradigmas (identidad, conjuntos, relaciones)

  • Un tema recurrente: la POO fomenta la “identidad intencional” (inventas objetos/servicios y empujas datos/comportamiento hacia ellos), lo que puede inflar la complejidad del sistema.
  • En contraste, los enfoques relacionales/lógicos enfatizan la “identidad extensional” (las entidades se definen por valores/tuplas; la identidad emerge de los atributos).
  • Algunos señalan que muchos desarrolladores están tan inmersos en la POO que la ven como algo natural, y luego envuelven torpemente sistemas relacionales/funcionales/lógicos dentro de abstracciones orientadas a objetos.

Herencia, composición, interfaces

  • Fuerte crítica a la herencia de clases como herramienta principal de diseño; a menudo se prefieren la composición, las interfaces/traits/typeclasses y la delegación.
  • Otros defienden la herencia como un mecanismo potente y conveniente para la extensibilidad y la personalización de interfaces, especialmente cuando se restringe con cuidado (clases/métodos final, puntos de extensión claros).
  • Debate sobre si la delegación + genéricos igualan la expresividad y ergonomía de la herencia; hay acuerdo en que el mal uso de la herencia conduce fácilmente a diseños frágiles.

POO en GUIs frente a backends

  • Muchos consideran que la POO encaja bien con los toolkits tradicionales de GUI (widgets con estado y comportamiento, estructura jerárquica).
  • Los frameworks de UI modernos (React, Elm, Compose, SwiftUI) tienden hacia estilos declarativos/funcionales o reactivos, aunque los críticos argumentan que siguen dependiendo de estado oculto, al estilo POO, por debajo.
  • Discusión sobre los hooks de React: se sienten funcionales en la superficie, pero rompen reglas de la FP pura y dependen de semánticas poco habituales.

Rendimiento y diseño orientado a los datos

  • Se considera que las diapositivas muestran que los grafos de objetos centrados en la POO perjudican la localidad de caché y el prefetching en comparación con disposiciones orientadas a los datos (por ejemplo, arrays/vectores).
  • Algunos generalizan: la modularidad y la abstracción a menudo implican una compensación con el rendimiento bruto; el diseño orientado a los datos contrarresta esto en código crítico para el rendimiento.

Pragmatismo y uso multiparadigma

  • Varios comentaristas abogan por una práctica multiparadigma: POO para algunas partes, FP/relacional/lógico para otras.
  • Las posiciones extremas (“todo es un objeto”, “todo es inmutable”) se ven como contraproducentes; el problema debería dictar el paradigma.