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.
- 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.
Si te interesó el artículo, te interesará leer los 21 errores comunes programando en PHP y las reglas de codificación y lineamientos de código en PHP
¿Sabes SQL? ¿No-SQL? Aprende MySQL, PostgreSQL, MongoDB, Redis y más con el Curso Profesional de Bases de Datos que empieza el martes, en vivo.
Por Zguillez el 03 de Julio de 2007
Por Reymond el 03 de Julio de 2007
Muy buen artículo, a muchos nos hacía falta algo como esto.
Por Jatrix13 el 03 de Julio de 2007
Por el 03 de Julio de 2007
queremos un curso tuyo!
queremos un curso tuyo!
Gracias!
Por eldervaz el 03 de Julio de 2007
Por vanvanero el 04 de Julio de 2007
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 Odin el 04 de Julio de 2007
Por Victor-Nael el 04 de Julio de 2007
Por bicho_O el 04 de Julio de 2007
Por babosonico el 05 de Julio de 2007
Por manolo el 05 de Julio de 2007
Por Maikel el 05 de Julio de 2007
manolo_blog :
El punto se refiere a hacer algo como esto:
Código :
saludos
Por Dientuki el 05 de Julio de 2007
Maikel :
manolo_blog :
El punto se refiere a hacer algo como esto:
Código :
saludos
Para la sobrecarga de PHP hay que hacer eso Maikel
Código :
y usar el __call para manejar eso, es la unica manera de hacer una "sobrecarga" como en otros lenguajes.
Fuente
Por Freddie el 05 de Julio de 2007
Código :
Como verás, no es necesario.Por Dientuki el 05 de Julio de 2007
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 vanvanero el 06 de Julio de 2007
Freddie escribió
public function foo($param1, $param2="")
{
// Operación
}
Es una solución que solía hacerse en php 4 y que igual sigue siendo efectiva, en PHP5 puede utilizarse también la función func_get_args(); y si como dice Dientuki PHP todavia le falta cosas para establecerse como un verdadero lenguaje de cuarta generación, pero eso es lo que nos estan prometiendo alcanzar en el no tan lejano lanzamiento de PHP6.
¡Aché pa'ti como aché pa'mi!
Por [url] test[url] el 13 de Febrero de 2008
Por Maikel González el 13 de Febrero de 2008
Y para los que se inician usando un framework, les recomiendo Symfony, el cual está muy bien documentado, véase http://www.librosweb.es, será una guía para aprender otros, pues el mismo no reinventa la rueda, sino que aprovecha las mejores prácticas de otros y las acomoda a su estilo.
---------------------
http://www.htmleando.com
Por keren alexandra el 13 de Agosto de 2008
Por cintia el 13 de Agosto de 2008
Por BENKENOBI el 17 de Noviembre de 2008
Por Gracias y dos coment el 18 de Junio de 2009
En cuanto a la clase Template, dos comentarios:
Primero, en inglés "read" es un verbo irregular, por lo que "readed" es incorrecto, debería ser "read" (aunque supongo que usaste readed para que quedara claro para qué sirve dicha variable).
Segundo. Parece ser que hay un bug, por el cual si usas una plantilla donde aparezca el caracter "'", pero no le pasas un Plantilla::setVars(), quedará formateada la salida en Plantilla:show() con la barra invertida de escape, eso es, \' (y no queremos substituir eso en nuestras plantillas solo porque no usemos setVars).
Como "workaround" al problema lo he solucionando poniendo el siguiente código al inicio de la función show():
if ( $this->vars == NULL )
$this->setVars(array());
Y eso llamará a setVars, aunque no lo usemos, antes de imprimir la salida, para forzar a que nuestros "\'" vuelvan a ser "'" simples.
Saludos!
Iván aka naibed.
Por Maikel el 24 de Junio de 2009
saludos
Por Tmeister el 24 de Junio de 2009
Buenos tips.
Por Mago.ozkuro el 24 de Junio de 2009
Por Dano el 24 de Junio de 2009
Maikel :
saludos
kbr0n de cuando acá tan diplómatico? "el autor y yo".
Por Dano el 24 de Junio de 2009
Tmeister :
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 Paco el 07 de Septiembre de 2009
Tratemos de hacer un código cada vez mejor, programemos orientado a objetos!
Saludos a todos
www.phppoo.freezoka.com/es/
Por Andrés el 08 de Octubre de 2009
¿Cómo puedo solucionar esto?
Por Maikel el 08 de Octubre de 2009
Código :
Con eso basta.
saludos
Por Andrés el 09 de Octubre de 2009
Anda perfecto.
Por Fernando el 13 de Enero de 2012
Después lo de las variables globales e imprimir salidas en los métodos es algo que vi mucho e inclusive hay tutoriales donde se hace eso, que como decís vos le quita la posibilidad de reutilizarla.
Saludos.
Por mortemx el 31 de Enero de 2012
estoy metiendo X (elementos de datos) en un arreglo global ;
use $_SESSION["agregados"] como el array, como rayos puedo precindir de esa variable global dentro de las clases que realice? es obvio que a algun lado deben guardarse el id del producto que agrege y las cantidades que agregue entonces como implementar una solucion sin incluir variables globales a la clase StatusCart que me invente
Por Dientuki el 31 de Enero de 2012
Por Deckertur el 13 de Marzo de 2012
Por elmesiasperdido el 03 de Agosto de 2012
Por Jrodriguez el 18 de Octubre de 2013
Por Maikel el 23 de Octubre de 2013
Saludos
Por gerardo el 19 de Septiembre de 2015
he visto que los hacen al cerrar la } de la clase
Por zeuskx el 19 de Septiembre de 2015