10 errores comunes programando orientado a objetos en PHP

Por: Maikel + 3 de Julio del 2007

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. Esta lista acompaña a nuestra vieja guía de 21 errores comunes programando en PHP.

1. 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.
   
   
2. 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.
   
   
3. 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.
   
   
4. 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)
   
   
5. 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.
   
   
6. 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.
   
   
7. 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”.
   
   
8. 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.
   
   
9. 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.
   
   
10. 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.

Tweet  

También te interesa

• Superando las expectativas, Maestros del web cumple 13 años
• Curso de programación orientada a objetos en Cristalab
• FreakLances: Serie animada de trabajadores web freelance

php webmasters poo

Buena información. Gracias Maikel
Por: Zguillez

muy bueno Maikel


Por: Jatrix13

de mas decirlo Maikel, simplemente excelente
Por: eldervaz

¡Muy buena nota!, el trabajo con Frameworks para PHP, nos acostumbra a trabajar con estas y muchas otras normas que se proponen a nivel de Seguridad, CVS y el aprovechamiento del ORM(Object-Mapping-Model), dejo aqui algunos de los mas famosos: [Symfony: http://www.symfony.es, CakePHP: http://www.cakephp.org/, Zend: http://framework.zend.com/ y el orgullosamente Colombiano Kumbia:http://201.245.53.58:81/Kumbia, Digo Orgullosamente por que yo soy Colombiano !.

PD: La mayoría ya tiene una documentación completa en español y posiblemente si no están familiarizados con los Frameworks se darán cuenta que nos hace ordenar mucho los proyectos Orientados a Objetos o a Servicios.
Por: vanvanero_blog

public function foo($param1)
{
// Operación
}

public function foo2($param1, $param2)
{
// Ejecuta una operación muy parecida a foo pero con 2 argumentos
}

public function foo($param1)
{
// Operación
}

public function foo2($param1, $param2)
{
// Ejecuta una operación muy parecida a foo pero con 2 argumentos
}

public function foo()
{
// Operación
}
public function foo1($param1)
{
// Operación
}
public function foo2($param1, $param2)
{
// Operación
}

public function foo($param1, $param2="")
{
    // Operación
}

F, para el ejemplo que da Maikel, esa (la tuya) es una solucion correcta.

El punto 9 se basa en no repetir metodos por falla de logica, pero si quieres implementar sobrecarga de la manera tradicional, se debe repetir el nombre de la funcion seguido de la cantidad de parametros.
No quiero desviar el post... pero a PHP 5 le falta un poco de POO todavia
Por: Dientuki

Maikel :

La versión de la clase que está publicada no la hice yo, solo hice el tutorial... Además el autor y yo comulgamos e hicimos varias mejoras ( una fue la corrección de ese bug que mencionas), pero debido a que no tenemos mucho tiempo libre no hemos publicado nuevas versiones.

saludos

kbr0n de cuando acá tan diplómatico? "el autor y yo".
Por: Dano

Tmeister :

Una duda el punto 7 es Hacer o NO hacer pruebas unitarias

Buenos tips.

El error es NO HACER pruebas unitarias.(recuerda que el tema es 10 errores al programar en OOP),

Tienes que hacer pruebas unitarias a las clases.


Por: Dano

<?php

include_once( dirname(__FILE__). "/Clase2.php"); // mismo directorio
include_once( dirname(__FILE__). "/../Clase2.php"); // directorio superior
include_once( dirname(__FILE__). "/lib/Clase2.php"); // directorio inferior

class Clase1 extends Clase2
{
}
?>