¿La Programación Orientada a Objetos mala para Drupal?
Después de un buen tiempo me animé a escribir sobre algún tema relacionado a lo que día a día hago, y que mejor comenzar haciéndolo desde un punto de vista medio extraño que deseo expresar, mi visión acerca de Drupal y los miles de intentos de querer adecuar ésta a una Programación Orientada a Objetos. Siempre me he preguntado por que los desarrallodares de PHP más aún de Drupal son más felices adecuando sus soluciones a la necesidades que tienen con la serie de Módulos que tan buenamente Drupal nos proporciona frente al hecho de ver a a desarrolladores acostumbrados muchos años a un desarrollo tradicional de POO (más si provienen de Java) adecuarse a un framework como lo es Drupal.
Yo estoy más que segura que muchos de ustedes no estarán deacuerdo conmigo pero es lo que he venido observando, e incluso me ha pasado a mí cuando intentaba armar un sistema para una compañia, el tema de POO siempre invadía mi mente de querer organizarlo todo como me habian enseñado en la Universidad donde tanto nos exigen en todo, la muy querida POO y mayormente usando Java O.O, pensamos en Java,comemos con Java y hasta soñamos con Java :D bueno también con .Net. También antes de meterme al tema quiero comenzar resaltando y que no olvidemos que "PHP es un Lenguaje Interpretado" y con base en la estrucutura a un grupo CGI y NO esta basado en un diseño Orientado a Objetosinicial; que ésta se esté moviendo a una estructura más Orientada a Objetos ya en PHP5 y el nuevo PHP6 es diferente.
Ahora vayamos a Drupal, Drupal no fue diseñando con esta lógica de clases, abstracción y polimorfismo admitámoslo, por que queremos forzar algo? Una de las cosas que me hizo sentir mejor a esta forma de pensar que tenia en la cabeza fue encontrar el post de Matt Butcher quién ha escrito buenos detalles relacionado al tema y que pueden ver aquí
Como Matt mismo señala con la frase "Las cosas fáciles ahora son más difíciles"; el problema no es que exista la POO no! no he dicho eso, no me entienda mal Ud!, ni estoy diciendo que sea mala prácticarla, no se proecupe! no y por favor si está leyendo algún profe que me enseñó este post, Hola? no se preocupe Profe, aprendí bien mis leccciones de clases :D)tampoco estoy diceindo que un desarrollador promedio no pueda aplicar esta técnica con Drupal por que si lo hacen; el punto está enfocado más al hecho de que el core o núcleo de Drupal durante mucho tiempo ha sido alimentado y desarrollado de una manera compleja para facilitar la creación de Módulos ahora en Drupal. Pero que no solo la base de código es compleja. Es la gran cantidad de subsistemas, de los métodos de datos que pasan, de los convenios especializados, incluso de la terminología es algo compleja. Pretender ligar la POO en este cuadro no es simplificar las cosas.
Realmente existe un dilema en lo que está sucediendo y muchos acuerdos y desacuerdos frente al tema. En conclusión como menciona Matt "Lo que existe es una profunda diferencia filosófica entre arquitecturas orientada a objetos y la disposición de Drupal's laissez-faire ¿Por qué tratar de mezclar a los contrarios?
Drupal 7 con todos sus nodos, campos, entidades, usuarios, comentarios, los menús, las vistas, consultas, filtros, acciones, las funciones, preprocesadores, themes, módulos ... y que para Drupal 8, se esta agregando Contextos, plugins .... Estos subsistemas Oreintado a Objetos nuevos tendrán (o ya tiene) nuevos convenios y las nuevas prácticas de programación y terminología nueva. ¿Cómo alguien recien iniciándose alguna vez entendera todo esto? teniendo encuenta el core de Drupal?.
A mi punto de vista los que tenemos de alguna forma una mentalidad bastante "Ingenieríl y estructurada" (por decirlos de alguna forma), tendemos a querer estructurar todo lo que esté a nuestro alrededor; pero realmente en este caso, una idea como ésta es un beneficio o es lo mejor para el avance de Drupal? o es que lo que más queremos es estructurar este Framework y adecuar a nuestra mente y forma de ver las cosas...
Quiero finalizar mi post dejando una pregunta abierta.Que piensa Ud. acerca de esto? déjeme sus comentarios.
Yo pienso que se deben separar las cosas, el uso de POO es para usarlo en conjunto con una Metología de desarrollo (RUP). Muchos piensan que programar en POO es la mejor practica, y es falso, existe la programación Modular, Funcional, x Contratos, y muchos paradigmas más. Cada uno tiene sus ventajas y desventajas.
PHP es de naturaleza modular, es por ello que permite desligarse de metodologías.Pero si quieres agregarle POO por cuestión de moda ahí radican los problemas. Lo importante para todo programador es saber elegir que lenguaje se adecua mejor ante una metodología sin perder la calidad.
Primero, estoy en desacuerdo con "jc", no creo que ningún lenguaje en ningún paradigma esé amarrado o se aplique mejor en alguna metodología.
Sobre el post, según algunos principios de POO, los métodos GetHashCode o ToString que existen dentro de las clases de algunos lenguajes, se podrían ver como una mala decisión de diseño, debido a que se están mesclando las responsabilidades, la lógica de la clase y como mostrarse en una cadena(violación del single responsability principle).
Xq los que diseñaron el lenguaje no prefirieron hacer un API de tal manera que cada vez que necesitemos un ToString tengamos que crear una nueva clase? Simple, xq ellos prefieren que su producto le de valor a sus clientes (nosotros los desarrolladores) a estar cumpliendo con todos los principios de la POO. De qué sirve un core complejo con un montón de indirecciones si no hace que la vida de sus usuario sea más facil.
No conozco el caso de Drupal , posiblemente estos cambios sean necesarios incrementar la mantenibilidad de algo tan importante como es el núcleo o tal vez realmente se esté sobre-diseñando algunas cosas; lo que sí es seguro, que si el diseño de un producto dificulta el trabajo de sus usuarios, no es un diseño adecuado.
Para comenzar, estoy de acuerdo con Snahider, cualquier metodología puede usar cualquier lenguaje de programación.
Retomado el tema del post, creo que todo depende del contexto (debo confesar que esa frase a veces me aburre). El objetivo es que los desarrolladores se sientan a gusto, que el software funcione correctamente y no importa si es POO o no, mientras les permita a los desarrollares de Drupal mantenerlo, mejorar y crecer.
Assoritam :P luego de leer tu post me ha dado ganas de revisar el código fuente de Drupal, estoy agregando esa tarea a mis next-actions.
Muchas gracias a Jc, Snahider y mi querido amigo Abner por sus comentarios, realmente creo que ayudan mucho y aportan al post, al dar sus diferentes puntos de vistas.
Es un tema que puede verse de un lado y otro, sólo quiero dar mi apreciación en un punto, no creo que algo que este fuera de la lógica de POO deba ser considerado como un mal diseño,quizá me equivoque pero hasta ahora lo creo así.Buscando una analogía es como decir que un poema no es poema si no obedece a la metrica? :S mmhh..tengo mis dudas al respecto.
H.h. :)
En el mejor sentido, comparar POO con DRUPAL/PHP es comparar un Ómnibus inter provincial (formal y legal) con un TICO.
Mientras uno esta forjado como metodología y filosofía de desarrollo en el largo proceso de hacer SISTEMAS de INFORMACIÓN; el otro es un framework sobre un lenguaje de script que tiene por objeto desarrollar de manera limpia, rápida y eficaz soluciones internet.
El desarrollo del mercado laboral y las crecientes demandas por rapidez y menos "tramite" en la generación de soluciones WEB han originado que los frameworks tenga un éxito mayúsculo, esa es su fortaleza y su razón de ser, si lo modificas, forzando características POO, tendrás después de todo el trabajo que eso implique, una herramienta de desarrollo lento en un lenguaje scripting insuficiente. exactamente lo que sucedió con ASP 3.0
Antes de mesclar las dos cosas, apoyaría un desarrollo de un nuevo framework que desde su inicio tenga los criterios POO que buscas en los actuales.
Tengo entendido que cuando Drupal fue concebido PHP aun no soportaba POO, sin embargo, hoy en dia, Drupal (D6) internamente se vale de la POO en algunas cosas, asi como muchos de sus modulos tambien lo hacen. Habia oido que Drupal 7 reimplementa en POO algunas cosas que se hacian de forma estructurada antes, como por ejemplo lo relacionado a base de datos. Hay quienes mencionan que el hacerlo en POO ayuda a que algo pueda ser expandido con menos dificultad en el futuro y me atreveria a decir que probablemente pudiera hacer mas sencilla la creacion de modulos. Sin embargo, el trabajar con objetos, en PHP tiene un costo de desempeño, si lo comparamos con algo trabajado en PE, no digo que los cambios selectivos hacia POO en D7 sean los culpables de su lentitud (criticada por algunos), puesto que estoy seguro que hay otras cosas que la causan. En lo personal creo que por ahora conviene ir hacia POO algunas cosas y dejar en PE algunas otras, por compatibilidad y desempeño, principalmente.
Umm teoricamente Drupal es un sistema Orientado a Objetos, yo siento que un nodo es un objeto, sus campos con CCK son los fields normales de un objeto. Hay polimorfismo al manejar los hooks del nucleo de drupal como el user_session_hook.
Los archivos de templates acaso no son una especie de herencia? Especialmente cuando usamos un subtema.
Creo que Drupal tiene muchas cosas prestadas del la POO, que no use objetos de PHP, no quiere decir que no use objetos.
Hola. Me gustó tu artículo y también he observado que Drupal está organizado de modo diferente, pero posiblemente sea eso lo que hace que le da sus virtudes.
Si recordamos, a la computadora no le importa cómo hemos hecho el programa. Algo que creamos que es mejor por haberlo hecho con OOP no correra más rápido por eso sino por... las razones de la computadora.
Porque OOP ha sido hecho para los programadores, no para la computadora. El objetivo del código de alto nivel, UML, etc, es hacer la programación mas manejable, llevadera, confiable, etc.
Si Drupal logra eso sin usar OOP estrictamente, eso puede indicar que hay mas de un camino :)
A mi, personalmente, me parece genial la forma como Drupal permite la colaboración de los módulos que uno hace con lo que ya viene funcionando (a través de sus hooks y convenciones de nombres).
Uno aprende en la universidad muchas cosas utiles, pero no hay que santificarlas tampoco :) Creo que lo mejor es tener la mente abierta, observar, probar, y seguir aprendiendo continuamente.
Hace tiempo que siento el impulso de volver a mis orígenes y a la OOP. Como programador en Drupal nunca me he sentido a gusto con la programación estructurada. Sin embargo siempre volvía a mi cabeza la voz mesurada que me decía "no, respeta el 'Drupal Way'". Así que desechaba mis impulsos.
La cosa cambió hace unos meses, cuando cayó en mis manos el libro Clean Code. Hasta entonces, me creía un (aceptablemente) buen programador. Y a medida que leía sus páginas se iba revelando la verdad y la vergüenza de mi propio código. Y a medida que pasaban los capítulos me daba cuenta de la gran empanada de espinacas que es Drupal, al menos en su versión 6.
Deltas, operadores, múltimes hooks, eventos que se disparan, funciones que se acoplan... un sistema grandioso, sí, pero...
¿No os hastía cuando tenéis que hacer un nuevo formulario, con funciones de scroll vertical infinito y replicación de código abusiva?
¿No os resultan incómodos los chorizos resultantes de utilizar hook_nodeapi() para CUALQUIER COSA que le ocurra a un nodo?
Hay un principio repetido hasta la saciedad en Clean Code (libro que no puedo recomendar con mayor firmeza); las funciones deberían hacer una sola cosa. Este y otros muchos principios son ignorados por Drupal, y sólo hay que ver unos cuantos módulos contribuídos para darse cuenta que la programación en Drupal, al contrario de lo que dice Matt Butcher en el post enlazado, no es simple sino compleja e incluso (me atrevo) fea por naturaleza.
Por eso, y porque el testing unitario con la programación estructurada no es gratuíto, estoy considerando muy seriamente empezar a combinar los hooks de Drupal con clases.
Un saludo.
lunes 13 junio 15:20
Añadir Comentarios
Su comentario deberá ser aprobado antes de ser publicado. Gracias!
PHP es de naturaleza modular, es por ello que permite desligarse de metodologías.Pero si quieres agregarle POO por cuestión de moda ahí radican los problemas. Lo importante para todo programador es saber elegir que lenguaje se adecua mejor ante una metodología sin perder la calidad.