Agregar comunidad a un videojuego
Un articulo que presenta muchas opciones bastante interesantes para agregar elementos que generen comunidad alrededor de un videojuego. Algunas son “un poco” impracticables, y en varias es importante tener en cuenta que hay que asesorarse en cuanto a las cuestiones legales de implementarlas, en especial a todo lo que pertiene a contenido generado por los usuarios (recordar cosas como lo que se conoce como “sporn”… a veces el costo de mantener a una comunidad a raya es mucho más de lo que se puede ganar con ella).
Singletons en Actionscript 3
Este no es un tema nuevo, de los patrones de diseño se habla a montones en la blaahgosfera, y actionscript no queda fuera del campo de interés de quienes ven en los patrones de diseño una buena herramienta para no andar reinventando la rueda en cada proyecto. También es conocida una situación particular del lenguaje actionscript que causa ciertas molestias en algunos puristas, la imposibilidad de declarar como privados a los constructores de una clase.
Para hacerla corta, para un patrón de diseño de construcción, como por ejemplo el Singleton, conviene dejar fuera del alcance del resto del sistema el manejo de su construcción, o sea, siguiendo el ejemplo, para un singleton debería existir solo una única instancia, pero si otras piezas del sistema tienen acceso al constructor del singleton ¿quién te asegura que nadie intente crear una nueva instancia?
En general veo dos posiciones, la de los puristas que chequeen en runtime que el objeto no instanciado externamente, añadiendo un flag parche y causando una excepción si este flag indica que no se está instanciando el objeto como se debe. Y la otra posición es la de los que les importa un bledo, y si instanciaste el singleton es problema tuyo por no saber que no se instancian los singletons.
Ahora, existe una tercer postura, la mía =P
Volviendo a ponernos serios, no es realmente conveniente asegurarse que un singleton mantiene su cualidad de tener una única instancia haciendo la validación en runtime antes mencionada. Primero, ensucia el código, el flag parche no tiene otro propósito que ser un workaround para una condición del lenguaje. Segundo, estos problemas deberían detectarse siempre en la compilación, no hay razón para delegarlas al runtime.
Lo más interesante es que realmente se puede hacer singletons en actionscript 3 cuya construcción sea inaccesible para los otros componentes del sistema, y de esta manera controlar que se cumpla la condición de única instancia. Asimismo se puede aplicar otros patrones de diseño de construcción manteniendo inaccesible la construcción, aunque con algunas vueltas de tuerca.
Para esto lo que se hace es separar el patrón en 3 partes: la interfaz, la implementación y el acceso. Para el caso del Singleton tenemos una interfaz al objeto que es singleton, que es pública y abstracta, una implementación que es el objeto singleton en cuestión, que es privado, y el acceso que es la forma en que accedemos a la instancia singleton.
La interfaz es justamente implementado como un interface que expone los métodos y atributos del singleton. El interface nos abstrae de la implementación y no nos da acceso a la construcción del mismo. La implementación la declaramos como internal, de manera que es solo accesible desde dentro del mismo paquete, no solucionamos realmente el problema pero lo limitamos considerablemente (al paquete del singleton).
Finalmente queda la cuestión de como proveer el acceso a la instancia singleton. Una opción simple es tener una constante dentro del paquete para dicha instancia, pero esto puede ser complicado a la hora de ponerle nombres a los símbolos (porque en muchos casos resulta coherente usar el mismo nombre para la constante y para la interfaz). Otro opción es dar acceso al singleton desde otro clase, ya sea una que por el modelo de datos funcione como contenedor, o una clase de utilidad que solo cumpla la función de dar acceso a uno o más singletons.
En un proyecto en google code que tengo para este tipo de cosas, subí código para ejemplificar esto.
En el mismo se puede ver, por ejemplo, la implementación interna de un singleton de configuración, la interfaz que expone este singleton al resto del sistema, y el acceso a dicho singleton mediante una constante.
A primera vista puede resultar molesto tener que mantener estas tres partes por separado, pero a la larga uno empieza a notar los beneficios de resolver este tipo de situaciones desacoplando interfaz e implementación. Por ejemplo, si uno usa una IDE con code-hinting, al usar una interfaz en lugar de la implementación, la IDE te sugiere unicamente aquello expuesto por la interfaz, lo cual resulta sumamente útil para filtrar todo aquello que nos hubiera sugerido de haber usado la implementación y realmente no nos interesabe. Esto último sucede en especial con clases cuya herencia es bastante prolongada, y la IDE nos sugiere todo cuanto las sucesivas clases dieron en exponer como público.
