Discusión: "¿cuál es tu grado de madurez en POO?"

Todo surgió respondiendo una consulta en un foro y me pareció interesante discutirlo aquí. Les comparto los "niveles" o "etapas" que considero que todo desarrollador pasa cuando decide dejar atrás la programación estructurada.

Generalmente todos empiezan por el primero y luego pocos llegan hasta el último (la mayoría solo logra llegar al 2 y se estancan en el 3):

1. "Programación Estructurada": el inicio, desde donde parten, la "nada" ;-)
   
2. "Programación Estructurada con uso de Objetos": usan objetos "sueltos / aislados", no los saben relacionar entre ellos, se reusan a leer material con "conceptos", creen que es mejor aprender a través del "prueba y error".
3. "Programación Orientada a Objetos Sin Conceptos Claros": "creen que lo hacen bien" pero luego heredan clases mecánicamente pensando que es el mejor mecanismo para reusar código.
   
4. "Desarrollo 100% OO": personas que invirtieron sabiamente su tiempo para aprender primero los conceptos para luego poder aplicarlos de forma correcta

Puedes seguir desarrollando estructurado y apoyarte en algunos objetos, pero lo ideal es que te vayas adecuando a la forma de trabajo con objetos y estructures todo el sistema de esta forma (y eso empieza por "pensar en objetos", no en código).

Nuevamente, "crear clases y jugar con objetos" es algo que todos podemos hacer, pero desarrollar "orientado a objetos" es un tema más de tener los conceptos claros que de saber la sintaxis de cómo se codifica.

Recomiendo que antes de preguntar qué es o qué no es POO, revisar el apartado de Wikipedia sobre POO y paradigmas de programación y las diferencias entre ellos.

¿Tú, en qué nivel de madurez estás? ¿crees que hay otros niveles o etapas más? ;-)

¿Por qué usar un (zend) framework?

Estas preguntas me la han hecho muchas veces, así que es buen momento para compartirlas en el blog :-)

• ¿Para qué sirve un framework?
• ¿Por qué Zend Framework?
• ¿Cuales son las ventajas de no hacer todo yo?
• etc
  

La idea de los frameworks es que son "cajas de herramientas" que puedes aprovechar en tus desarrollos... la filosofía del desarrollo profesional debería ser "¿cómo harías para construir una casa con las manos y sin martillos? imposible, no terminaría nunca, debo usar herramientas..."

Por ejemplo, no tienes que crearte tu propia clase de persistencia para recuperar o guardar datos, lo cual incluye además de lo básico, muchas funcionalidades que te ahorran tiempo y hasta te dan mayor seguridad por controles internos que ya incorporan de fábrica.

Si le sumamos que el esquema de trabajo es MVC, ya te da una forma de organizar tus sistemas, donde colocar cada cosa, etc, que te permite estandarizar y ahorrar mucho tiempo.

Un ejemplo bastante común: tú quieres validar un email que recibes de un formulario, en vez de tener que implementar toda esa parte (y hacerlo bien) puedes hacer uso de clases existentes como Zend_Validate_EmailAddress()

$email = $this->getRequest()->getPost(' email', 'none@example.com');
$validator = new Zend_Validate_EmailAddress();

if ($validator->isValid($email)) {
// email seems valid
} else {
// email seems invalid; Outputting the reasons
}

Listo, sigues adelante y programas el resto de lo importante de tu sistema, ya que lo que te importa es terminar el trabajo, entregar el sistema y cobrar al cliente.

De alguna forma, muy resumida, te "profesionaliza".

No sé si quedó claro el ejemplo ;-)

PD: se podría decir que lo importante no es si usas Zend Framework (más allá que yo lo use), creo que deberías por lo menos conocer alguno y estudiarlo en profundidad para sacarle provecho en el reuso de componentes y experiencia de la empresa o grupo que lo desarrolló. Siempre existirán ventajas, más si tu eres un equipo reducido de desarrolladores y el framework fue hecho por un equipo más grande y especializado en su diseño y desarrollo, no lo hicieron en su tiempo libre.

"Apóyate en hombros de gigantes"

Comentar código de forma "invisible"

Este tema tiene un origen histórico, trataré de empezar desde el principio ;-)

Cuando hace años empezamos en el mundo estático del "html" (cuando el 95% de los sitios solo eran puro html sin dinamismo, sin un lenguaje de scripting), lo que aprendimos fue a "programar html" haciendo muchas tablas (no usábamos los div's como ahora) y para seguir la "cascada" de código le agregábamos comentarios usando el tradicional <!-- -->

Por ejemplo:


Muy "cómodo" para hacer debug "manual" usando de apoyo los comentarios porque evidentemente era un "humano" el que debía controlar todo esto y se podía perder entre tanto código en cascada ;-)

Para los "técnicos" esto siempre fue desprolijo, ya que para nuestros futuros clientes o hasta curiosos, estábamos revelando detalles internos de nuestra aplicación / diseño. Está de más decir que no es para nada recomendable hacer comentarios técnicos importantes en ellos ya que es "código público" que cualquiera puede leer, y tampoco comentar código que no se va a usar, ya que es extremadamente desprolijo (si no lo quieres perder, respalda, o versiona).

Nota: no será la primera y última vez que veo en los comentarios de un código html insultos del propio desarrollador, que la verdad queda muy feo ;-)

Primer sugerencia, el código de producción debe estar "limpio", y si conoces algún sistema que pueda contener los comentarios en tu código de desarrollo e impida que quede en producción, úsalo.

Algunos ejemplos.

Usando el propio lenguaje de scripting: PHP

Cuando la tecnología evolucionó y empezamos a contar con lenguajes de scripting como PHP, la primera práctica que empezamos a adoptar fue el de embeber el código "dinámico" dentro de nuestro código html, pero dejamos todas las demás prácticas intactas, por lo que los comentarios seguían estando públicos en el html.

Con el tiempo, dejamos de "embeber" y ya no era tan evidente la manipulación del código html, empezamos a hacer invocaciones a funciones de tipo:

generarCabezalHtml();
generarContenido('Hola Mundo');
generarPie();

Por lo que ya no es el "humano" que debe seguir tan literalmente el código, ver si cierra o no, porque podemos validarlo a través de herramientas, y luego tratar de seguirlo a través del código PHP (aquí también ayudan mucho los IDEs en la pre-validación del código y evitar errores).

Una opción posible es mover todos los comentarios html al código php y estos quedan "privados" dentro del sistema.

Si esto no fuera suficiente, aún se podría generar algo como una configuración que diga "habilitarComentariosHtml" y que genere html con comentarios embebidos, y una vez en producción, eliminar esta opción (pero estaríamos generando mucho código poco productivo para el sistema).

Sigamos un siguiente nivel en la escala evolutiva ;-)

Usando sistemas de plantillas: Smarty

Con los años esto no nos quedó muy cómodo y preferimos optar por un sistema de "plantillas" (templates), y limpiar nuestro código PHP. Smarty fue una de las mejores opciones por años, lo cual te ofrecía además un código simil PHP del lado del template, pero podíamos volver a caer en la misma práctica, hacer comentarios html públicos.

Repitiendo lo que hablamos en el punto anterior, podíamos adoptar el mecanismo de comentarios de Smarty, lo cual genera el mismo efecto que hacerlo desde PHP. Se hacía con {* comentarios *}

{* display dropdown lists *}
<select name="company">
{html_options options=$vals selected=$selected_id}
select>

La diferencia con el primer caso de "solo html" es que lo estamos haciendo en la plantilla y no es público, y tampoco lo estamos haciendo del lado de PHP ya que toda la parte de generado de html era responsabilidad de Smarty (como una separación de capas).

Siguiendo con la evolución...

Nos pasamos a Zend Framework y usamos "Vistas"

Las vistas son como al principio de nuestra era, código html donde se embebe código PHP de la siguiente forma (un mix entre PHP embebido y sistema de plantillas).




Y volvemos al principio, he visto muchos proyectos que para poder hacer seguimiento de lo que generan de html tienen comentarios públicos html por todos lados, por lo que mi sugerencia final es... hagamos los comentarios dentro de la la vista, dentro del código PHP embebido y no dejemos expuestos nuestros comentarios internos.

Existen también herramientas que limpian el código, lo compactan y hasta te lo ofuscan, bien podrían ser una alternativa.

Pero la idea es esa, trata de no dejar comentarios que los pueda leer todo el mundo, sé ordenado y limpio. En lo personal cuando voy a ver páginas de diseño web que se ufanan de seguir "estándares", descubrir luego tablas o comentarios del tipo "abre tabla", "cierra tabla", etc, no me dejan muy tranquilo.

¿Qué opinas? ¿cuales son tus prácticas? ¿o no te importa que puedan descubrir leyendo el código de tu sitio? ;-)

Repasando la historia a través de Zeev Suraski, coautor de PHP

En estos días volví a leer esta entrevista que data de principios del año pasado y la verdad que tiene partes muy interesantes que valen la pena recordar y destacar, como la vez que comentamos la opinión de Rasmus Lerdof (autor inicial de PHP) apoyando la "programación estructurada" y desalentando el uso de los objetos y los frameworks (ya casi le perdí el respeto ;-)).

Entre los tres, Zeev Suraski, Andi Gutmans y Rasmus Lerdof(castellano), se puede decir que son la cara más visible de la creación de PHP. Digo "se puede decir" ya que como ellos mismos reconocen son un proyecto Open Source (y no Software Libre) que es escrito mayormente por los usuarios. Este trio, con los años, serán los fundadores de Zend Technologies.

Destaco algunos comentarios vertidos por Zeev (los resaltados son míos):

-PHP es software libre o de código abierto?

-En la definición de Richard Stallman, es código abierto porque no tiene una licencia GNU. PHP tiene su propia licencia.

-El video mató a la estrella de la radio. PHP está preparado para la web 3.0?

-No sé cómo será la web 3.0 y no puedo decir que estemos preparados para ello pero, en general, tenemos mucho éxito en integrar tecnologías para hacerlas accesibles, integración con Java, etc. Ahora que estamos preparando la versión 6 de PHP, veo que está tan avanzado y es tan poderoso, comparado con la versión de 1996, está integrado con tantos lenguajes, muchas cosas que hemos implementado en PHP están basadas en ideas y demandas de la gente que lo está usando, quizá el 60%. Por tanto, el hecho de que PHP responda a las necesidades de la gente hace que cuando la web 3.0 sea popular, PHP soporte todo lo que necesite. Incluso sin saber que será la web 3.0, una forma de conocer el futuro es crearlo.
-Ahora Java es libre. ¿Es un problema para PHP?

-No. Hay una diferencia fundamental entre ambos: Java no se ha diseñado para crear sitios web sino aplicaciones de escritorio. Es más difícil crear sitios web con Java que con PHP, sea Java libre o no. Estamos en negocios diferentes.

-Si PHP es gratuito, ¿de qué vivís?

-Cuando lo creamos estábamos en la universidad y no necesitábamos mucho dinero, era un hobby. Pero cuando empezó a crecer, en ocho meses, entre 1998 y 1999 un millón de sitios web lo empezaron a usar. Fue algo increible. Y empezamos a pensar qué negocio podíamos crear, no fuimos nosotros sino que las empresas venían a nosotros, en 1999, pidiéndonos que hiciésemos determinadas herramientas para PHP que no existían o pidiéndonos soporte. Al ver esto, creamos Zend Technologies. Invertimos mucho en código abierto y lo que hacemos es vender el conocimiento y crear programas comerciales y servicios para empresas. Así hacemos el dinero. Invertimos mucho en proyectos de código abierto y donde hacemos el dinero es en los servicios comerciales.

-¿El código de PHP se produce todo en Zend?

-No. Zend es responsable sólo del kernel de PHP. El resto de contribuciones son desarrolladas por gente de Zend pero muchos voluntarios. PHP no sería lo que es sin las contribuciones de esa gente que ha creado las extensiones y otros, voluntarios de todo el mundo. Zend hace las partes quizá más complicadas pero la mayoría de gente que contribuye crea y mejora PHP son voluntarios de todo el mundo. No sería tan popular sin sus contribuciones. Si miras todas las líneas de código de PHP, quizás el 90% es de los voluntarios. PHP es como una cebolla: en el centro está el kernel y esto lo desarrollamos nosotros, pero el resto de capas las hacen voluntarios (extensiones, etc). Zend hace también una parte, pero pequeña. En PHP hay un montón de desarrollo de la comunidad. PHP es uno de los mejores ejemplos de productividad funcional de la comunidad. No somos sólo una empresa.


-¿Qué tecnologías son realmente vuestros competidores?

-Java y .Net son grandes competidores. .Net es muy bueno si te gusta Microsoft, están haciendo un buen trabajo. Java es una historia diferente, tiene mucho trabajo hecho en la percepción, en la imagen, han hecho un gran trabajo de marketing, todo el mundo piensa que debe usar Java para todo. Esta percepción es aún difícil de cambiar. Java es un competidor en el área de aplicaciones web más por la percepción de las empresas de que deben usar Java para todo. Esto está empezando a cambiar, también porque las empresas oficiales de Java están empezando a soportar PHP y vemos a Java menos como competidor y más como colega, aplicaciones que conectan PHP y Java, usar Java para unas cosas y PHP para otras, conectarlos es necesario.

-Hace unos días, leíamos que el editor de O'Reilly decía: "We've noticed that one of the signs that a language is becoming mainstreams (and perhaps being abandoned by the cutting edge developers) is that the For Dummies book becomes the top seller". ¿Es quizás el caso de PHP?

-Ahhh... Qué manía en predecir el futuro.. No, no lo creo... No sé si es un buen indicador. PHP desde el principio no ha querido dirigirse a los desarrolladores avanzados. Desde el principio sabíamos que no era para ellos, por eso lo hicimos fácil de usar. No queríamos que fuese un lenguaje élite desde el principio sino fácil para los nuevos y creo que hicimos un buen trabajo. Y ahora hay muchos novatos que lo usan y también compañías avanzadas y queremos seguir por este camino.

-PHP tiene algún conejo a punto de sacar de la chistera?

-Conejos no, solemos jugar con la transparencia en el código abierto. La discusión precisamente está en ser muy abiertos. Para la comunidad de desarrolladores, el Zend Framework y los componentes que vamos a publicar en unos meses creo que serán una sorpresa, aunque no son un secreto. Para las empresas, estamos haciendo más potente Zend Core. También estamos trabajamos con IBM en herramientas para PHP. Es difícil hablar de sorpresas porque no lo son.

-Si PHP no hubiese sido libre habría tenido este éxito?

-No. Más por la accesibilidad que por el precio, que no es un aspecto demasiado importante, aunque está claro que si no te cuesta nada entrar en esta tecnología es más fácil hacerlo. Hoy las compañías usan PHP porque la tecnología es buena, pero si no fuese popular no lo harían. La comunidad ha sido la clave del éxito de PHP.

Fin del resumen

Explica muchas cosas, como el hecho de no ser tan estrictos con los programadores, dar "flexibilidad y facilidad" (filosofía que no comparto enteramente), pero que visto desde otros ambientes damos la impresión de ser "poco serios" o hasta "desprolijos".

De todas formas, y aunque lo digan los autores, no reflejan la opinión de la mayoría, ya que hay una puja clara dentro de la comunidad: los usuarios que quieren que sea "fácil y directo" (sin importar tanto el diseño ni las buenas prácticas) y las empresas que buscan un modelo "más robusto, estricto, más de plataforma" (como sucede con Java y .Net).

Ustedes ya saben de que lado estoy y por lo que voy a seguir trabajando... ¡siempre más allá de los lenguajes! ;-)

Estándares o muerte... para PHP

Luego de una acalorada discusión sobre el tema estándares y buenas prácticas, paso en limpio y hago un resumen de todo lo hablado, ya que veo que es un tema que los "Desarrolladores PHP" nos cuesta -aún- tomar conciencia.

Nuestros referentes obligados

Zend -la empresa- nos guste o no, debe ser siempre el referente a todo lo relacionado con PHP, ya que no solo desarrollan en la actualidad lo que puede considerarse el "Framework Oficial de PHP" (sin desmedro de ningún otro framework), también es la responsable de desarrollar el propio lenguaje PHP.

La importancia de los estándares

Los estándares nos permiten disminuir muchos costos que surgen a la hora de desarrollar sistemas que van desde la incorporación de nuevos recursos hasta el entendimiento de los sistemas "legacy" ("sistemas heredados") que existen en cualquier organización. Si todos los desarrolladores programan como quieren, o cualquiera inventa su "propio estándar" o toma el de "cualquier estándar que use otro proyecto", indudablemente esto significará caos.

Qué sucede con la empresa Sun y su lenguaje Java

Creo que está de más decir que a nadie de los profesionales que desarrolla bajo Java se le ocurriría no seguir el estándar de Sun Microsystems, y esta empresa a su vez, que es muy metódica y ordenada, tiene predefinidas especificaciones muy claras que explican cómo codificar, cómo programar, cómo usar tal o cual tecnología, para que todos los que usen la arquitectura sigan el mismo criterio.

Empresa Sun == Empresa Zend

Por lo tanto, es de sentido común tomar entonces las sugerencias de Zend como "estándar oficial" y empezar a usar sus criterios (nos gusten o no), sin importar si antes programabas estructurado en PHP con una nomenclatura y ahora quieres seguir usándola, o si no usas Zend Framework y quieres seguir el criterio de otros lenguajes.

Nota: a mi tampoco me gustó la primera vez que vi las llaves de las clases y los métodos contra el margen izquierdo, similar a C o C++, pero a las pocas semanas me acostumbré.

La Historia de PHP

PHP es un lenguaje que desde sus orígenes estuvo pensado para programar de forma estructura o "procedural" (uso de funciones y pasaje de datos a través de parámetros), pero con la evolución de los lenguajes este empezó a ser cada vez más Orientado a Objetos, tomando como referencia el lenguaje Java (en la mayoría de los casos, ya que no hizo lo mismo con el término "namespaces" que en sí lo sacan de .Net).

Aquí surge un híbrido, un lenguaje con una lista interminable de "funciones estructuradas" que empieza a evolucionar hacia los Objetos, que permite crear clases como en Java, pero que por un lado usa la nomenclatura "smallcase" (en todas sus funciones) y por otro sugiere la nomenclatura "camelcase".

"Camelcase Versus Smallcase"

"Camelcase" es un estándar en la mayoría (por no decir todos) los lenguajes POO, por lo que Zend sugiere, al igual que Java y .Net, seguir esta nomenclatura.

1  <?php
2  
3  require_once 'Usuario.php';
4  
5  $admin = new UsuarioAdmin();
6  
7  echo $admin->getNombre();
8  
9  ?>


Aquí es donde surge el problema (o la confusión), muchos desarrolladores PHP siguen usando el estándar viejo "smallcase" porque así es como inició PHP con la práctica estructurada y todas sus funciones siguen usando esa nomenclatura (ver Anexo a continuación).

1  <?php
2  
3  require_once 'usuario.php';
4  
5  $admin = new UsuarioAdmin();
6  
7  echo $admin->get_nombre();
8  
9  ?>


Pasando en limpio, para PHP la regla sería:

"Cuando es POO se usa camelcase, cuando es programación estructurada se usa smallcase"


Anexo: hacia donde debería evolucionar PHP7

Mi solución a este problema, buscando una "migración de paradigmas", sería que en PHP7 (ya que para PHP6 no hay miras de hacerlo) se implementen "Clases Wrappers" (envoltura / cáscara) que ocupen el lugar de las "Clases Base" (String, Integer, Boolean, etc) que existen en cualquier lenguaje 100% POO, logrando que cada método "esconda" la función "estructurada" correspondiente y mejorando notablemente la organización del lenguaje.

Por ejemplo, en vez de:

1  <?php
2  
3  $nombre = 'Enrique Place';
4  
5  $cadena_en_mayusculas = strtoupper( $nombre );
6  
7  ?>


Debería ser:

1  
2  <?php
3  
4  $nombre = new String('Enrique Place');
5  
6  $cadena_en_mayusculas = $nombre->toUpper();
7  
8  ?>


Y también se debería poder hacer algo como:

1  <?php
2  
3  $cadena_en_mayusculas = String::toUpper( $nombre );
4  
5  ?>


Cuando tienes que buscar algo relacionado con "strings" solo deberías buscar los métodos dentro de la clase correspondiente.

Nota: hace algunos años había iniciado sobre este tema un proyecto experimental como parte de mi taller piloto de PHP.

En Resumen

Se sabe que Sun define todos los estándares de Java y a nadie se le ocurre no seguirlos, en nuestro caso están empezando a existir fuertes "sugerencias" de parte de Zend ("nuestra Sun") para seguir el criterio "camelcase", porque justamente, lo usan en la mayoría de los lenguajes 100% POO.

Aquí está el enlace hacia una presentación realizada por Zend sobre las Buenas Prácticas de Desarrollo en PHP y la documentación de Zend Framework donde explica el estándar de codificación del proyecto (indistintamente si usas o no este framework, la guía sirve para todo desarrollo POO bajo PHP).

Para cerrar, resumo la explicación del manual sobre el "objetivo" del estándar de codificación y una frase de la presentación de Buenas Prácticas:

"Buenas normas de codificación son importantes en cualquier proyecto de desarrollo, pero sobre todo cuando varios programadores están trabajando sobre el mismo proyecto. Usar normas de codificación ayuda a asegurar que el código es de alta calidad, tiene menos bugs, y es fácil de mantener."

"No eres tan especial como para necesitar inventar tu propio estándar"

Espero haber aportado un poco de luz sobre el tema.

"¡Que fácil que caemos en las guerras entre lenguajes/plataformas!"

Cuando escribí el post sobre que los desarrolladores de PHP debíamos profesionalizarnos (inspirado en una respuesta que di en forosdelweb.com), un colega subió el mismo a Menéame (famoso sistema de promoción de noticias) y este generó un pico abrupto de nuevas visitas a este blog. Entre medio del proceso de votación que posibilita a que este artículo pasara de "la zona de revisión" a "la portada" de Menéame, se dieron algunas discusiones entre usuarios lo cual fácilmente derivo en la clásica lucha entre "lenguajes / tecnologías" (lo cual no aporta nada útil).

Esta es mi opinión sobre el tema, que aprovecho a rescatarla y dejarla "vigente" en el blog del autor (o sea, yo ;-) y terminar de reforzar la idea que intento transmitir en cada artículo que escribo, curso que dicto o charla en la que participo:

La idea de mi artículo (si, soy el atrevido que escribió esto ) es hacer reflexionar a los "programadores php" que con solo scripting no se hacen sistemas medios en adelante... y eso no es solo por un tema de "falta de plataforma" (porque al día de hoy PHP sigue siendo "solo un lenguaje" pero que se puede complementar con un conjunto de herramientas) es también un tema de "falta de mentalidad de desarrolladores", donde la gran mayoría de los programadores desconoce los conceptos básicos de la POO.

En mi muy humilde opinión, si tomamos en cuenta el avance en las plataformas más populares, como Java o .Net, los conocimientos de los programadores han quedado en el pasado bordeando en la actualidad el "analfabetismo" en todo lo que concierne OO, Diseño, Patrones, etc. **

PHP5 incorpora el manejo de "interfaces", pero al día de hoy es habitual hablar con desarrolladores que no entienden siquiera el concepto que hay detrás, ni la diferencia entre "programar orientado a la implementación" versus "programar orientado a la interfaz", donde la mayoría de los principios de diseño te sugieren que tus diseños dependan de "implementaciones abstractas" y no de "implementaciones concretas" (para obtener los beneficios tan publicitados del paradigma: flexibilidad, mantenibilidad y reusabilidad).

Y todo esto se hace con la ayuda de las "interfaces" (que no es, como he escuchado decir, para poder implementar "herencia múltiple"... estrategia desaconsejada que difícilmente verás implementada en un patrón de diseño).

Estas grandes carencias las percibo habiendo estado muy poco tiempo estudiando estos temas desde la óptica del mundo Java (muchos de los conceptos que quiero transmitirles a los programadores php, para que abran su cabeza, aquí son elementales). Cuando se liberó la versión 5 de PHP y al ver que implementaban la mayoría de las características que tiene cualquier lenguaje OO (interfaces, visibilidad de atributos y métodos, abstract, etc) me di cuenta que era perfectamente directo pasar los conocimientos y experiencias de un lado a otro.

Pero todo esto te das cuenta cuando vienes de una plataforma, de una arquitectura; si siempre estuviste "dentro" del ambiente PHP, ni te percatas de los grandes cambios que puedes hacer y del salto que pueden hacer tus sistemas.

No fue solo un agregado menor en la sintaxis.

Eso es lo que intento transmitir.