ambar-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mine-dev] Métodos demodificación de atributos en Sala.py


From: Andres Moya
Subject: Re: [Mine-dev] Métodos demodificación de atributos en Sala.py
Date: 20 May 2003 09:54:11 +0200

El lun, 19 de 05 de 2003 a las 19:35, Gabriel Pulido de Torres escribió:
> A ver, empezando por el uso de self.atributo dentro del mismo parseado de la
> sala en vez del self.__atributo

No entiendo esto muy bien, ¿quieres decir cambiar las clases para que
para acceder a sus propios atributos usen la property, en vez de ir
directamente al atributo privado?

No me parece muy buena idea, en principio, pero no lo tengo muy claro.
Yo de momento dejaría eso como está.


> Luego cuando leemos una descripción del xml (parseandola) llamando a un
> método que es algo así como "addDescripción" en vez de copiar a capón todos
> los atributos ya que así se pueden añadir descripciones de forma coherente
> desde varios sitios aparte del parseado y siempre se hará igual... (y lo
> mismo para las salidas, hummm se me acaba de ocurrir que una sala podría
> cambiar dinámicamente dentro del juego al estilo matrix de ups ya no está
> esa puerta ahi, en ppio puede ser un lío pero puede ser algo interesante en
> la versión n de mine cuando n tiende a un numero bastante grande ;) lo
> siento soy matemático no lo puedo evitar
> Ya se me iran ocurriendo cosas, la idea es añadir funciones que hagan lo
> mismo que bloques de código que se usan a pelo pq en un principio sólo se
> iba a hacer ahi eso específico, pero yo me estoy encontrando de que me será
> más fácil definir funciones que hagan bloques pq comod e todas formas lo voy
> a acabar haciendo pq las necesito así no está el código duplicado...
> No se si me he explicado bien :)

Pues más o menos creo que lo entiendo, habrá que ver caso por caso. De
todas formas, no olvides los consejos de eXtreme Programming, por
ejemplo el YAGNI (You're Not Gonna Need It): haz sólo lo que realmente
necesites ahora, el futuro no lo conoces ;)

http://www.xprogramming.com/Practices/PracNotNeed.html
http://www.xprogramming.com/Practices/xpractices.htm


> Sobre lo de la validación de los datos, lo puede hacer el editor si quereis,
> y poner a sin_tipo o sin_subtipo los valores que estén mal, pero ya me he
> encontrado alguna sala que está mal, alguna de los Retama usa el tipo
> "habitación" que no está definido

Creo que lo suyo es que el editor estuviera hecho de tal manera que no
deje crear una sala mal; y al intentar abrir con el editor una sala
hecha a mano que esté mal, de un error con un mensaje informativo.

Si la carga en el editor la haces con las mismas clases que se usan
luego para cargar los objetos en el juego, me parece bien que el código
de validación esté ahí mismo, y que lance una excepción si hay
inconsistencias (dentro del juego, las excepciones de este tipo están
bien manejadas). En el editor tendrás que manejar también las
excepciones, y dar mensajes al usuario.


> . Estaba pensando tb en sacar a otro
> fichero todas las constantes de ese tipo que necesite el juego... pq a lo
> mejor no sólo en la sala.py se necesita saber todos los tipos de salas que
> hay... 

*NOOOP* Si en algún otro sitio se necesita saber los tipos de salas que
hay, que se vaya a Sala.TIPOS_SALA, que por algo es un atributo de clase
público. No se te ocurra sacarlo a otro fichero... Esta es la esencia de
la OO. :D


> De todas formas las que valido yo son estas mirar si falta algo:
> TIPOS_SALA = { "Población" : [  "calle",    "callejón",     "plaza",
>[...]

Me parece bien, en principio. Si falta algún tipo ya se añadirá.

El caso es que a mí me suena esto de algo. ¿No se había hecho ya en
algun sitio? ¿Será con otra clase? :-?



> Sobre lo de las versiones de la sala, vale a ver si lo entiendo:
> Al parsear se verifica que la version de XML del fichero es la correcta y
> luego se le asigna como "version" al objeto sala la versión de atributos no?
> Ok, entonces yo tengo que imprimir a fichero la versión de XML :) que sólo
> está en una constante y no en ninguna variable del objeto sala creado.

Si, eso, la VERSION_DESC_SALA se guarda en el descriptor de la sala (o
sea, el fichero XML). La VERSION_SALA se guarda en la sala (o sea, la
instancia de clase Sala).

Cuando se crea un fichero nuevo, se le asigna como versión lo que has
leído de la constante VERSION_DESC_SALA.

-- 
Andres Moya <address@hidden>

Contra la guerra global permanente.
Foro Social Mundial - Otro mundo es posible.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]