La Orientación a Objetos debe morir. #KillOO (y las diapositivas de mi charla)

La semana pasada, @psluaces y el @CPIICyL organizaron en Valladolid una serie de charlas cortas sobre los problemas, aún a día de hoy, relacionados con la Orientación a Objetos (OO).
Por alguna razón a Pablo le dio por invitarme y allí que fui, en compañía de otros destacados ponentes en el tema.
Para mi charla, recuperé bastante información y experiencias que fui acumulando desde hace muchos años en el tema. Más de una vez te he comentado por aquí mi época leyendo, e intentando aplicar, todo lo que había sobre diseño software, principalmente sobre patrones de diseño. Llevado a ello por el trabajo, lo que me dio para hacer una tesis doctoral sobre el tema. Tesis que hice y terminé íntegramente trabajando 100% en empresa, en desarrollo software, en modo Bodyshopping.
Te doy más detalles de la charla al final del post, pero antes déjame que te ponga en antecedentes de por qué a @psluaces y al @CPIICyL les dio por montar este evento…

¿Por qué ahora un evento sobre OO? Y por qué alguien se atreve a querer matar a la OO

Comentaba Pablo en el arranque del evento, y cito casi textual, que si escribir código sencillo y legible es tan esencial, entonces… ¿por qué hay una tendencia tan acusada de escribir código complicadísimo y auténticos castillos de jerarquías de clases, polimorfismos complejos, etc., que acaban siendo innecesarios?
Parece que todos coincidimos en que el “sobre diseño” es uno de los pecados capitales del software. Y parece que es una afección que tarda años en curarse, porque casi todos los novatos tienen a complicarse la vida sobremanera para resolver cualquier problema.
Jerarquías innecesarias, confusión de variables miembro con variables globales disfrazadas y una clara tendencia a “construir soluciones generales” (generalizar) son algunos de los “smells” que desprende la OOP.
¿Serán realmente problemas intrínsecos de OOP? ¿y si la orientación a objeto fuera también un problema en sí mismo? ¿Se aprendería mejor y más rápido si no nos formásemos directamente en orientación a objeto? ¿Cuáles son las alternativas?

Mi exposición del problema

Como eso de volver a hablar de OO tenía su toque “reto”, vintage, unido a ese toque de peligro que a la conferencia se le quiso dar, “los peligros” de la OO, junto a ese hashtag que se eligió, el #KillOO, juntando todo, a mí, mientras preparaba la presentación, lo de vintage + kill me traía a la cabeza constantemente a… Freddy Krueger, al que no dude en pedirle ayuda en la ambientación y narración de mis diapositivas.

 
Las diapositivas tiene poco texto, pero la ponencia se grabó, puedes verla aquí, no obstante te la resumo en unas líneas:
– Mi planteamiento inicial fue si el problema era de la OO o era nuestro, de nuestras carencias para facilitar su correcto aprendizaje y de nuestras posibles carencias en conocer realmente la OO.
Y dividí el anterior en tres puntos:
1 – El conocimiento de cómo hacer buenos diseños OO existe, desde hace muchos, pero muchos años. Si bien es cierto que es difícil de aprender y es bastan desconocido.
2 – Demasiadas veces no tenemos claro qué buscamos a la hora de diseñar, qué es un buen diseño, para qué, por qué, en qué mejora a un desarrollo software, etc. Así es difícil saber si el diseño que estamos haciendo es bueno o malo… ¿qué es bueno y qué es malo?
3 – La OO no viene sola. Si queremos hacer un buen diseño OO necesitamos de otras disciplinas que le den soporte (métricas, etc.) y, normalmente, estas no siempre están.

27 comentarios en “La Orientación a Objetos debe morir. #KillOO (y las diapositivas de mi charla)”

  1. Aparte de que el título es totalmente sensacionalista, las diapositivas (al menos) abordan un problema inexistente: que la programación orientada a objetos es mala (y debe morir).
    No, los malos somos nosotros, los ingenieros. La POO es sólo una herramienta, igual que la programación estructurada. ¿Cuántas veces habremos visto verdaderas burradas en programación estructurada? ¿Debe esta morir por ello? No, obviamente.
    Además, se aborda otro problema (este sí lo es, en mi opinión), el de la formación. ¿Debemos aprender directamente POO? Pues no. Hay que empezar por partes y lo primero que cualquier principiante debe aprender es a programar de forma estructurada. Luego, cuando ya sabe hacer medianamente bien, debe (si quiere) aprender POO, porque la POO también es programación estructurada.
    Y vuelvo sobre lo mismo porque odio estas charlas con frases lapidarias que nada tienen que ver con la realidad: la POO es una herramienta, y es responsabilidad del desarrollador aprender a usarla.

    1. No sé si me he perdido algo, o si hablas de las diapositivas de otro, porque si hablas de las mías… ¿en cual slide dice que la OO ES mala? Justamente acaban diciendo que quizá el problema es nuestro. Si eso mirate mejor el video de la ponencia…

      1. Es que “quizá” el problema sea nuestro es lo sensacionalista. El problema es nuestro. El simple título de la charla me ha hecho desistir de ir a verla.

  2. Bueno, no olvidemos que el desarrollo de software no es una ciencia real, ni tan siquiera algo que se pueda considerar ingeniería de verdad. Y aunque existen aspectos ralacionados con otras ramas como son la lógica matemática y por supuesto el sustrato sobre el que se ejecuta ( procesadores ), es básicamente un reino de taifas con un montón de tendencias, opiniones y preferencias individuales o comunitarias. Por lo tanto, afirmar categóricamente que la OO, la programación funcional y tantos otros aspectos deben morir o seguir viviendo no es más que una opinión de un individuo o grupo y muchas veces una cuestión de preferencias, circunstancias e incluso de modas.

    1. Ciencia “de verdad” no es porque la ingeniería del software es un proceso creativo. Pero ingeniería de verdad sí es. Basta con ir a la definición de ingeniería: conjunto de conocimientos y técnicas científicas aplicadas para la resolución de problemas de las actividades de la sociedad. Ahí casa a la perfección.

      1. Bueno, sería abrir debate fuera de este hilo… Precisamente mi afirmación anterior se basa en que es posible escribir un mismo programa de múltiples maneras y varias de ellas sin necesidad de recurrir a técnicas realmente científicas. Un cocinero trabaja con herramientas, alimentos, condimentos y sigue o inventa una nueva receta, no por ello hablamos de ingeniería culinaria, aunque parte de su trabajo esta constreñido también por las leyes de la física ( y la química ).
        P.D.: Tengo formación científica (grado licenciatura) me encanta escribir software. >20 años en la industria, comenzando con assembler, pasando por varios lenguajes y ‘enamorado’ del C++. 😉

  3. Hola Javier. Siempre es un gusto leer tus publicaciones. Quisiera saber de tu opinión cual es uno de los mejores libros para empezar a entender mejor la programación orientada a objetos.
    Te agradezco de antemano.
    Saludos

  4. Hola, me pregunto si tienes en mente alguna alternativa mejor que la POO, me estoy iniciando en el desarrollo de software, y realmente encuentro la POO mas facil de entender ( a la hora de mirar un codigo ajeno) que la estructurada.

  5. Gracias Javier por tu post, presentación y vídeo.
    Me gustó que trataras es tema de los patrones y métricas y el supuesto efecto encontrado «más patrones -> peores métricas». Planteas además calidad de software -> mantenibilidad, y agregaría adaptabilidad, que aunque parezca obvio es bueno explicitarlo.
    Lo otro que me llevo y en cierta forma me preocupa como docente/consultor es el problema que planteas claramente de que la información de cómo hacer buenos diseños existe pero no llega, que es desconocida. Ni hablar ahora con la proliferación de cursos que prometen hacerte desarrollador en 15 días.
    Y uniéndolo con el último punto que planteas, que la OO no viene sola, me lleva a pensar que la división «legada» de la enseñanza del software que quedó como colgada, aislada de los otros elementos esenciales de hoy en día (testing, refactoring, CV, CI, etc). No hay (al menos en la enseñanza tradicional de software) elementos integradores, como el «glue code» que los una y que les de coherencia dentro de un todo, valor.
    ¿Qué podemos hacer al respecto? ¿Cuál es tu opinión?
    ¿Y qué hacer con los equipos actuales responsables de mantener ese código «walking dead» y que lo siguen produciendo? ¿las empresas y organismos invierten en buscar soluciones a este problema?
    Abrazo! fue un placer finalmente conocerte en persona en el Ágiles 2014 en Medellín.

    1. Gracias Pablo.
      Ha habido iniciativas para intentar resolver el problema del «conocimiento», pero o no eran buenas o tampoco son muy conocidas. Por ejemplo el SWEBOK, etc.
      De los walking dead, queda, queda incluso que concienciemos de su existencia…
      Saludos!

  6. Hola Javier.
    Me ha gustado la presentación. ¿Sabes algo de atomic design? Seguro que hay soluciones o reflexiones del diseño atomic que se pueden adaptar para mejorar los procesos/sistemas orientados a objetos. Igualmente a la inversa.
    Un saludo! 🙂

  7. Buenas,
    Yo estuve en en la charla y me parecio muy buena, pero me supo a poco. Me parecio que las 2h se quedaron muy cortas. Pero gracias por ofrecernos tus conocimientos.
    Lo unico que salí un poco desilusionado, cuando Jose Daniel dijo que empezar programando con java como primer lenguaje, estaba dañando el cerebro de generaciones. Yo soy uno de esos casos, estoy en mi 4º año de carrera y practicamente solo he usado java, del que considero que apenas se lo basico.
    A ver si saco un poco de tiempo para volver a ver la charla y apuntar las dudas que no se pudieron resolver, para preguntartelas.
    Un saludo

    1. En mi opinión, lee lo siguiente, marcará una diferencia enorme y te abrirá muchísimas oportunidades:
      === Windows via C/C++ ===
      * Chapter 4: processes.
      * Chapter 5: Jobs (optional)
      * Chapter 6: Thread basics
      * Chapter 7: Thread scheduling
      * Chapter 8: Thread sync in user mode
      * Chapter 9: Thread sync in Kernel mode
      * Chapter 13: Windows memory architecture
      * Chapter 14: Exploring virtual mem
      * Chapter 15: using vmem
      * Chapter 16: a thread’s stack
      * Chapter 18: Heaps
      * Chapter 19: DLL basics
      === Windows Internals Part 1 ===
      Only for further reading, more advanced:
      * Read Chapter 1 – Concepts and Tools
      * Read Chapter 5 – Processes and Threads
      Y después: Linux Systems Programming para tener la misma visión sobre sistemas Linux.
      Sin saber eso bien (que además complementa todo lo que ya has aprendido durante la carrera, claro, y te ayudará a sacarle partido) siempre andarás perdido. Manejas bien la diferencia entre Heap y Stack, por ejemplo? Todo esto ayudará.
      Por supuesto, aprende a dar una buena explicación de cómo funciona el garbage collector de Java. ¿Lo sabes? ¿Es generacional? ¿Por qué? Todas estas cosas son las diferencias entre intentar hacerse experto o no saber por dónde te da el aire. 🙂

      1. Gracias por la recomendacion, lo tendre muy en cuenta.
        A ver si acabo ya y puedo dedicarme a estudiar los temas que me interesan, o que almenos son mas necesarios, ya que muchas asignaturas de la carrera no las encuentro utilidad de momento. Y al final son horas que te quitan y no puedes dedicar a estudiar lo que si te interesa.
        De las preguntas que me planteas, son conceptos que me suenan, pero no se definir muy bien. El recolector de basura, esa cosa de java que se preocupa de liberar memoria, eliminando objetos que han perdido referencia. Poco mas, lo poco que he oido en la carrera. He oido mas veces lo de, tu crea objetos que java ya se encarga de gestionar y liberar memoria con esto. Tu por la memori no te preocupes. Y asi me va.
        Son un monton de cosas que no te enseñan bien en la carrera, y otro monton que ni te enseñan, y ahora toca apañarse cada uno por su cuenta, y volver a empezar de 0, cosa que ya es dificil si has afianzado ciertos conocimientos.
        Por cierto, me acabo de dar cuenta por otro comentario, que eres el organizador de la charla, y que estubiste el pasado miercoles dando una clase de gestion de proyectos, para el tema del control de versiones. La verdad que yo tenia que haber estado en esa clase ya que estoy cursando la asignatura, pero no sabia que ese dia venia alguien a explicarnos el tema de control de versiones. Y como me coincidia con otra asignatura, pues no fui. Una lastima, porque es un tema que me interesa.
        Creo que para febrero hay una charla/taller de plasticscm, a ver si este año puedi ir, ya que el año pasado me apunte, y no pude asistir. Tantos examenes,trabajos y demas me quitan el tiempo de todo jajaja.
        Un saludo.

  8. El problema no es la OO en sí, sino esa curva de aprendizaje tan plana, cuya causa es a su vez una deficiente formación. Así que de lo que estamos hablando es de un problema de formación. No creo que haya que «matar» a la OO. Además, intuyo que la solución más adecuada no pasaría por volver a programar código espagueti en ensamblador.
    Además, hay un hecho que no deberíamos perder de vista: la informática es una ingeniería. Sí, lo siento, Manuel. Por lo tanto, todo aquél que se acerque al desarrollo de SW debería hacerlo con la mentalidad de un ingeniero. Y desde ese punto de vista (y el de la experiencia) las cosas se ven mucho más claras.

  9. Interesante reflexion! Soy desarrollador de videojuegos y profesor, enseño programacion de videojuegos a alumnos con perfil artistico y que no han escrito una linea de codigo en su vida. Tras mi primer año como profesor, me di cuenta que todos los alumnos pueden entender con relativa facilidad la programacion estructurada pero les cuesta horrores entender la POO; por ese motivo cree raylib, una libreria puramente en C para aprender y crear videojuegos. Llevo año y medio utilizando la libreria con mis alumnos y casi todos, en apenas 40h de clase son capaces de programar un Pong desde cero… y entenderlo! Tras muchos años desarrollando videojuegos con POO, ahora con C tengo la sensacion de tener mayor control sobre mi programa e incluso creo q el codigo es mas claro y mejor estructurado. Resumiendo, la POO esta genial pero entender bien la programacion estructurada y haber trabajado con ella creo que es esencial antes de saltar a la POO.

  10. Cuando elegí el título y comencé a organizar el evento, quería ponerme en la difícil situación de dudar de algo que daba por sentado y luego reunir a un grupo de expertos que me ayudara a encontrar respuestas.
    Incluso en tecnología hay gente con la mente tan cerrada que no quiere escuchar a quien pone en duda sus creencias. El lleno completo del evento en unas pocas horas me hace pensar que afortunadamente quienes piensan así son minoría.
    == Planteamiento de la charla ==
    Por supuesto no creo que la OOP deba desaparecer. Por supuesto creo que si todos supiéramos mucha más OOP tendríamos menos problemas. Pero lo que busco es una solución muy práctica al problema sin enredarme en soluciones ideales.
    Más del 90% de los desarrolladores de software no se leen ni un libro al año. Ni uno. Partiendo de esa base es muy complicado conseguir súper expertos en OOP.
    Por otro lado para mí hay dos principios fundamentales al construir software: comunicación y simplicidad. Comunicación con el resto de los miembros del equipo (que todo el mundo lo entienda) y simplicidad, que van unidos. Considero menos importante la flexibilidad (hablo de cómo está construido el software, no de sus funcionalidades visibles por el usuario).
    Y unido a ello añado: si para resolver un problema sencillo el código es complicado, está mal. Da igual el paradigma de diseño, los patrones, las metodologías. Si lo simple se hace complejo, en mi opinión, está mal.
    == Principio fundamental ==
    Parto de la base de que escribir código bien es complicadísimo.
    También de que conseguir que software grande (>500K SLOC) sea simple y que comunique es también algo muy difícil de conseguir.
    Lo que busco es simplificarnos la vida para poder lograr ese objetivo.
    == La OOP nos lleva a hacer código complicado ==
    Ya sea porque no sepamos bien sus principios, porque falten horas de experiencia, o por la razón que sea, la mayoría de las veces que tratamos de aplicar “bien” los principios de OOP acabamos con código demasiado complicado para nada. Frustrados y con código malo.
    La mayoría de las veces que he usado la herencia creo que podría haberla evitado. Muchas veces cuando se usan “miembros” en una clase se están disfrazando variables globales mal utilizadas que podrían sustituirse por pasarse parámetros entre los métodos. Y hay un largo etcétera más.
    == ¿Por qué intentamos hacerlo así de difícil? ==
    En mi opinión, nos complicamos la vida intentando “emular” buen código OOP y creemos que hacer abstracciones, polimorfismos y jerarquías de herencia es “bueno” para que el código sea “flexible” pero nos olvidamos de que sea “simple”. (Esto dependerá de cada proyecto. En mi caso, simplicidad ante todo frente a cualquier otra opción de construcción).
    Mi planteamiento es que si en lugar de complicarnos la vida intentando hacer cosas para la que nos falta lectura y horas de vuelo, fuésemos más prácticos, el resultado sería mejor: código más sencillo y productos/proyectos mejores. Ingeniería es encontrar soluciones teniendo bien presentes las restricciones de recursos y tiempo, es decir, no llorar con lo que te falta sino encontrar una buena solución con lo que tienes.
    Por eso creo que en la mayoría de las circunstancias es mejor escribir funciones/métodos correctamente, y agruparlos en clases (no le llamo OOP porque sería pretencioso, sería como llamar a programar en C con clases OOP, ¿no?) y listo.
    Escribir funciones que tengan el nombre buen puesto, que sean cortas, que estén probadas, que tengan retornos claros y correctos. Escribir estructuras de datos adecuadas para que ese código “fluya” y sea sencillo y entendible y fácil de modificar y de mantener. No liarla con mantener estados que no son necesarios. Escribir código con efectos locales (cito a “Implementation Patterns”). Que para hacer una modificación no tengas que tener el sistema entero en la cabeza.
    Esto parece sencillo pero ya es en sí mismo muy complicado y al alcance de muy pocos.
    Creo, no obstante, que es un objetivo alcanzable si los miembros del equipo nos centramos en ello dejando de lado la complicación extra, casi inconseguible, de además que todo sea libre de pecado según alguna biblia de OOP que hemos leído a medias.
    En la charla Javier Garzás comentaba como incluso sistemas perfectamente diseñados y súper flexibles creados por un maestro experto en OOP acababan siendo incomprensibles excepto para quien lo hizo.
    Para mí eso no es deseable en mis proyectos.
    Por eso planteaba lo de que la programación orientada a objeto debe morir.
    ¿Quiere esto decir que no deberíamos aprender OOP? No. Ni mucho menos. El único conocimiento que no es aplicable y positivo es el que no se tiene. Hay que leer más, hay que aprender más sobre todo lo posible. Pero mientras tanto hay que seguir consiguiendo resultados, y para eso cuanto más simple sean los diseños, mejor.

    1. “Más del 90% de los desarrolladores de software no se leen ni un libro al año”. Yo no leo un libro al año. Lo que sí hago es leerme como más de 100 artículos sobre desarrollo de software al año (quizá más; no llevo la cuenta).
      Estoy de acuerdo en que si lo simple se hace complejo, está mal. Por ejemplo, en mi trabajo, se pelean por usar patrones. Ante cualquier problema, lo primero es que miran si hay un patrón que encaje. Si lo hace, lo aplican, independientemente de que se pueda hacer de otra forma más simple.
      La OOP no lleva a hacer código complicado. Es el ingeniero el que lo hace. La OOP es una herramienta más. Y no creo que sea más difícil de usar que otras.
      Lo de las variables miembro como globales es muy discutible.
      Respecto a la simplicidad del último punto: yo también soy de esos (vamos, de seguir el principio KISS) pero es que cuando empiezas a hacer software grande, la simplicidad desaparece. Y no porque no lo quieras, sino porque es imposible. Y es por eso que, a veces, todas esas jerarquías y abstracciones que parecen complicadas al principio se hacen con vistas a muy largo plazo, para que cuando el software sea realmente grande, la simplicidad esté ahí.

      1. Tocas otro de los puntos clave: complejidad para «cuando cambie», que para mi es otro de los desastres. Claro que el código grande puede ser simple, si se evitan todas estas complicaciones innecesarias.

    2. Sergio Antonio Espósito Pérez

      Suscribo totalmente tus planteamientos.
      Yo creo que quienes enseñan POO, y específicamente patrones de diseño, no hacen suficiente énfasis en que tan importante como aprender el patrón es identificar en cuales situaciones aplicarlo. Intentar aplicar un patrón de diseño de manera forzada lo que produce es código complicado y muy seguramente disfuncional, pero la gente que está aprendiendo POO suele quedarse con la fijación de «tengo que aplicar patrones» y termina aplicándolos mal.
      Saludos

  11. Yo creo que el problema viene al 99% por el déficit de conocimiento de los ingenieros y las personas que realizan el diseño y la programación de aplicaciones utilizando la programación orientada a objetos.
    Mientras más tiempo pasa, más experiencia tengo y más código veo…más complicada y difícil me parece implementar con código orientado a objetos.
    Y luego también estoy totalmente de acuerdo con lo del sobrediseño y el pensar que hasta los problemas más simples tienen que estar planteados con complejas estructuras de clases, que si le sumas lo comentado anteriormente del poco conocimiento en general que existe sobre el tema, el resultado puede ser una bomba de relojería en forma de código que tarde o temprano explotará.
    La ponencia muy buena.

  12. Yo me he llevado un chasco.
    Pensaba que ibas a hablar de otras formas o paradigmas de hacer las cosas, como lenguajes funcionales (Erlang), lenguajes híbridos (Maude) o desarrollo dirigido por modelos.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba