Por qué la Programación Orientada a Objetos es mala para Drupal

artículo de Matt Buttcher (2010/10/13), traducción libre de Antonio Kobashikawa

Nota de traductor: Aunque Drupal se ha convertido en un movimiento poderoso, parece que, en el interés por capitalizar algunos negocios asociados, se han tomado decisiones que están distanciando al producto de sus objetivos primarios para la comunidad. Algunas personas han estado notando eso desde hace algún tiempo y me parece interesante el tema.

He conducido o contribuido a docenas de proyectos Open Source. Y todo mi código ha sido siempre Orientado a Objetos, con una excepción. Esa excepción es Drupal. Java, Python, PHP, y aún OO Perl... soy un desarrollador que teje con la lana del OO. Así que esto puede sonar chocante para cualquiera que me conoce, pero mi argumento es que la OO es mala para Drupal.

Créame que decirlo no es algo notable en mi vida de desarrollador. Me siento como si le dijera a mi niño que debe faltar al colegio, sólo porque tal nivel de sofisticación no es necesaria en su vida. Y supongo que ese es, precisamente, el sentido de lo que estoy diciendo.

1. La compejidad es la antitesis de la manera Drupal

¿Por qué tiene Drupal miles de modulos mientras otros CMS -muchos más antiguos que Drupal-, tienen mucho menos? La razón es tan clara como el día. Los módulos de Drupal son simples de desarrollar. Y esto es no sólo porque los hooks son fáciles de usar, sino porque el API está bastante enfocado en hacer fáciles las cosas difíciles.

Pero una parte del camino está al revés: las cosas faciles se han vuelto más y más difíciles.

Me ocurrió durante una conversación con un amigo mío. Él es un excelente desarrollador PHP que había trabajado con Drupal más tiempo que yo. Se lamentaba que Drupal 4.7 había sido mucho mejor que Drupal 6. Cuando le pregunté por qué. empezó a enumerar las formas que que Drupal se ha vuelto más complejo con los años. Él no es un egresado deseando que la vida fuera de la universidad sea tan buena como cuando vivía en su dormitorio. Se trata de un desarrollador experimentado, y sus ideas eran profundas.

Alguna vez, fue posible para un desarrollador promedio conocer Drupal. Ahora, poca gente (quizás 5-10) entienden todos los sistemas del core de Drupal. Ese punto realmente me atrapó. No es sólo que el código base sea complejo. Es la plétora de subsistemas, de formas de pasarse los datos, de convenciones especializadas, y aún de la terminología. Drupal es un hipopótamo conceptual.

Introducir OO en el cuadro no es una simplificación. De hecho, es una inyección masiva de complejidad. Muchos desarrolladores Drupal están ahora mismo tratando de aprender un nuevo conjunto de prácticas. La profundidad conceptual de Drupal 7 es abismal. Nodos, campos, entidades, usuarios, comentarios, menús, los otros menús, vistas, las otras vistas, queries, filtros, acciones, hooks, funciones de tema, preprocesadores, templates, módulos... y para Drupal 8, ¡agregaremos más! contextos, plugins... Estos nuevos subsistemas OO tendrán (o ya tienen) nuevas convenciones y nueva terminología y nuevas prácticas de programacion. ¿Cómo puede un recién llegado entender esto?

¿Acaso es "mantenganlo en perspectiva" la respuesta? ¿Qué vamos a sacar de esta nueva tendencia? ¿Un mejor sistema, a qué costo? Contribuyentes y usuarios. Renunciarán. Drupal se está volviendo el sueño del consultor ocioso: toneladas de jerga, montones de complejidad, y una pila de llamadas que requiere una pizarra del tamaño de una pared para diagramarla.

2. Privado, protegido, y filosóficamente discordante

El debate sobre si deben o no usarse las palabras clave private y protected en Drupal ha sido revelador para mí. No porque porque piense que la gente este siendo banal. De hecho, es lo opuesto. Pienso que esta siendo profunda.

Nosotros, la gente con mentalidad OO, no podemos entender que alguien pueda poner en tela de juicio la utilidad de las variables protegidas. ¡Herejía! Y tenemos nuestro pequeño arsenal de argumentos en favor de propiedades privadas incluso para proyectos FOSS (Free and Open Source Software). Pero cuando reflexionamos sobre ello, el propósito de los miembros privados y protegidos de un objeto es mantener otras cosas (léase: programadores cargosos con "grandes ideas") de modificar su preciosa data.

Drupal, simplemente, no va por ahí.

De hecho, la sentencia de muerte (bienvenida) del anti-pattern static vino en la forma de drupal_static(), el cual ahora nos provee de acceso no controlado al único mecanismo que teníamos para controlar datos en el ámbito global. ¡Las funciones estáticas son ahora tan públicas como las variables globales!

¿Qué es lo que ilustra esto? Durante mucho tiempo, Drupal ha permitido que los desarrolladores puedan dispararse a sí mismos (o sus websites) en el pie, haciendo cosas estúpidas. Drupal nunca ha tratado de proteger a un desarrollador de sí mismo, o de proteger mi API de las intenciones insidiosas de otros desarrolladores. Lo que tenemos aquí es una diferencia filosófica profunda entre las arquitecturas Orientadas a Objeto y la disposición de Drupal al laissez-faire (dejar hacer, dejar pasar). ¿Por qué tratar ahora de mezclar los contrarios?

3. Un cúmulo mal hecho de técnicas sin forma

¿Por qué Drupal hace una distinción entre themers y desarrolladores? Una gran razón es porque las dos capas requieren distintas arquitecturas y convenciones. Los templates PHP fueron escritos alrededor de 1997 (¡Cómo lo deseaba Rasmus!). Esto if; esto else; esto print. EOF. Los módulos, por otro lado, son tan manejados por datos que, si un bit de HTML se cuela en su módulo (y no es una función de tema), podrá esperar repercusiones en su cola de issues.

Así que hay dos técnicas diferentes que el Rock Star (este... ¿dije eso?) Drupal developer tiene que dominar. ¿Es así? Bueno... en realidad, hay más.

Hay hooks, una casi-novedad en la esfera de la programación PHP. Y arrays anidados -la Única Estructura de Datos para Gobernarlos a Todos, según la forma de ver de algunas personas. Lo más cercano que haya visto a los arrays FAPI, fuera de Drupal, es el LDAP API... y eso es como comparar a los Yankees con un equipo de las ligas menores. Hay archivos .info, que son casi como archivos PHP .ini. Hay convenciones de nombres importantes para programar en funciones, extensiones de archivos, directorios, tablas de base de datos, sentencias SQL, arrays de renderizado, y cadenas. Todos son diferentes, por supuesto. Donde uno puede esperar cinco funciones, hay solamente una... con un argumento $op. Estas no son prácticas estándar de programacion fuera de Drupal. Ya estábamos esperando mucho de nuestros desarrolladores.

Drupal ya tiene una matizada mezcla procedural/funcional de estilos (con alguna teoría Orientada a Aspectos que la sazona). Y tiene una serie de convenciones profundamente arraigadas, aunque incipientes, construidas en torno a esas técnicas. ¿Y ahora estamos hablando de agregar otra importante nueva técnica de codificación? ¿Cuántos nuevos libros ha visto sobre teoría y práctica OO? ¿Y como es que se mezclará eso con nuestra arquitectura existente?

Pero, en serio... ¿cuál es el problema? Hay dos razones:
Consistencia: ¿Cómo puede uno construir algo que se aproxime a una arquitectura consistente cuando siempre hay al menos tres teorías que compiten sobre cómo se debería hacer?
Reutilización: No estoy hablando de código. Estoy hablando de wetware (la mente humana). A medida que nuestro estilo de codificación se aparte de la corriente principal, se vuelve más difícil para los neofitos imaginar cómo hacer las cosas. La OOP Drupalesca está introduciendo otra anomalía que el nuevo usuario debe entender.

4. Refactorizando: El paso en falso, sobre aguas de tiburones, de los proyectos FOSS

¿Cómo matar un proyecto Open Source? Reescriba toda la cosa. Y el gran ejemplo FOSS por excelencia para esto es... ¡PERL!

Ahora que hemos iniciado el sendero del OO, todo parece ser candidato a refactorizar. ¿Qué tan fuerte reclama la gente la fecha límite para Drupal 7? ¿Y qué tanto y tan fuerte reclamará la gente antes de que se distraigan con algo brillante... y más simple... y que se perciba como "más activo"? ¿Cuánta gente está dispuesta a tolerar un gran cambio en el API cuando podría ser más facil simplemente aprender algo nuevo?

Esta es una razón significativa, pienso, para resistirse activamente a saltar sobre la catarata de la reescritura API a la OO.

5. La controversia consume tiempo

Por largo tiempo, nunca entendí porque la gente lee las revistas que se venden junto a las cajas registradoras de los supermercados. ¿A quién le importa si Britney deja a su niño en el asiento de atrás mientras se va a comprar alimento para mascotas? ¿Por qué es tan importante que dos ricas celebridades de Hollywood se estén separando luego de tres meses de matrimonio?

Pero la respuesta me golpeó la duodécima vez que refrescaba Twitter durante el DrupalCon de Copenhage: los humanos (incluido yo) aman la controversia. Tanto así que nos distraemos fácilmente con ella -lejos de las cosas por las que, aparentemente, nos preocumamos más.

Una vez que empezamos a mezclar los principales estilos de programación, como estamos empezando a hacer, abrimos una gran lata de gusanos. Ahora sera The Gang of Four (la Banda de los Cuatro, los chicos Orientados a Objetos, que son de lejos menos malvados que el grupo de Mao) vs Kernigan y Ritchie (los creadores de C). Y de tiempo en tiempo veremos otras vez choques que generarán controversia fresca. La potencial pérdia de tiempo ya se está manifestando (¿en este artículo?).

Debemos boicotear OOP?

¿Cuál es el balance final? ¿Debemos prohibir por decreto toda OO? No lo creo. Para algunos casos, creo que es probablemente la elección adecuada. Por ejemplo, pienso que el caracteristicas encadenadas del nuevo API de base de datos es una gran manera de cumplir efectivamente con los objetivos de Drupal. Aún así, me encuentro reticente a recomendar algún otro lugar donde deba ponerse OO como lo principal.

Seguro que vemos muchos ejemplos de módulos contribuídos que usan OO, y debemos tratar a los módulos contribuídos como siempre hemos hecho: como los soberanos de las contribuciones.

Pero, para el core, es la hora de contener los esfuerzos OO, y dar un buen vistazo, aunque difícil, a como queremos mantener el API de Drupal... bueno... drupalizado.