Tras escuchas un sinfín de historias para no dormir, en lo relación a módulos de “informática” donde se programa sin un PC y se compila con la mente, me veo en la obligación de contar “mi mierda”, a pesar de no haber sacado plaza cuando Steve Jobs lucía melena. Así que hoy os traigo mierda de la buena: bienvenidos al mundo de la programación por objetos, impartido por Mr. Orange, un señor que no sabe programar.
El ejemplo más cercano a lo que es un «objeto» o una «entidad» en un entorno de programación del mundo real, o al menos, para todo lo real que es el mundo para un jugador de RPG, es una hoja de personaje.
Es sencillo. ¿Qué es una hoja de personaje? Es un papel, una plantilla, donde vienen ciertos datos a rellenar, que definen a tu personaje en una partida de D&D, por ejemplo, todos sois personajes. Pero no todos sois lo mismo. Simplificando la ficha, para no perder demasiado tiempo, pongamos un juego donde el personaje escribe: nombre, clase, fuerza, destreza, magia.
Así que empieza el juego. Tenemos tres jugadores. David va a ser Sidi, un poderoso guerrero barbado (que no bárbaro). Apunta en su hoja nombre: sidi, clase: guerrero fuerza:10 destreza:6 magia:1. Guillermo va a ser Lockhart, un picaro vividor, y en su hoja apunta nombre: lockhart clase: picaro fuerza:5 destreza:10 magia:2 y por último, Norberta Lionheart va a ser la exótica hechizera klausis, y apunta en su ficha nombre: klausis clase: mago fuerza:4 destreza:4 magia:10
Muy bien. Partiendo de esa clase, todos esos personajes son objetos o instancias de un objeto, como prefieras llamarlos. La ficha de personaje es la «clase», es la definición, es el código que escribes. Los personajes son instancias de esa clase. Implementaciones de los datos.
Piénsalo. Cuando tú tecleas un código para que haga «algo» en un lenguaje por objetos, lo que quieres es un programa que, recibiendo diferentes datos, arroje resultados diferentes. Lo que tú realmente piensas cuando dejas C u otro lenguaje estructurado y pruebas uno por objetos es «vale, estoy cansado de andar escribiendo un código cada vez que el ordenador tiene que calcular algo. Quiero hacer algo que me permita DEFINIR un algoritmo, una operación concreta, para poder hacerla siempre».
Pues resulta que, en un ámbito totalmente diferente, antes de que los lenguajes por objetos empezasen a popularizarse, el enorme Gary Cygax dio con una solución a un problema (a grandes rasgos, un RPG es también la esencia de un algoritmo: simular, mediante números, un mundo de fantasía) muy similar. El quería un juego donde un jugador pudiese desempeñar diferentes roles, enfrentarse a diferentes problemas, y tener resultados diferentes cada vez, pero no de forma totalmente aleatoria, sino con un peso por parte de sus estadísticas.
Así, nuestros jugadores, David, Guillermo y Norberta se han creado todos un personaje. Tienen la misma ficha… pero no tienen las mismas estadísticas. Entonces, se encuentran un peligro. Y tienen que tirar: tiran por fuerza, por ejemplo, tiran 1D10 y añaden el resultado a su fuerza. Si todos sacan 5 (raro, pero posible) y la dificultad era 10, Sidi superará la prueba (era imposible que no), Lockhart la pasará por los pelos, y Norberta no la superará.
Ahora imagínate el potencial de esa idea aplicada a la programación: coger una serie de objetos, de datos, que responden a las mismas reglas y que van superando las mismas pruebas. Imagínate un programa para simular coches. Los objetos coche, todos ellos pueden usar la orden arrancar, acelerar, virar, etc… pero no dan los mismos resultados. No, algunos tienen un motor v6, otros un motor v8, con transmisión deportiva, sin ella, de más peso, de menos peso…
Crear un objeto es una gran ventaja porque te permite definir un subprograma y llamarlo cuando lo necesites, sin grandes implementaciones. Si dentro de un simulador de carreras necesitas saber la aceleración de un coche, introduces los datos en un nuevo objeto coche y le pides .aceleracion();
Imaginemos que queremos un objeto de una hoja de personaje. Imagina que las salvaciones dependen del valor de salvación + el atributo de fuerza. Escribes una función salvación…
int salvacionFuerza()
{
return salvacionBase + fuerza;
}
y puedes usarla en más funciones. Por ejemplo, en superar salvación. Le das la dificultad, y le das la tirada…
bool pasarSalvacionFuerza(int tirada,int dificultad)
{
return (salvacionFuerza() + tirada) > dificultad;
}
Ahora fíjate en el potencial. Si tuvieses en tu ordenador varios objetos creados, con los datos de tus jugadores, varias «hojas» de personaje en memoria, vaya, ¿Qué harías si quisieras ver si el ataque de uno supera la salvación de otro?
Pues cruzar los datos de tipo
//primero se usaria un valor aleatori para hacer la tirada.
tirada = dados(1,10);
//y luego
if (lockhart.pasaSalvacionFuerza(tirada,sidi.fuerza)) {lockhart.experiencia +=2;}
¿Qué sucede? Puedes seguir liando la madeja. Puedes meter en una lista, un array u otro tipo de colección a los jugadores, hacer que rellenen sus datos en una hoja colgada en el ordenador o en internet, almacenar esos datos y hacer que el ordenador los seleccione de las listas cuando los necesite. Como hace un juego on-line, cuando golpeas a otro personaje, yéndose a la base de datos, recuperando los datos de la dicha, creando un objeto para hacer todas las operaciones, calculando su defensa, debilidades, etc, decidiendo que le quita 30 pv, modificando la entrada de la base de datos y siguiendo con el juego.
Así que un objeto, al igual que una hoja de personaje, te permite definir unos parámetros. Cuando tu les das una hoja de personaje a tus amigos, lo que en realidad les estáis diciendo es «hey, sé que tenéis mucha imaginación todos, pero aquí no venimos a hacer lo que nos apetece. Todos tenemos las mismas reglas y todos nos ceñimos a ellas, rellenamos los mismos datos y todo lo hacemos con esos datos. Todos somos personajes»
Un objeto coche, un objeto moto, un objeto gorrión, son lo mismo. Tienen los mismos datos, juegan con las mismas reglas. Al principio puede chocarte. No crees necesitar una clase para calcular el radio de una circunferencia, pero… ¿Y si tu clase no solo calculase radios, sino TODOS los cálculos matemáticos que normalmente usas? ¿Y si los usases cientos de veces en tu código? Entonces, sin objetos, seguramente sería demasiado complicado hacerlo.
Un objeto funciona de forma muy sencilla si entiendes eso. Si entiendes que, en principio, ESTO es el esquema de un objeto simulando lo más parecido a un objeto del mundo real.
public class ficha
string nombre;
string clase;
int fuerza,destreza,magia,hp;public ficha(string _nombre,string_clase,int _fuerza,int _destreza,int _magia)
{
hp = 20;
clase = _clase;
nombre = _nombre;
fuerza = _fuerza;
destreza = _destreza;
magia = _magia;
}//determina si un golpe se ha acertado
public bool golpear(int tirada, ficha enemigo)
{
if(tirada + destreza > enemigo.defensa())
{
return true;
}
return false;
}//devuelve la defensa base: destreza + 10.
public int defensa()
{
return destreza +10;
}//recibe daño
public void dañar(int daño)
{
hp -= daño;
}//decide si provoca o no daño en un enemigo
public void atacar(ficha enemigo,int tirada)
{
if(golpear(tirada,enemigo) enemigo.dañar(fuerza);
}
Supongo que te habrás fijado… ¿Por qué algunos métodos son para atacar, y otros para recibir? ¿No es lioso? No, son métodos. En una acción real, unos personajes atacan, otros defienden, y viceversa. En un sistema por turnos, sidi.atacar (12,lockhart); lockhart.atacar (8,sidi); y si sigues los cálculos, verás cómo se van comprobando las estadísticas y dañándose el uno al otro.
Hasta aquí la explicación de que es básicamente un objeto. Quizás otro día lo aplique a un XML y como utilizarlos dentro de un código (y más aún, de forma razonable, no como muchas veces se hace) pero como carezco de plaza alguna que me motive a reciclarme y dar lo mejor de mí, se lo dejo a esos héroes anónimos que dan clase de manera desinteresada sin usar PC alguno. ¡VIVA HONDURAS!
