10 errores comunes programando orientado a objetos en PHP
El dominio de la programación orientada a objetos es, sin duda, uno de los paradigmas más codiciado por los programadores. Sin embargo, muchas veces estos cometen "atrocidades" al intentar implementarlo solo por decir a sus amigos, empresas u otros "Yo sé programar orientado a objetos".
A continuación verán una lista de 10 cosas que no se deben hacer al implementar programación orientada a objetos enfocándonos en el lenguaje PHP.
- Usar variables globales dentro las clases: una de las ventajas más importantes de la programación orientada a objetos es la reusabilidad de los códigos. Al usar variables globales ($_GET, $_SESSION, $_POST, $_COOKIE, global) dentro de las clases, esta se ve comprometida considerablemente. La razón es que todos los proyectos no tienen las mismas variables globales.
- Mezclar código HTML en la definición de las clases: es una de las cosas que me sorprenden cada vez que la veo. Es inaceptable que esto se le haya ocurrido a algunos. Al mezclar HTML en el código PHP se compromete la reusabilidad de la clase, no todos los proyectos tienen el mismo código HTML.
- Imprimir salida (echo) dentro de las clases: aunque esto se parece a la anterior, me refiero a los echo o similares dentro de los métodos. Si una clase no está destinada para emitir salida no lo debe hacer. Para eso muchos utilizamos sistemas de plantillas.
- Identificadores de clases, métodos y propiedades sin sentido: un identificador siempre debe ser lo más descriptivo posible. A muchos le gusta usar identificadores increíblemente irrelacionados con su propósito. Esto compromete enormemente la lectura de un código. (Mira las reglas de codificación en PHP)
- Mezclar uso de versiones de php en una misma clase: a partir de la versión 5 de PHP, la programación orientada a objetos se puede implementar de una manera más formal, pues se introdujo los modificadores de visibilidad public, private, protected. Aparte de que se pueden crear clases de alto nivel (clase Abstractas) y métodos abstractos con la palabra reservada abstract. También se pueden definir los métodos y propiedades estáticas formalmente con la palabra reservada static. Mezclar la programación orientada a objetos en PHP 4 (donde todo era publico) con la de PHP 5 hace un código “sucio”. Consejo: elige una de las versiones y programa para ella.
- Más de una clase en un mismo archivo: definir distintas clases en un mismo archivo es otra de las cosas que no se debe hacer. Las clase se han de componer lo más reusables posible y si puedes nombrar al archivo con el nombre de la clase muchísimo mejor. Sigue el camino de los grandes lenguajes como: Actionscript, Asp.net, Java entre otros.
- No hacer pruebas unitarias a las clases: al terminar de codificar una clase recuerda de hacer pruebas unitarias para asegurar el correcto funcionamiento de clase. Esto es simplemente probar todos los posibles caminos que pueda tomar un estado (propiedad), parámetro de método, etc para que la clase no “explote”.
- Todos los métodos y las propiedades publicas en una clase de PHP 5: los programadores novatos cometen el error de definir todos los métodos y propiedades como públicos, por desconocer las ventajas de los modificadores visibilidad. En PHP este es un problema grave porque no hay tipeado de datos. El problema de las propiedades públicas es que no podemos controlar de manera fácil el tipo de datos que contiene por lo que nuestra clase pudiera explotar por un tipo de dato inesperado. Si no estas seguro de que visibilidad le debes poner a una propiedad hazla privada. Valida los tipos de datos de las propiedades al menos de una manera básica.
- Duplicación de métodos para ocultar falla de lógica: A diferencia de otros lenguajes como Java y C++, PHP no admite la sobrecarga de métodos. Al menos no de la manera tradicional. Esto, sin embargo, no es excusa para duplicar métodos sólo porque un dato cambia para la operación que éste realiza.
- Variables de configuración dentro de las clases: Los datos de configuración de base de datos, web services y otros deben ir en un archivo de configuración aparte, NO dentro de la clases que hacen uso de estas. Aunque se admite en clases que sea exclusivamente para ello.
