En cuanto a su estructura, hemos creado una clase llamada “Edificio” y hemos decidido que cada uno de ellos será una clase heredada de "Edificio". Por ello, todos nuestros edificios tendrán unas semejanzas y unas peculiaridades. Abajo os adjunto una captura del editor UML que hacemos servir para definir las clases.
Los edificios están identificados en el árbol de construcción de la anterior entrada con tema “Propuesta de edificios”. Ahora, podemos añadir que todos nuestros edificios funcionarán de una forma similar, todos recibirán algo (mantenimiento) para ofrecernos alguna otra cosa (posibilidades, producción, etc.), podemos ver un diagrama que ilustra esto abajo. Esto se definirá con métodos propios de cada edificio y será gestionado por la aldea.
El problema más grande que nos hemos encontrado a la hora de definir esta parte ha sido el almacén de los datos de cada edificio. Cada uno tiene muchísima información referente a cada uno de los niveles que se puede encontrar (20 generalmente).
Al principio, para que el sistema fuera más flexible, decidimos que cada objeto tuviera su información, pero la naturaleza de nuestra aplicación (tendencia a hacer muchas aldeas) hacia que tuviéramos muchísima información redundante. Por ello, creamos una clase pública y estática que contendrá toda esta información, y cada edificio podrá consultarla cuando lo necesite. Con esto centralizamos la información en una especie de base de datos pública y evitamos repetir información.
En esta ilustración podemos ver claramente como en el primer modelo (ilustrado en la izquierda), los objetos eran pesados y se repetía la información. Mientras que en el dibujo de la izquierda vemos objetitos consultando la clase que contiene los datos.
Saludos
Los edificios están identificados en el árbol de construcción de la anterior entrada con tema “Propuesta de edificios”. Ahora, podemos añadir que todos nuestros edificios funcionarán de una forma similar, todos recibirán algo (mantenimiento) para ofrecernos alguna otra cosa (posibilidades, producción, etc.), podemos ver un diagrama que ilustra esto abajo. Esto se definirá con métodos propios de cada edificio y será gestionado por la aldea.
El problema más grande que nos hemos encontrado a la hora de definir esta parte ha sido el almacén de los datos de cada edificio. Cada uno tiene muchísima información referente a cada uno de los niveles que se puede encontrar (20 generalmente).
Al principio, para que el sistema fuera más flexible, decidimos que cada objeto tuviera su información, pero la naturaleza de nuestra aplicación (tendencia a hacer muchas aldeas) hacia que tuviéramos muchísima información redundante. Por ello, creamos una clase pública y estática que contendrá toda esta información, y cada edificio podrá consultarla cuando lo necesite. Con esto centralizamos la información en una especie de base de datos pública y evitamos repetir información.
En esta ilustración podemos ver claramente como en el primer modelo (ilustrado en la izquierda), los objetos eran pesados y se repetía la información. Mientras que en el dibujo de la izquierda vemos objetitos consultando la clase que contiene los datos.
Saludos
No hay comentarios:
Publicar un comentario