design-nation.blog/es

Vamos a ver un ejemplo de cÛmo podrÌa implementarse el patrÛn State, para realizar juegos con lÛgica compleja y / o reactiva, teniendo en cuenta que la implementaciÛn es bastante relajada, y que el ejemplo que se presenta es tan sÛlo eso, un ejemplo, lo suficientemente sencillo para poder ser explicado en unas pocas lÌneas, pero lo suficientemente complejo para que empiece a merecer la pena el considerar implementar este patrÛn. Obviamente, cuanto m·s complejo sea el comportamiento del juego y / o de sus entidades, esta opciÛn cobrar· m·s cuerpo.

Manos a la obra. Primero veamos quÈ es el patrÛn State.

Del libro "Patrones de diseÒo" ( Gamma et al, Addison Wesley, Madrid, 2003 )

"Permite que un objeto modifique su comportamiento cada vez que cambie su estado interno. Parecer· que cambia la clase del objeto"

Aplicabilidad: ⁄sese el patrÛn State en cualquiera de los siguientes dos casos:

1.- El comportamiento de un objeto depende de su estado, y debe cambiar en tiempo de ejecuciÛn dependiendo de ese estado.
2.- Las operaciones tienen largas sentencias condicionales con m˙ltiples ramas que dependen del estado del objeto.[Ö]. El patrÛn State pone cada rama de la condiciÛn en una clase aparte. Esto nos permite tratar al estado del objeto como un objeto de pleno derecho que puede variar independientemente de otros objetos".

Dicho en otras palabras, lo que vamos a intentar es describir el comportamiento de un objeto como una colecciÛn de estados, de manera que sea el propio objeto el que maneje su comportamiento mediante transiciones de un estado a otro.

Dicho asÌ, no hay quien lo entienda, pero vamos a intentar ilustrarlo con un ejemplo.

Imaginemos que tenemos que hacer un juego: "Explota la pelota". La especificaciÛn del juego es la siguiente: se nos presentar· un n˙mero indeterminado de pelotas en pantalla, que rebotan en el suelo sin pÈrdida de energÌa, y que no rebotan en las paredes ( es decir, si se salen por la derecha de la pantalla, han de volver a aparecer por la izquierda ). Tenemos un tiempo m·ximo para explotar un n˙mero determinado de pelotas ( haciendo clic con el ratÛn sobre ellas ). Al explotar una pelota aparecer· otra, de manera que siempre habr· el mismo n˙mero de pelotas en pantalla. La posiciÛn y velocidad inicial de las pelotas es aleatoria. Si no explotamos un n˙mero mÌnimo, perdemos. Si lo conseguimos, se nos ofrece terminar el juego con la puntuaciÛn actual, o volver a intentarlo, pero con menos tiempo y teniendo que explotar un n˙mero de pelotas mayor. AsÌ hasta que nos plantemos o perdamos.

A bote pronto ( valga la expresiÛn ) tenemos dos entidades claramente diferenciadas: el universo del juego, y la pelota en sÌ, luego parece lÛgico pensar que debamos estructurar el juego en dos clases, una que maneje la lÛgica del juego ( que se encargue de colocar las pelotas en pantalla, compruebe si se han explotado las suficientes, si queda tiempoÖ ), y otra que maneje el comportamiento de la pelota. Vamos a fijarnos en Èsta ˙ltima.

Evidentemente, la pelota se va a representar con un MovieClip. Luego podemos pensar que lo lÛgico serÌa crear una clase Pelota que extienda de MovieClip, y sobrescribir el onEnterFrame, de manera que ese mÈtodo se encargue de chequear la posiciÛn de la pelota en cada frame, haga el chequeo de colisiÛn con el suelo, compruebe si la pelota se ha salido de la pantalla por alguno de los lados, y que coloque la pelota dependiendo de esas circunstancias ( dicho de otra forma, que implemente un mecanismo para manejar la ecuaciÛn de movimiento de la pelota ), que detecte cu·ndo se ha hecho click en la pelota y se lo notifique al universo del juego, que maneje la animaciÛn de explosiÛn de la pelota, etcÖ.

…ste no creo que sea ni el momento ni el lugar para discutir sobre si ese enfoque puede considerarse el m·s apropiado o no. Partamos de la base de que no hay una forma correcta y otras incorrectas de hacer las cosas. Pero ve·moslo con espÌritu crÌtico.

Por un lado, vamos a tener una clase con una abanico de responsabilidades muy amplio ( desde comportamientos fÌsicos a mera presentaciÛn ). Eso es lo que se denomina baja cohesiÛn. Dicho de otra forma: "zapatero, a tus zapatos".

Adem·s, el comportamiento de la pelota se deber· implementar como un enorme switch o una larga serie de sentencias if ( si ha rebotado con el suelo, haz esto; si te has salido por alguno de los lados, haz esto otro;Ö.. ). Bueno, pues, esto, precisamente, es uno de los casos que se ponen como ejemplo de "Èste es el momento para implementar un state". Sobre todo teniendo en cuenta, que aunque Èste no sea el caso, el comportamiento de la pelota podrÌa ser reactivo, es decir podrÌa tener que cambiar a lo largo del juego ( cambia el rozamiento con el aire, las propiedades din·micas del rebote, etc ).

Por hoy es suficiente. En breve veremos lo que es una m·quina de estados, y cÛmo implementarla.