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".

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!!!.


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:


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