Sobreorientación a Objetos

 

Ando últimamente un poco preocupado sobre un tema.

Según puedo comprobar en la realidad, el 90% de los programadores no sabe realmente de orientación a objetos. Sí, el 90 % de ellos a lo mejor han usado alguna vez, por ejemplo, un patrón observador: un ActionListener de java lo es y sólo por hacer un botón que haga algo, ya el 90% de los programadores lo han usado. Implementar uno en tu diseño/programa también. El patrón observador es sencillo y bastantes programadores lo han implementado alguna vez en sus proyectos, incluso muchas veces.

Pero ¿qué pasa con el resto de patrones? ¿Quien conoce el patrón estado, o el patrón comando, o cualquier otro de esos que hay por ahí menos conocidos? ¿Y cuántos lo han implementado alguna vez para algo? ¿y cuántos de esos poco lo han hecho correctamente?. Ya estamos llegando al otro 10 % de programadores, los que realmente entienden la programación orientada a objetos, los que realmente entienden la utilidad de esos patrones y los que realmente son capaces de usarlos y sacarles partido en proyectos reales, los que después de pasarse ocho horas programando en el trabajo, llegan a casa, encienden el ordenador y se ponen a programar lo que les gusta.

Pero ahí está el problema. Para ese 10% de programadores el código que han hecho es entendible, fácilmente modificable y adaptable y una pequeña maravilla de la técnica. ¿Y qué pasa cuando tiene que mantener ese código un programador del otro 90%, que suele ser el 90% de las veces?. Pues que se encuentran un código que no entienden, en el que no saben qué buscar ni donde, en el que no tienen ni idea de qué tocar y en el que toquen lo que toquen, fastidian algo.

Y esa es mi preocupación. ¿Hasta qué punto es entonces bueno usar la orientación a objetos?. La situación real es que cuando necesitas modificar/adaptar un sofware ya hecho con intención de reutilizarlo en otro proyecto, depurar algún bug, añadirle algo de funcionalidad, etc, el programador original ya está en otras cosas y sólo tienes un 10% de posibilidades de que la persona a la que pongas a hacerlo pueda hacerlo.

Al final, el código hecho por ese 90% de programadores que hace un uso básico de la orientación a objetos es realmente el código que resulta mantenible, el código que cualquier programador puede entender y cualquier programador puede tocar con cierta seguridad, aunque no sea todo lo elegante ni correcto que debiera ser.

Dicho de otra forma, muchos son capaces de tocar un texto en prosa para que diga otra cosa. Muy pocos son capaces de entender una poesía genial, modificarla para que diga otra cosa, y siga siendo genial.

En fin, cada vez soy más partidario de hacer código más "lineal", usando la orientación a objetos lo más simple posible y en los sitios que realmente se le saque un partido real. Si estás en un proyecto en el que todos los programadores son programadores de "élite", en el que todos ellos realmente viven la orientación a objetos y todos ellos de coeficiente intelectual alto, adelante, usa todos los patrones que quieras. Si estás en un proyecto normal con programadores normales (el 90% de las veces y el 90% de los programadores), piénsatelo dos veces antes de poner un patrón estado.

Esta entrada ha sido publicada en diseño, varios y etiquetada como , . Guarda el enlace permanente.

12 respuestas a Sobreorientación a Objetos

  1. Blaxter dijo:

    o pasas de ese 90% de proyectos. Las cosas se hacen bien o no se hacen. O ese es mi lema (un poco idealista, pero se intenta :P). La cuestión es que si de primeras ya te planteas hacer las cosas «mal», el resultado será pésimo.

    Aunque con los patrones hay que tener mucho cuidado, pues de primeras puedes estar tentado a utilizarlos en exceso, solo porque crees que quedan bien. Esto suele pasar al inicio, al menos a mi así me pasó. Lo importante es captar los conceptos de cada uno de ellos y cómo resuelven un problema común, para luego aplicarlo a los casos particulares, los cuales nunca son como los casos teóricos.

    Mi preferido, abstract factory, ahora vas y haces lo mismo sin usar el patrón. El código espagueti definitivo sería xD. El peor, singleton :P.

    Eso si, muchos de estos patrones suelen ser increíblemente más simple implementarlos en lenguajes de script (ruby, python, perl) que en lenguajes como Java donde muchas veces es peor el remedio (implementar el patrón) que la enfermedad (el problema a resolver).

  2. Chuidiang dijo:

    Hola:

    No puedes «pasar» de esos proyectos, puesto que la empresa tiene que hacerlos.

    Desde luego, entre usar o no usar un patrón hay un límite «real y técnico», que es usarlo para solucionar un problema real y no porque quede bonito. Sin embargo, hay otro limite no tan visible y que es el que comento, la capacidad de la gente que luego va a mantener el código. No digo hacer las cosas mal, sino más simples, aunque el código luego no sea tan reutilizable. El programa puede funcionar exactamente igual de bien con ambas soluciones.

    ¿Qué es mejor? ¿una solución perfecta pero compleja o una solución no tan buena, pero más simple?. Ten en cuenta que los patrones nacen en un 99% de la necesidad de hacer el código más reutilizable más adelante y si la gente no va a ser capaz de reutilizarlo por la complejidad, quizás no hemos conseguido nada.

    Se bueno.

  3. Yo me planteo esto cada vez que empiezo un proyecto, y adopte el uso de frameworks, para mantener una estructura, el codigo se hace mil veces mas entendible, por que es menor, y mas organizado.

    Es muy gracioso leer los nombres de los patrones en Castellano.

    @Blaxter: No me parece logico dividir a los patrones por mejores y peores, son soluciones a algo especifico y punto.

  4. Chuidiang dijo:

    uy, aprendí informática de forma autodidacta, con libros, antes que inglés. Para mi se dice «goto» y no «goutu», se dice «run» y no «ran», se dice «basic» y no «beisic» y, desde luego, es «debuguer» y no «dibaguer». No veas la desilusión que me llevé cuando me enteré que se decía «asci» y no «a ese ce dos». Rupestre que es uno 😉

    Se bueno.

  5. asantiago dijo:

    Hola chuidiang, de primeras muchas gracias por ayudarme con c++, xD. No tengo ni puta idea de c++ pero estoy aprendiendo rapidamente entre otros gracias a ti…

    En cuanto a la sobreorientacion a objetos estoy completamente de acuerdo contigo, soy programador de java actualmente y somos chapuceros de cojones, la mitad del codigo en jsp..argh… ,pero en mi anterior trabajo programaba con php, y el AP estaba flipado con los patrones de diseño,habia que implementarlos hasta para ir al cuarto de baño…De las dos opciones, la verdad no se cual es peor, para el codigo php tardabamos mas por las tonterias y despues al final la mayoria del esfuerzo era un desperdicio, ya que realmente luego no reutilizabamos tanto y por supuesto eso no eximia de errores, despues con las jsp si quieres aprovechar algo utilizamos el clasico (copy&paste), puagh… pero ciertamente se montan las aplicaciones (no muy grandes sobre 600 horas) como churros… en definitiva, un punto intermedio como siempre.

  6. Te encuentro razón en que el código elegante y lleno de patrones es dificil de mantener.

    Pero no entiendo que tiene que ver la orientación de objetos con el uso de patrones. Perfectamente en un equipo de trabajo cada persona puede hacer sus propias clases encapsuladas para luego utilizarlas o reutilzarlas con herencia, quizas algunas clases vengan con patrones o quizas otras no.

    Puntualmente ahí estoy utilizando orientación a objetos. Ahora el COMO ESTEN IMPLEMENTADAS cada clase es otro tema

    Quizas te referias a que solo el 10% utiliza patrones a la hora de programar con oop.

    Saludos

  7. Willie dijo:

    Creo que Pontt ha tocado un buen punto, y ese es el de la separacion
    de el disenno y la implementacion. Los `arquitectos’/disennadores
    deben conocer los patrones a profundidad (10% de tu equipo?), mas los
    programadores solo requieren un conocimiento relativamente superficial
    (el 90% restante). Por ejemplo, como bien has notado, cualquier
    programador puede usar el ActionListener, mas no cualquier programador
    pudo haber concebido el disenno de esa manera.

  8. Chuidiang dijo:

    Pensado así creo que tienes razón.

    El problema mencionado en el post es entonces consecuencia de otro problema más grave, pero habitual: no se hace diseño y se codifica sobre la marcha. El código marvilloso hecho por el que sabe, es inmantenible para los demás simplemente porque no hay un documento de diseño que diga cual es el esqueleto y filosofía de ese código.

    Me habeis dado un pequeño tema para reflexionar…..

    Se bueno.

  9. Pingback: Diario de Programación » Blog Archive » Buena acogida del redmine… quizás demasiada

  10. ruben dijo:

    En el post estas confundiendo los terminos «patron de diseño» con «orientacion a objetos».

    Hablas de patrones de diseño y los nombras como orientacion a objetos. Son cosas distintas.

  11. Chuidiang dijo:

    Hola Rubén:

    La orientación a objetos y los patrones no son lo mismo, pero están muy relacionados. Los patrones son las soluciones de diseño que han demostrado ser buenas. Puedes hacer un diseño orientado a objetos sin usar los patrones, pero posiblemente no es el mejor diseño (siempre hay excepciones). Por ello, en el artículo, aunque quizás no lo dejo muy claro, pretendo decir que el que sabe hacer un buen diseño orientado a objetos, suele conocer y aplicar patrones.

    Se bueno.

  12. Saludos,

    Antes de aplicar cualquier patron debemos de tener un concepto total de la aplicación.
    Tratar de dejar documentado el patron que se utilizara para que en futuros cambios no desvirtuar la idea del porque se uso dicho patron y no se contamine o dañe el código.
    Tambien debemos ver si es necesario o no un patron pq muchas veces añadimos complejidad sin necesidad.

Deja una respuesta

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

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.