Programacion orientada a objetos (POO), o la odias o la amas, pero debes de comprenderla. Y para comprenderla debes de conocer su objetivo primario, que es la reutilizacion de codigo, simplemente es eso. Un objeto es malo si solo lo usas una o 2 veces, si lo piensas bien facil podrias reemplazarlo por una funcion cualquiera. Te ahorrarias muchos includes o imports dependiendo del sabor en que programes. Pero la POO no esta orientado a mejorar la performance ni la escalabilidad de las aplicaciones.
En aplicaciones Desktop no hay muchos problemas sobre esto, solo es una maquina con un solo usuario, el programador crea todas las clases que quiera y el usuario no va a sentir la diferencia. El aumento de clases y objetos recarga el programa "aritmeticamente".
Un objeto de un 1 KB multiplicado por un yupie usando el sistema desktop, te usa un 1 kb en memoria ram
En Sistemas Web la cosa es diferente, aumenta un objeto por aqui y en un segundo la carga de memoria RAM aumenta en 1 mega. La cantidad de usuarios que maneje el sistema hace que aumentar una clase haga mas lento al sistema de forma geometrica. Una clase mas es igual a 1kb multiplicado por el numero de usuarios del sistema, 100 usuarios = 100KBs y solo por una clase mas!!!.
Un Objeto de 1 kb multiplicado por muchos usuarios es igual a muchos kbs de ram, simple isnt it?Pues bien, actualmente estoy en una fase de optimizar un poco mi codigo. Y bueno se me aparecio un caso perfecto para dar un poco de sentido comun al uso de objetos.
Resulta que mi juego tiene unidades. Cada unidad tiene propiedades, como puntos de ataque, puntos de defensa.. una propiedad llamada attrition que explicare en otra entrada... Mis unidades atacaran otras unidades asi que hice una funcion atacarUnidad() para el calculo del ataque. Lo obvio desktopmente (sic) hablando seria pensar.. "y bueno porque mejor no mejor agrupar toda esa funcionalidad en un objeto:
Con ustedes el posible objeto.Y el objeto unidad ve la luz. El problema de hacer esto es que por cada unidad que exista tendrias que crear un objeto y como los datos estan en la base de datos tendras que hacer varios selects por cada unidad que quisieras crear:
Cada variable que creas en PHP y posiblemente cualquier lenguaje de programacion en web, significa mas memoria RAM y mas tiempo de procesador. Hacer consultas a la BD tambien es relativamente caro. No lo van a notar en una o 10 consultas... lo van a notar va a notar cuando tengan 100 usuarios conectados presionando f5 como chimpances, solo por el gusto de presionar f5.
¿Entonces cual seria una de las posibles soluciones? . Una posible solucion nos lo podria dar el patron de diseño flyweigth. Lo que hacemos es algo asi:
Lo que hace el patron Flyweigth es contener toda la informacion de las unidades en un solo objeto usando arrays para contener todos los datos extrinsecos (osea diferentes, como sus puntos de vida), y variables normales para contener datos intrinsecos (variables en comun de todas las unidades, como digamos el nombre del jugador de esas unidades).
En Teoria ahorramos memoria y procesamiento accesando solo una vez a la Base de Datos para recoger toda la informacion de un solo golpe. Pero en la practica esta solucion no es escalable, la diferencia entre sacar poco a poco la informacion y sacarla todo de un golpes es que consumes mas memoria RAM de un solo tiron, aunque claro harias la aplicacion mas rapida.. hasta que se te acaba la memoria ram y empieza la paginacion en disco duro, que haria mas lento al sistema. Y esto es posible en Sistemas con muchos usuarios, como los Sistemas Webs. Bad.. so Bad.
Hay alguna solucion a este problema? Pues si hay dos soluciones que expondre en un proximo post. No son las mejores pero si que ayudan. Hasta la proxima
"presionando f5 como chimpances" me ha encantado XD , tambien otra funcinalidad importante de la OOP es que acerca la programacion (de proyectos , osea me refiero a pensar como lo vas a desarrollar)a un modo de pensar mas humano , asi que es mas facil organizarlo , de todas formas , yo creo que guardar datos de tus unidades (fuerza , defensa y todo eso) en la bd no es buena idea , ya que (no se como va tu juego) no creo que estos cambien , y si cambian tambien lo podrias solucionar.
A lo que voy , yo veria mas util coger esos datos y guardarlo como globales , o si no haces un include .
Para poner un ejemplo practico , en dexgame , las naves tienen , estructura , escudo y ataque , sumandole los fuegos rapidos que son unos especificos por nave , mas consumo velocidad y velocidad cuando cambia el motor de la nave ( que no son todas , pero como si lo fueran) total que si calculas son como 30 o mas datos , mas luego que pueden cambiar y transformarse devido a tecnologias etc. pues lo que hacemos es que tenemos un archivo que es vars.php donde estan los arrays con todos esos datos , entonces desde common.php le hace un inlude y common es requerido en todos los archivos del juego , asi que siempre tienes acceso a esos datos sin necesidad de hacer querys y demas
Meter todo en un include claro que si eso es valido y muchisimo mas rapido que un SELECT a la base de datos cercana, aunque esa posibilidad es dependiendo del juego. En mi extravagante caso, pues los valores de las unidades si cambian, digamos que le tiran un hechizo que baja el poder de ataque a una sola unidad, entonces la unidad baja su poder de ataque pero eso no se aplica a las demas unidades que compartan su mismo tipo.
Mi solucion temporal fue crear 2 tablas, una para almacenar los valores iniciales de cada tipo de unidad (lo que vendria a ser tu vars.php solo que en tablas de BD) y otra tabla que guarda los valores persistentes de las unidades.
Claro podria poner los valores iniciales de las unidades en un archivo a incluir pero el truco es que en mi juego el jugador podria crear su propio tipo de unidad asi que manipular archivos con el servidor se me hace una patada con alevosia a las partes bajas del ser humano. Asi que BD it is.
Eso si.. tengo un archivo de includes donde meto funciones y muchos DEFINES pero estos los uso mas para limpiar mi codigo de numeros magicos