Introducción
La Programación Orientada a Objetos (POO) ha sido, durante décadas, uno de los paradigmas dominantes en el desarrollo de software. Lenguajes como Java, C++, C# y Python han adoptado este modelo como base estructural, enseñándose ampliamente en universidades y utilizándose en sistemas empresariales a gran escala.
Sin embargo, en los últimos años ha surgido un debate importante: ¿la forma en que se usa hoy la POO refleja realmente la visión original de sus creadores? En particular, se ha cuestionado el uso excesivo de herencia, jerarquías complejas y diseños rígidos, frente a una interpretación más cercana a sistemas de objetos autónomos que colaboran entre sí, similar a “células” independientes.
Este análisis explora el origen de la POO, su evolución, las malas prácticas actuales y si realmente nos hemos desviado de su intención original.
Desarrollo
1. Origen de la POO: la visión original
La POO nace en los años 60 y 70 con el lenguaje Simula, pero es en Smalltalk donde alcanza su forma más pura. Su creador, Alan Kay, ha sido muy claro en varias entrevistas:
“La gran idea es message passing, no clases ni herencia.”
Esto es clave. La POO originalmente se basaba en:
- Objetos autónomos
- Comunicación mediante mensajes
- Encapsulación fuerte
- Comportamiento antes que estructura
En este sentido, los objetos eran más parecidos a agentes independientes, casi como células biológicas que:
- Tienen responsabilidad propia
- Interactúan mediante mensajes
- No dependen fuertemente de jerarquías
Esto encaja directamente con lo que mencionas: objetos como “células” que hacen una sola cosa bien.
2. La desviación moderna: la obsesión con la herencia
Con la popularización de lenguajes como C++ y Java, la POO se reinterpretó de forma distinta. Se priorizaron conceptos como:
- Herencia profunda
- Jerarquías complejas
- Reutilización mediante subclases
- Modelado del mundo real con árboles de clases
Esto llevó a prácticas como:
Animal
├── Mamífero
│ ├── Perro
│ │ ├── Chihuahua
│ │ └── PastorAleman
Problemas de este enfoque:
- Alta rigidez (cambiar una clase base rompe todo)
- Acoplamiento fuerte
- Dificultad para mantener
- Violación del principio de composición sobre herencia
Muchos sistemas empresariales terminaron siendo difíciles de evolucionar, precisamente por estas decisiones.
3. La reinterpretación moderna: composición sobre herencia
En respuesta a estos problemas, surgieron principios como:
- “Favor composition over inheritance”
- Principios SOLID (especialmente el de responsabilidad única)
- Arquitecturas desacopladas
Aquí es donde aparece la idea que mencionas:
Objetos como “células” que hacen una sola cosa
Esto implica:
- Clases pequeñas y enfocadas
- Bajo acoplamiento
- Alta cohesión
- Comunicación mediante interfaces
Ejemplo moderno:
UsuarioService
├── ValidadorEmail
├── RepositorioUsuario
├── EnviadorNotificaciones
Cada componente:
- Hace una sola cosa
- Es intercambiable
- Colabora con otros
Esto es mucho más cercano a la visión original de Alan Kay.
4. POO vs Programación Funcional (aclaración importante)
Es importante no confundir esta evolución con programación funcional.
La programación funcional:
- Evita estado mutable
- Usa funciones puras
- Se basa en composición de funciones
Mientras que esta “nueva POO”:
- Sigue teniendo objetos
- Mantiene estado encapsulado
- Usa colaboración entre objetos
La similitud está en:
- Composición
- Simplicidad
- Evitar complejidad innecesaria
Pero siguen siendo paradigmas distintos.
5. El problema real: enseñanza vs práctica
Uno de los mayores problemas es cómo se enseña la POO:
Se enseña:
- Herencia como herramienta principal
- Diagramas UML complejos
- Modelado rígido del mundo real
Pero en la práctica moderna se usa:
- Composición
- Interfaces
- Inyección de dependencias
- Microservicios
Esto genera una desconexión entre lo académico y lo profesional.
6. POO como sistema de objetos que colaboran
Si volvemos a la esencia, la POO debería verse así:
- Objetos independientes
- Comunicación por mensajes
- Sistemas emergentes a partir de interacciones
Esto es más cercano a:
- Sistemas distribuidos
- Microservicios
- Arquitecturas basadas en eventos
Y sí: muy parecido a células en un organismo.
Cada “célula”:
- Tiene una función específica
- No conoce todo el sistema
- Coopera mediante señales (mensajes)
Conclusión
La forma en que se ha utilizado la Programación Orientada a Objetos durante décadas no siempre refleja su intención original.
El uso excesivo de herencia y jerarquías complejas representa una desviación significativa de la visión inicial, que estaba centrada en objetos autónomos que se comunican mediante mensajes.
La tendencia moderna —basada en composición, responsabilidad única y bajo acoplamiento— se alinea mucho más con esa visión original. En este sentido, la analogía de objetos como “células” que hacen una sola cosa no solo es válida, sino que representa una evolución hacia una POO más correcta.
No se trata de abandonar la POO, sino de reinterpretarla correctamente:
- Menos jerarquía
- Más composición
- Más colaboración
- Más simplicidad
En resumen:
La POO no está mal, pero muchas veces se ha aplicado mal.
Referencias
- Kay, Alan. The Early History of Smalltalk. ACM SIGPLAN Notices.
- Kay, Alan (entrevistas y conferencias): “OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.”
- Gamma, Erich et al. Design Patterns: Elements of Reusable Object-Oriented Software.
- Martin, Robert C. Clean Code y Clean Architecture.
- Bloch, Joshua. Effective Java (ítem: prefer composition over inheritance).
- Fowler, Martin. Patterns of Enterprise Application Architecture.
- Armstrong, Joe. Programming Erlang (crítica a la POO tradicional).
- Rich Hickey. Simple Made Easy (crítica indirecta a complejidad en paradigmas).
No hay comentarios.:
Publicar un comentario