El término programación orientada a objetos fue acuñado originalmente por Alan Kay. Kay fue miembro del equipo de PARC que fue pionero en la interfaz gráfica de usuario que ayudó a que Internet, los PC, las tablets y los smartphones fueran tan útiles, así como algunos de los lenguajes orientados a objetos con los que ahora implementamos.
Una vez que se elimina el desorden emocional que rodea a la programación orientada a objetos, ¿qué queda? ¿La programación orientada a objetos sigue siendo una herramienta eficaz de desarrollo de software o es simplemente una moda pasajera de programación obsoleta?
Esto es lo que dijo Alan Kay sobre la programación orientada a objetos:
"Para mí, la OOP significa solo mensajería, retención y protección local y ocultamiento del estado en el proceso, y vinculación extrema y tardía de todas las cosas".
Dividamos esta frase para entender la globalidad:
- “solo mensajería”: Significa que los objetos se comunican entre sí a través de mensajes. Un mensaje a un objeto es una solicitud de ejecución de un procedimiento y, por lo tanto, dará como resultado un cambio en el estado de uno o más objetos o devolverá un valor. Esto destaca que los objetos deben interactuar a través de interfaces claramente definidas, utilizando mensajes para solicitar acciones.
- “retención, protección y ocultación local del estado en el proceso”: Se refiere a la encapsulación y ocultación de información. La encapsulación es la agrupación de datos con los métodos que operan sobre esos datos, o la restricción del acceso directo a algunos de los componentes de un objeto. El ocultamiento de información es un principio en el que los detalles de implementación de una clase se mantienen ocultos a los usuarios. El objeto sólo revela operaciones que son seguras y relevantes para el usuario. Esto protege el estado interno del objeto y garantiza que el objeto se pueda utilizar sin necesidad de comprender la complejidad interna.
- “Enlace tardío extremo de todas las cosas” El enlace tardío significa que el código específico que se invocará se determina en tiempo de ejecución en lugar de en el tiempo de compilación. Esto permite un comportamiento del código más flexible y dinámico, donde objetos de diferentes tipos se pueden usar indistintamente si ofrecen la misma interfaz externa, incluso si implementan acciones de diferentes maneras internamente. La vinculación tardía describe un sistema que maximiza esta flexibilidad, permitiendo un modelo de componente muy dinámico y adaptable.
La descripción de Kay pone énfasis en la interacción entre componentes autónomos a través de interfaces bien definidas, manteniendo privados tus procesos internos y datos, y permitiendo un alto grado de flexibilidad y dinamismo en cómo y cuándo los componentes pueden interactuar entre sí. Estos principios pueden hacer que el software sea más modular, más fácil de mantener y más flexible.
Una cosa que Kay no mencionó fue la herencia, un concepto que ha preocupado a muchos programadores de programación orientada a objetos. Su declaración deja claro que no considera que la herencia sea un requisito para la programación orientada a objetos.
Si bien la subclasificación mejora la reutilización y el polimorfismo del código, también presenta algunas desventajas:
- Las subclases están estrechamente acopladas a sus clases principales.
- Las jerarquías de herencia pueden dificultar la comprensión y el seguimiento del código.
- Los cambios en una clase base pueden romper fácilmente tus subclases.
- Anular métodos en subclases puede generar confusión sobre qué instancia del método se llama.
- Las subclases a menudo dependen del conocimiento sobre los detalles de implementación de sus clases principales, lo que puede dificultar la encapsulación.
- Cambiar una superclase puede requerir cambios extensos en muchas subclases.
- Las subclases introducen estados y comportamientos adicionales que pueden complicar las pruebas.
Aunque a menudo se enfatiza en el entrenamiento de programación orientada a objetos, la herencia no es un atributo central de la programación orientada a objetos (sino más bien una característica de algunos lenguajes orientados a objetos, como Java) y se usa con demasiada frecuencia cuando la composición o la agregación son opciones de diseño más apropiadas.
El uso inadecuado o excesivo de la herencia puede dar lugar a diseños innecesariamente complejos que son menos flexibles y más difíciles de comprender y modificar.
¿Qué significa la programación orientada a objetos en tus proyectos?
En el diseño, desarrollo, implementación, operación y mantenimiento de software, la complejidad es un determinante principal del coste.
El software es inherentemente complejo. Cuanto más crece un sistema, o cuanto más se modifica, más complejo tiende a volverse.
Como se muestra en la tabla, la complejidad de la aplicación aumenta dramáticamente a medida que aumenta la cantidad de cosas que componen la aplicación y las conexiones entre ellas.
Una de las formas más efectivas de gestionar la complejidad del software es utilizar modelos de componentes que:
- Haga que los componentes de software individuales sean más fáciles de entender y cambiar.
- Aísla los componentes de software de cambios en otros componentes.
- Minimiza la posible interferencia entre equipos que trabajan en diferentes partes del sistema.
- Simplifica la entrega de componentes de software nuevos y actualizados.
Alan Kay y el equipo de PARC eligieron la programación orientada a objetos para el desarrollo de GUI por las mismas razones que la programación orientada a objetos tiene sentido hoy en día para el desarrollo de aplicaciones concurrentes y distribuidas. Los microservicios componibles que cumplen con la definición de programación orientada a objetos de Kay demuestran el valor de las ideas de Kay.
¿Por qué son importantes los conocimientos de programación orientada a objetos de Kay?
El problema fundamental es que crear software es complicado. El software responsivo, en red y distribuido que sea asequible de crear y mantener (y que funcione de manera confiable) puede ser algo muy complejo.
El problema se vuelve aún más difícil cuando uno o más equipos de personas deben coordinar sus esfuerzos para garantizar que todas las partes de la aplicación resultante funcionen juntas a la perfección.
También sería económicamente beneficioso si las aplicaciones resultantes fueran fáciles de probar y modificar e implementar continuamente, y no estaría de más si las aplicaciones fueran autoconfigurables y monitoreadas, tolerantes a fallas y escalables horizontalmente en respuesta a la carga.
Conclusión
¿La programación orientada a objetos sigue siendo una herramienta eficaz de desarrollo de software o es simplemente una moda pasajera de programación obsoleta? La respuesta es que la programación orientada a objetos no está obsoleta. Si algo es cierto es que la programación orientada a objetos es aún más importante en el mundo actual de la informática distribuida, donde los modelos eficaces de componentes y comunicaciones son cruciales.
Crear software distribuido, en red y con capacidad de respuesta, que sea asequible de crear y mantener, y que funcione de manera efectiva y confiable, puede ser algo complicado. Alan Kay ha demostrado, una y otra vez, que utilizar la programación orientada a objetos (de la manera que él y el equipo de PARC imaginaron) puede ayudarte a desarrollar software mejor.
Referencias: