Es hora de alejarse de la programación orientada a objetos
OOP es considerado el diamante más grande de la corona de la informática. La mejor forma de organizar tu código. La solución a todos los problemas. La única forma segura de escribir nuestros programas. El Dios de la programación nos envió desde arriba ... Solo aquí el programador de programación orientada a objetos se ve obligado a rastrear un montón de todo tipo de abstracciones, realizar un seguimiento de todos los objetos compartidos, recordar toneladas de "patrones de programación" y gastar su tiempo y energía en todo esto en lugar de resolver el problema en sí.
Muchos han criticado a la programación orientada a objetos durante mucho tiempo, y hay muchos programadores muy respetados entre esos críticos. E incluso Alan Kay , ¡el inventor de OOP está en sus filas!
El objetivo principal de cualquier desarrollador es escribir código confiable. Si el código tiene errores y no funciona como se esperaba, nada más importa. ¿Cuál es la mejor manera de escribir código confiable? Mantenga el código simple. La simplicidad es lo opuesto a la complejidad . De ello se deduce que el objetivo principal del desarrollador es reducir la complejidad del código.
Descargo de responsabilidad:
no soy un fan de la programación orientada a objetos, por lo que no es de extrañar que este artículo parezca sesgado para muchos. Sin embargo, daré argumentos en defensa de mi posición.
También entiendo muy bien que la crítica a la programación orientada a objetos es muy dolorosa para muchos. Muchos lectores se sentirán ofendidos personalmente. Sin embargo, tengo la intención de declarar lo que creo que es correcto. Porque mi objetivo no es ofender, sino señalar los problemas que tiene OOP. No estoy criticando
la OOP de Alan Kay . Generalmente es un genio. Personalmente, desearía que la programación orientada a objetos fuera exactamente lo que pretendía Alan Kay. Lo que critico es la programación orientada a objetos en una implementación de C # o Java.
El problema es que OOP se ha considerado durante mucho tiempo el estándar para organizar el código de software. Y mucha gente piensa, incluidos aquellos que ocupan puestos importantes en la industria del software, que es por eso que otros enfoques de la programación ni siquiera se consideran en la mayoría de las empresas.
Tuve que superar muchas dificultades cuando escribí en idiomas OOP. Y siempre me he preguntado por qué surgieron estas dificultades. ¿Quizás no fui demasiado bueno? ¿Quizás necesitaba aprender un par de docenas de "patrones de programación" más? Al final, simplemente no me quedaban fuerzas para todo esto.
Este artículo le contará el viaje de una década que pasé de la programación orientada a objetos a la programación funcional. Desde entonces, no recuerdo ningún caso en el que me encontré con un proyecto para el que OOP sería más adecuado. Además, los proyectos en los que se utilizó OOP fracasaron bajo el peso de la complejidad del código; desde algún punto fue imposible mantenerlos y desarrollarlos más.
TLDR
"Los programas orientados a objetos son la alternativa a los programas adecuados".
Edsger W. Dijkstra, pionero de la informática
El objetivo de la programación orientada a objetos era uno: hacer frente a la complejidad del código de procedimiento. En otras palabras, OOP fue diseñado para mejorar la organización del código. Pero desde entonces no ha habido evidencia de que OOP sea mejor que la antigua programación procedimental.
La cruda verdad es que OOP no hizo lo único para lo que fue diseñado. Todo se veía genial en el papel: teníamos jerarquías estrictas de animales, perros, personas ... (Y, por supuesto, formas: rectángulos, cuadrados y círculos, ¡dónde podemos ir sin ellos!) Pero a medida que aumentaba la complejidad del código de la aplicación, la POO no ayudó a reducirla. , pero por el contrario aumentó, con toneladas de "patrones de programación" necesarios, lo que dificulta al programador realizar un seguimiento de dónde y cómo cambian los valores de las variables. La programación orientada a objetos hizo que muchos procedimientos de uso común, como la refactorización y las pruebas, fueran innecesariamente complejos.
Mucha gente no está de acuerdo conmigo, pero el hecho es que el diseño de POO en C # o Java no fue pensado científicamente, no fue el resultado de una investigación científica seria. A diferencia de la programación funcional, por ejemplo, en Haskell, donde el cálculo lambda es una base teórica sólida. OOP no se basa en nada de eso.
En proyectos pequeños, OOP funciona bastante bien. Pero, ¿qué pasa cuando el proyecto crece? OOP es una bomba de tiempo que inevitablemente explotará cuando el código del proyecto alcance cierto tamaño. Los proyectos comienzan a retrasarse, los plazos fallan, los desarrolladores se quedan sin energía y agregar nuevas funciones se vuelve casi imposible. Al final, las empresas se ven obligadas a marcar dicho código como "obsoleto" y obligan a los desarrolladores a reescribirlo.
OOP no encaja muy bien con la forma en que piensan nuestros cerebros. Estamos acostumbrados a centrarnos en la acción: dar un paseo, hablar con un amigo, comer pizza. Nuestro cerebro ha evolucionado hacia "hacer algo" y no hacia la construcción de una jerarquía compleja de objetos abstractos.
El código OOP no es determinista (a diferencia de la programación funcional): no podemos estar seguros de que con los mismos datos de entrada obtendremos el mismo resultado cada vez. Esto hace que sea muy difícil entender cómo funciona el programa. Aquí hay un ejemplo simple: compare 2 + 2 y calculator.Add (2, 2) . La última expresión, en teoría, siempre debería devolver 4, pero puede devolver 5, 3 o incluso 1004, porque las dependencias del objeto Calculator puede cambiar su comportamiento de las formas más impredecibles.