¿Abuso de POO?

[danihxh]

Buenas, consultando un libro de POO PHP me he encontrado con un ejemplo en el que se crea un blog y se utilizan diversas clases para manipular toda la información de la base de datos, pero no le acabo de ver la utilidad.

Por ejemplo, se crea una clase "articulo" con las propiedades id, título, texto y fecha y los métodos insertar, eliminar, modificar, cargar y visualizar.

El motivo por el que no le encuentro sentido es porque por ejemplo, en una página que muestre un artículo al usuario, se crea un objeto "articulo", se llama a "cargar" pasándole el ID del artículo deseado y luego se llama a "visualizar" para que lo imprima por pantalla mientras el resto de código de la clase: insertar, eliminar y modificar se ha cargado para nada, porque un usuario normal jamás los va a utilizar.

De todas maneras, creo que el simple hecho de crear un objeto, cargar la información de la base de datos en él y luego mostrar su contenido por pantalla ya es un abuso, ya que se podría insertar directamente el código PHP (o hacerlo con include/función para tenerlo todo mejor organizado) que cargue la información de la base de datos y la muestre, sin gastar memoria en las propiedades ni en los métodos del objeto que, al menos a mi parecer, tan sólo añade un paso intermedio entre la base de datos y el usuario.

Ya sé que del tema POO ya se ha hablado en este foro y en muchos otros, pero aunque en otros lenguajes como Java o ActionScript los encuentro de gran utilidad, en PHP casi siempre los veo poco útiles.

¿Qué pensáis vosotros? El tema lo he puesto porque estoy realizando una web y me ha surgido la duda de si realmente era buena opción utilizar objetos.

[pateketrueke]

Entonces no comprendes nada de organización.

Tu lo quieres ver todo como archivos, carpetas y funciones.

En el mundo real los objetos no representan ningún problema, deberías estudiar mas.

[danihxh]

No digo que los objetos no sean una buena manera de organizar la información, estoy de acuerdo que en ese aspecto es mucho mejor que tener archivos, yo estoy hablando de rendimiento y consumo de memoria.

Yo el ejemplo que he explicado lo veo como si para beber agua la pasas antes por varios vasos diferentes, cuando podrías bebértela directamente de la botella :\

[pateketrueke]

En el mundo real eso es trivial, ¿rendimiento y consumo de memoria?

Optimizar prematuramente es un enorme vicio, y peor si vas comenzando, creer que tener todo en funciones sencillas y/o archivos es menos costoso para el CPU que usar objetos es completamente errado.

Si tuvieras razón entonces la programación orientada a objetos no existiría y todos seguiríamos bebiendo leche directamente de las tetas de las vacas.

[danihxh]

Pero eso es lo que no entiendo, que me digas que "creer que tener todo en funciones sencillas y/o archivos es menos costoso para el CPU que usar objetos es completamente errado" cuando al fin y al cabo la clase tiene las mismas funciones que se deberían usar sin el uso de clases, pero agrupadas, y además vuelca el contenido de la base de datos en unas variables "intermedias".

Otra cosa que he pensado es suprimir esas variables y unir las funciones cargar y visualizar, puesto que siempre se van a llamar juntas, pero a eso tampoco le encuentro mucho sentido porque una clase que sólo contiene funciones tampoco lo veo muy lógico.

[jotaincubus]

Perdón por meterme donde no me han llamado, pero creo que @danihxh no esta pensando con claridad, tu te basas en lo simple de las clases (ya que dices que solo agrupan funciones) pero dime como podrías hacer herencias solo trabajando con funciones? o como podrías utilizar los métodos mágicos solo con funciones ? o aun mas complicado como crearías métodos y clases abstractas a punta de funciones ?

La POO no es solo encapsular en clases funciones, estas tienen muchísimas cosas mas que no estas teniendo en cuenta en este momento...!

Espero que no te enojes, solo lo hago a método de información.

[danihxh]

No digo que sólo agrupen funciones, estaba hablando de ese caso en particular.

Ciertamente las clases pueden hacer muchas otras cosas que en otros casos pueden resultar útiles. Por ejemplo, si en el ejemplo que puse se tuviesen que tratar los datos recuperados de la base de datos de una manera algo más compleja que concatenándoles algunas etiquetas HTML y imprimiéndolos, seguramente sí que sería mejor el uso de clases, pero no es el caso.

Y la herencia te digo lo mismo, en aplicaciones más complejas puede resultar de gran utilidad, pero en casos más sencillos, y más cuándo puedo asegurar que no voy a necesitar crear ninguna clase derivada de otra anterior (cosas del estilo "artículo" -> "artículoAvanzado"), no se le dará utilidad.

[chwc]

bueno yo me meto a la discución, por que tambien me planteo lo mismo,actualmente estoy trabajando con JSON, y lo que pasa es que tengo archivos como listaDeUsuarios.php, etc.. todos los archivos entregan resultados en json y son bastante sencillos, se conectan a la BD, se fijan que usuario esta online ( con el uso de cookies) y realizan la operación correspondiente en Mysql, y devuelven un array en JSON.lo que pasa es que tengo como 20 archivos de estos, que son bastante simples ( deben tener alrededor de 15 lineas de codigo cada uno), ahora si tendria todas estas funciones en un mismo archivo de PHP, podria tener 250 lineas de codigo, pero cada respuesta tardaria mucho mas sabiendo que solo quiero una cosa sencilla.
es asi lo que sucede, o hay algo en PHP que hace como si fuera un "Cacheo" de una clase??
saludos

[pateketrueke]

Tengo una manera de ver las cosas.

Si la aplicación va a crecer en algún punto, es decir, que va a escalar entonces debe diseñarse para que así sea. Usar OOP en este punto es clave, aunque no descarto que una aplicación hecha sin OOP también escale.

Todo depende del diseño del software, si no necesitas OOP no lo uses, no es pecado.

[gjx2]

No me pasa igual, si tengo un método que es posible que lo vaya utilizar solo a el en una clase
pues lo declaro como estático y luego accedo a el sin tener que instanciar la clase.

Hoy en día hacer una aplicación que valga la pena demanda de muchas lineas de códigos y de un orden total, trabajar con clases no es un lujo es una necesidad.

Y digo lo mismo que dice @pateketrueke " si no necesitas OOP no lo uses, no es pecado "

[GatorV]

Justo en el foro de PHP OO hace poco hice una comparativa de una función vs una clase que hacen lo mismo, el resultado, fue que fueron igual de rápidas, y ocuparon lo mismo de memoria.

Ahora sí crees que el simple hecho de incluir una clase va a hacer lento tu sistema, estas equivocado, lo que hace "lento" el sistema es el ejecutar como tal, por lo que si cargas la clase pero no invocas el método, es igual de rápido y consume la misma memoria.

Así que no te preocupes por incluir la clase con esos métodos, no influyen ni alentan el sistema en lo más mínimo ya que no son ejecutados hasta que son invocados en el código.

Saludos.

[danihxh]

Gracias GatorV, eso es lo que quería saber, así que finalmente utilizaré clases en vez de funciones.

Gracias a los demás también por contestar tan rápido! :)

[cluster28]

Yo ahora mismo estoy en una situación difícil. A mí me costó un buen rato entender el concepto de POO. Una vez que lo entiendes no concibes un desarrollo sin esta forma de programar. Por lo menos me pasa a mí.

En un proyecto que estaba en programación estructurada la he pasado a POO. Tirando mucho de objetos. Creo que es la forma correcta, sobre todo después de haber leído el Libro Piensa en Java que es dónde realmente me enteré de POO. Realicé los cambios basándome en lo aprendido en el libro de Java.

Piensa que los objetos no sólo hacen cosas, si no que guardan datos. Son como una variable más que la puedes usar por todo el script. Sirve sobre todo para, con poco código, hacer mucho. Porque todo lo "gordo" que tiene que tienes que hacer, (acceso a base de datos, escribir en ficheros, etc...) lo vas a tener preparado dentro del objeto del script y ya no tiene que hacer includes ni nada por el estilo. Los métodos los tendrás siempre a mano dónde tengas el objeto.

Resulta que ese proyecto que pasé a POO (he tardado más de un año) me lo han rechazado porque consideran que abuso del uso de objetos y que hace saturarse la memoria.

Supongo que no habrá problemas por aumentar la memoria de PHP para que no se llene, no? He comprobado que la vez que más objetos hay creados la memoria de PHP llega a 33Mb.

Ya veo como voy a tener que hacerlo. Creando clases con métodos estáticos con parámetros y que devuelvan tipos de datos de PHP. Vamos, el estilo de funciones de toda la vida, sólo que agrupadas dentro de una clase, la cuál nunca se instancia.

Me gustaría saber si me enfoque en PHP es correcto basándome en el enfoque de Java.

Puedo confirmar que una vez creado el modelos de datos, programar la funcionalidad de la aplicación ha sido muy sencillo.

[oscartt67]

Hola Dani. Pues yo también meto baza..

Cuando pones el ejemplo de articulos con sus propidades y métodos, si das un paso mas, POO cobra aún mas sentido.

Los articulos, familias, almacenes, clientes, pedidos, noticias, ofertas tienen en común:

1. son creados,leidos,modificados y eliminados (CRUD)
2. tienen objetos relacionados: $clsArticulo->clsFamilia->Descripcion
3. tienen un sistema de permisos de acceso
4.......

Fíjate en el código que te dejo a corte de ejemplo. Define una sola clase clsCRUD, que implementa todos los puntos anteriormente dichos (y otras clases). Y si implementas/mejoras un nuevo método en clsCRUD, lo implementas en el resto de objetos.
Con esta simple función, solucionas de un plumazo el mantenimiento de todas las tablas de tu db. Y si alguno és muy especial, extiendes clsCRUD igualmente y sobreescribes sus metodos...

Código PHP:

  
function NewClassTable($pTable,$pId=''){
    if(!class_exists($pTable)){
        $exec="
        class $pTable extends ClsCRUD {
            function __construct(\$cargaId=''){
                \$this->tabla='$pTable';
                \$this->IniVars(\$cargaId);
                }
            }
        ";
        eval($exec);
    }
    $newclass=new $pTable($pId);
    return $newclass;
}  
   

Y otra cosa es la accesibilidad. Sabes lo cómodo que es que el cliente te pida añadir p.ej, el campo 'referencia2' a una seccion y lo único que tengas que hacer es:

1 añadir dicho campo a la db
2 acceder a el con $clsarticulo->clsFamilia->clsSeccion->referencia2

Saludos a todos.