OOP es un intento de solución.
La mejor manera de gestionar la complejidad es crear abstracciones. Si puedo convertir mis datos en colecciones útiles, con funciones reconocibles que operan en esas colecciones, puedo comenzar a pensar en las colecciones como "cosas" discretas. Esa es la base de las clases y los métodos. En ese sentido, la OOP diseñada adecuadamente puede ayudar a gestionar la complejidad.
En algún momento, alguien decidió que podíamos usar OOP para ayudar a resolver el problema de la reutilización de código. Quiero decir, ¿por qué reinventar la rueda? Si alguien más ha hecho gran parte del trabajo para resolver este problema, aproveche lo que ha hecho, agregue los ajustes que su proyecto particular requiere y ¡listo! Ha creado una aplicación potente y sofisticada con relativamente poco trabajo de su parte. Los programadores OO pueden ser programadores muy productivos.
El resultado final es que los programadores modernos de OO terminan siendo "aprendices de brujo", donde unen un montón de bibliotecas grandes y difíciles de manejar con unas pocas líneas de "pegamento" y obtienen algo que funciona. Sorta Un poco La mayor parte del tiempo ¿Hay posibles efectos secundarios al usar esta biblioteca con esa? Tal vez. Pero, ¿quién tiene tiempo para profundizar en el código contenido en esas bibliotecas? Especialmente cuando las bibliotecas están evolucionando. El resultado es que terminamos con aplicaciones hinchadas, donde un programador necesitaba un puñado de clases y métodos de esa biblioteca, pero la aplicación tiene que soportar el peso de TODAS las OTRAS cosas que no necesitaban.
El resultado final es que terminas con mucha más complejidad de la que necesitas.
Otro mecanismo para lidiar con la complejidad que desea separar la funcionalidad. Desea todas sus funciones de acceso a datos en un solo lugar. Desea toda la funcionalidad de su interfaz de usuario en un solo lugar. Desea todos sus controladores en un solo lugar. Entonces crea diferentes clases que administran diferentes partes de la funcionalidad. Hasta aquí todo bien. Y esto escala, hasta cierto punto; sus desarrolladores expertos en acceso a datos pueden escribir esas clases, su personal de interfaz de usuario puede escribir las clases de interfaz de usuario, etc. Todo está bien.
Hasta que tenga que mantener algo escrito por otra persona.
Sí, es bueno saber que todas las funciones de acceso a datos se encuentran aquí. ¿Pero qué los llama?
Este método está llamando a ese método en esa clase. Pero cuando miro la definición de clase, no hay ningún método con ese nombre. Oh, eso se hereda de otra cosa una o dos capas en la cadena de herencia. Espera un minuto; esa clase implementó una interfaz? ¿Cuántas clases diferentes implementan esa interfaz? ¿Y estamos usando un sistema complicado de tiempo de ejecución (te estoy mirando, Spring) para "conectar" instancias de clases en tiempo de ejecución? ¿Dónde se puede usar CUALQUIER clase que implemente esa interfaz?
Terminas con muchos métodos pequeños y discretos que hacen cosas precisas. Pero este lo llama, en otra clase. Lo cual llama a ese, en otra clase más. Lo cual llama a ese, en otra clase más. Que llama a ese, en una clase adicional. Que devuelve un resultado de un tipo particular. En el que tienes que llamar a un método para hacer una determinada cosa. Que devuelve un resultado de otro tipo. Etc.
Hay un término para esto: código de espagueti.
Terminas con un sistema muy complejo necesario solo para componer el código. Por lo tanto, IDEs como Visual Studio, Eclipse y NetBeans. Todos los cuales tienen una curva de aprendizaje significativa. De hecho, muchos de ellos pueden encapsular / agregar múltiples herramientas, desarrolladas por diferentes grupos, cada uno de los cuales tiene sus propias curvas de aprendizaje.
Esto es gestionar la complejidad?
El código de depuración es el doble de difícil que escribirlo. Buena suerte depurando algunas de estas cosas. Especialmente si está usando múltiples bibliotecas, "conectadas entre sí" en tiempo de ejecución usando algún tipo de sistema de inyección de dependencia.
En resumen: OOP proporciona lo que parece una herramienta prometedora para ayudar a gestionar la complejidad. La realidad es que el código resultante tiende a estar horriblemente hinchado (porque no puede extraer solo las piezas que necesita de todas esas bibliotecas vinculadas) y necesita herramientas sofisticadas solo para navegar por el código. Rápidamente se convierte en una pesadilla de mantenimiento.
En mi humilde opinión, es una pérdida neta; agrega más complejidad de la que elimina. Le permite hacer cosas que serían extremadamente difíciles, posiblemente incluso imposibles, sin él. Pero cualquier gran proyecto evoluciona rápidamente en un desastre imposible de mantener.
Si ya sabe cómo funciona y puede recordarlo, puede tener la oportunidad de mantenerlo.
Recuerde aplicar la Ley de Eagleson: cualquier código propio, que no haya visto en seis meses, bien podría ser escrito por otra persona.