miércoles, 25 de agosto de 2010

Objetos Producer-per-Platform

music: THE PRETTY RECKLESS -"Make Me Wanna Die"-

Durante todo este tiempo que he estado sin actualizar he estado realizando unos cambios a nivel de estructura interna del engine e incoporádole algunas cosillas. Una de ellas es la inclusión de una nueva clase de la que heredarán sucesivas clases hijas con las que se crearán un nuevo tipo de objetos: los Producer-per-Platform.

Un Producer-per-Platform es un objeto servidor, encargado de crear y entregar al objeto cliente objetos dependientes de plataforma. Entiéndase por plataforma una parte del sistema o el engine, normalmente situada en lo que llamaríamos "bajo nivel", que puede variar según nuestras preferencias o disponibilidad (S.O., Bibliotecas de creación de ventanas, de audio, gráficas, etc.). Según la clase a la que pertenezca el objeto Producer-per-Platform, éste creará unos u otros objetos "Product" (ventanas, render devices, audio devices, etc.). Y la clase concreta del Product que creará se decidirá, por directivas de preprocesador, en tiempo de compilación.

Debe aclararse, por tanto, que los objetos Producer-per-Platform (desde ahora, Producer) no son los dependientes de plataforma, sino los objetos product que crearán (desde ahora, Product).

La relación entre el Producer y el objeto cliente (desde ahora, Cliente) será de USO, y normalmente adoptará la siguiente forma:

0) El Cliente poseerá, como atributo privado, un puntero polimórfico de la clase de Product que el Producer debe crear.

1) La generación del Product se producirá dentro de un método del Cliente; en la implementación de dicho método el cliente poseerá, como objeto estático local, el Producer necesario.

2) El producer creará el product dependiendo de la directiva de precompilador actualmente establecida para ese Product (estará establecida en la propia implementación del Producer) y entregará el Product en el puntero polimórfico del cliente como valor de retorno.

3) La implementación del método finalizará, y el Producer quedará destruído. El Cliente tiene comunicación directa con el Product a través del interfaz de éste último.

4) La responsabilidad de ordenar la inicialización del estado del Product recae en el Cliente; éste será quien llamará al método Init del Product.

5) Asimismo, la responsabilidad de finalizar la vida del Product recae también en el cliente; éste será el encargado de destruir el Product, liberando la memoria que ocupaba.

Como puede intuirse un Producer NO ES UN MANAGER; es un concepto mucho más sencillo que el de un objeto Manager que carga recursos en memoria, lleva la cuenta de la cantidad de instancias (referencias) de recurso que hay empleadas en el sistema y, cuando el número de referencias de un determinado recurso llega a 0, elimina realmente dicho recurso de la memoria.

a) El Producer surge de la necesidad de crear objetos (Product) dependientes de plataforma. SOLAMENTE en este contexto tiene sentido el Producer. De saber a ciencia cierta que va a emplearse únicamente una plataforma el Cliente generaría el Product de forma directa, sin Producer.

b) Gracias a los Producer tendremos un mayor control sobre el engine sabiendo dónde hay establecidas directivas de preprocesador que determinan compilación para una u otra plataforma: en los módulos del los Producer.

He creado ya un Producer de ventanas que devuelve al Cliente (que en este caso es el Objeto Aplicación) una ventana creada mediante la biblioteca Win32. Ahora podría crearse una clase ventana creada mediante, por ejemplo, la biblioteca GLUT y el mismo Producer de ventanas creará y devolverá a la Aplicación una ventana creada mediante GLUT con sólo cambiar la directiva de precompilación en el Producer de ventanas (de crear ventanas Win32 a crear ventanas GLUT).

El siguiente paso en el que emplear esta técnica es en el render device. A ello voy.

Hasta otra. :P