De Simula y Smalltalk a las clases y prototipos modernos, comprende objetos, mensajes, encapsulación, polimorfismo y límites de la herencia.
La programación orientada a objetos (POO) es hoy tan familiar que resulta fácil olvidar su evolución histórica. Clases, objetos, métodos, herencia, interfaces y polimorfismo no aparecieron juntos ni fueron concebidos como una receta universal.
La orientación a objetos nació de una pregunta práctica: ¿cómo representar entidades que poseen estado, comportamiento e interacciones con otras entidades? De Simula a Smalltalk y después C++, Java, Python y JavaScript, la respuesta cambió profundamente.
Los lenguajes de alto nivel de los años cincuenta y sesenta aportaron funciones, procedimientos, estructuras de datos y módulos. A medida que los sistemas crecían, modificar datos manipulados por funciones dispersas se volvía costoso. La simulación proporcionó una de las respuestas más influyentes.
En los años sesenta, Ole-Johan Dahl y Kristen Nygaard desarrollaron lenguajes de simulación. Con Simula 67 introdujeron mecanismos fundamentales: clases, objetos, herencia y métodos virtuales. Una clase describe una categoría; un objeto representa una instancia concreta.
En el modelo clásico, una clase define estructura y comportamientos comunes y un objeto es una instancia con estado propio. Esta distinción es central en C++, Java y C#, pero no universal: existen sistemas basados en prototipos.
A finales de los sesenta y comienzos de los setenta, Alan Kay desarrolló otra visión, explicada en nuestra biografía de Alan Kay: lo esencial eran objetos autónomos que intercambian mensajes, no las jerarquías de clases.
En Xerox PARC, Alan Kay, Dan Ingalls, Adele Goldberg y otros desarrollaron Smalltalk. Números, colecciones y clases participan en el modelo de objetos y la interacción se centra en mensajes. Su entorno interactivo influyó profundamente en la informática personal y los IDE.
Un objeto suele combinar estado, comportamiento e identidad. Dos cuentas pueden tener el mismo saldo sin ser la misma cuenta. Esta identidad es útil en ciertos dominios; en otros, valores inmutables y funciones son más apropiados. La POO no es una obligación universal.
La encapsulación agrupa estado y operaciones y limita el acceso a detalles internos. Su objetivo es reducir dependencias y permitir que una abstracción cambie sin romper a sus usuarios.
La abstracción muestra lo que un componente sabe hacer sin exponer su implementación. La POO no inventó este principio, pero popularizó una forma centrada en entidades que combinan estado y comportamiento.
La herencia permite adquirir y especializar características de otra clase. Puede factorizar código, pero también crea acoplamiento y jerarquías rígidas. Por ello se considera hoy una herramienta entre otras.
El polimorfismo permite trabajar con distintos objetos mediante un comportamiento común. Puede basarse en herencia, interfaces, protocolos, duck typing o mecanismos genéricos. La idea esencial es programar contra un contrato y no contra una implementación concreta.
A partir de 1979, Bjarne Stroustrup combinó ideas de Simula con la eficiencia de C. El proyecto se convirtió en C++, que difundió masivamente la POO industrial sin abandonar otros paradigmas.
Objective-C, creado por Brad Cox y Tom Love, siguió otra vía: una capa dinámica sobre C inspirada en los mensajes de Smalltalk. Fue importante en NeXT y Apple antes de Swift.
Durante los años noventa, interfaces gráficas, análisis orientado a objetos, patrones de diseño y UML impulsaron la POO. Llegó a presentarse como una manera general de diseñar cualquier sistema, lo que produjo avances duraderos y algunos excesos.
Java apareció en 1995 con clases, recolección de basura e interfaces. Nuestra historia de Java y la biografía de James Gosling detallan esta evolución.
C# adoptó después ideas familiares en .NET y evolucionó con genéricos, lambdas, LINQ, records y pattern matching. Incluso los lenguajes asociados a la POO se volvieron multiparadigma.
Python admite clases y polimorfismo sin imponerlas en todo el código. El duck typing pone el foco en los comportamientos disponibles.
JavaScript, creado por Brendan Eich, se basa históricamente en prototipos. Su sintaxis class moderna sigue apoyándose en ese mecanismo.
Con la experiencia se difundió la recomendación preferir la composición a la herencia. La composición suele reducir el acoplamiento y facilitar el reemplazo de componentes. No elimina la herencia, pero evita convertir toda reutilización en un árbol de clases.
Las interfaces separan lo que un componente necesita de la implementación concreta. Esta idea sustenta la inyección de dependencias y varios principios SOLID.
SOLID es un conjunto de heurísticas, no leyes. Aplicarlo mecánicamente puede multiplicar clases, interfaces y capas sin beneficio. Una abstracción solo es útil cuando representa una frontera real de responsabilidad o variación.
En 1994, Design Patterns popularizó patrones como Factory, Observer, Strategy, Decorator y Adapter. Su principal valor es proporcionar vocabulario compartido, no recetas obligatorias.
UML unificó varias técnicas de modelado y sus diagramas de clases se asociaron estrechamente a la POO. Patterns y diagramas ayudan a razonar, pero no sustituyen un diseño adaptado al problema.
Encapsulación, interfaces e inyección de dependencias pueden mejorar la testabilidad mediante fakes, stubs o mocks. Pero fragmentar una arquitectura solo para facilitar mocks puede empeorarla. Más abstracciones no significan automáticamente mejor diseño.
Las limitaciones de la POO se hicieron visibles: jerarquías profundas, estado mutable compartido, objetos muy interconectados y arquitecturas «enterprise» cargadas de capas y factories.
La programación funcional volvió a poner en primer plano funciones puras y datos inmutables. Hoy Java, C#, C++, Python y JavaScript combinan enfoques. La oposición «objetos contra funcional» resulta cada vez menos útil.
GUI y juegos siguen adaptándose bien a entidades con estado e identidad, aunque los motores modernos también usan Entity Component System (ECS) para favorecer composición y datos separados.
En sistemas distribuidos, el modelo actor organiza entidades que reciben mensajes y mantienen estado. No es POO clásica, pero recuerda la importancia que Alan Kay daba a mensajes y aislamiento.
Tras décadas de experiencia, encapsulación, polimorfismo, composición, identidad y estado siguen siendo ideas duraderas. En cambio, la gran jerarquía de clases ha perdido influencia.
Smalltalk, C++, Java, Python y JavaScript muestran que la POO se entiende mejor como una familia de modelos de programación que como una lista absoluta de requisitos.
Una enorme cantidad de software y frameworks utiliza clases y objetos. Comprender encapsulación, responsabilidades, contratos y polimorfismo sigue siendo útil. La madurez consiste menos en «hacer objetos en todas partes» que en elegir la representación adecuada para cada problema.
La POO nace progresivamente con Simula, se transforma con Smalltalk y Alan Kay, se difunde industrialmente con C++ y se vuelve dominante con Java. Python y JavaScript muestran modelos más dinámicos y multiparadigma.
La experiencia corrigió excesos: la herencia ya no es la respuesta natural a toda reutilización, mientras composición, interfaces, inmutabilidad y funciones ganaron importancia.
La lección duradera no es «todo debe ser una clase», sino agrupar responsabilidades coherentes, ocultar detalles innecesarios y permitir que los componentes colaboren sin depender demasiado de sus implementaciones internas.
Es una familia de enfoques que organiza el software alrededor de objetos con estado, identidad y comportamiento que colaboran mediante métodos, mensajes o interfaces.
No existe un único inventor. Dahl y Nygaard introdujeron mecanismos fundacionales en Simula; Alan Kay y Smalltalk desarrollaron después una visión centrada en mensajes.
Una clase describe estructura y comportamiento comunes; un objeto es una instancia particular con estado propio. Los sistemas de prototipos funcionan de otra manera.
Encapsulación, abstracción, herencia y polimorfismo; en la práctica moderna también composición, interfaces y gestión de dependencias.
No. Muchos sistemas prefieren composición o interfaces.
Sí, pero históricamente mediante prototipos. La sintaxis class moderna sigue apoyándose en ellos.
Sí, pero es multiparadigma y no obliga a organizar todo en clases.
No. Sigue muy utilizada, aunque ya no se considera una solución universal.
A menudo sí, porque reduce acoplamiento. La herencia sigue siendo pertinente cuando existe una verdadera relación de especialización.
Porque encapsulación, responsabilidades, contratos y polimorfismo siguen ayudando a controlar la complejidad en arquitecturas multiparadigma.
Colección
10 / 26
Cómo Bjarne Stroustrup hizo evolucionar C with Classes hacia C++, conciliando abstracción, compatibilidad y control de recursos.
Cómo Brendan Eich creó el primer JavaScript en Netscape y participó en su transformación en el lenguaje estandarizado de la Web.
Cómo James Gosling y el equipo Green de Sun diseñaron Java: de Oak y las máquinas virtuales a la portabilidad y el legado del lenguaje.