[Ambar-dev] Re: Minë

[Andres Moya]

El jue, 07-11-2002 a las 19:27, Gabriel Pulido de Torres escribió: 

> Hola Andrés, ¿como va todo?, yo por aquí trabajando mucho en el editor
y te quería comentar un par de cosillas ahora que me he tenido que
remangar para mirar bien el código de sala.py. Te lo comento por aquí
porque es algo sobre programación y no creo que sea adecuado para la
lista :)

Hay una lista sólo para programadores, es recomendable que te apuntes
porque ahí es donde hablamos de este tipo de cosas: 

http://mail.nongnu.org/mailman/listinfo/ambar-dev

Pongo esto en copia a la lista porque también le interesa a los otros.


> A ver, para poder "editar" las salas, me he acabado creando una clase
nueva que hereda atributos de la clase Sala (realmente extiende la clase
sala) y en la cuál le estoy metiendo métodos de modificación de los
atributos y métodos para "imprimir" a fichero toda la información, con
ello consigo no tener que tocar la original y sólo habrá que poner mi
clase en el mismo directorio donde esté la sala (en principio , luego ya
se verá).

Si, no es mala idea, porque esos métodos de modificar sala y de guardar
sólo se usan en el editor. Es útil tener dos clases separadas.


> Lo que te quería decir es que a mi parecer no se está usando para
nada, ya que python lo favorece cosa que no me gusta demasiado, la
posible "privacidad" de los datos y la modularidad de la orientación a
objetos, por lo menos con estas clases. Esto es, para poder acceder a
los atributos de la clase sala.py tengo que saber exactamente como se
llaman los atributos y tocarlos directamente, lo cual es muyyyyyy
peligroso y hace que el código sea casi imposible de mantener en un
futuro si da la casualidad (que creo que se dará porque cada vez hay más
atributos) de que se cambia el formato de la clase sala.

Conozco perfectamente ese problema, soy consciente de ello desde el
principio. Ciertamente el Python no favorece mucho la ocultación o
encapsulamiento de los datos (que es como se llama lo que dices), pero
si que lo permite, lo que pasa es que hay varias formas de hacerlo. Yo
he ido experimentando varias hasta que he encontrado una aceptable.

Al principio usaba un método especial __setattr__, que llama Python cada
vez que alguien hace variable.atributo = valor (lo puedes ver en la
clase personaje.py). Con esto se pueden interceptar las asignaciones y
rechazar o filtrar lo que haga falta, pero acaba siendo muy farragoso,
así que lo dejamos de usar.

Al final, he decidido lo siguiente: Python permite declarar miembros
privados, poniéndoles delante un doble subrayado (__). Entonces todos
los datos miembros serán privados, y para los que deban verse desde
fuera definiremos una función de acceso para leer, y si es necesario
otra para escribir. Así nadie puede acceder directamente a los datos,
sólo a copias, y todos los accesos de escritura pasan por un único
punto. Ejemplo:

  class EjemploAtributos:
    """Clase para demostrar uso de atributos.

    Atributos:
     - __atrib1 (int): un numero del 1 al 100
     - __atrib2 (string): un texto

    Invariantes:
     __atrib1 in range(1, 100)
     __atrib2 != None
    """

    def __init__(self):
      self.__atrib1 = 1
      self.__atrib2 = "hola"

    def atrib1(self):
      """Asegura: return in range(1, 100)"""
      return self.__atrib1

    def atrib2(self):
      """Asegura: return != None"""
      return self.__atrib2

    def poner_atrib1(self, valor):
      """Requiere: valor in range(1, 100)"""
      self.__atrib1 = valor

  # Ejemplo de uso
  ejem = EjemploAtributos()
  print ejem.atrib1()
  print ejem.atrib2()
  ejem.poner_atrib1(14)
  ejem.poner_atrib1(5034534) # ilegal
  ejem.atrib1() = 7          # sin efecto
  ejem.__atrib1 = 10         # error de ejecución

Se puede hacer de otras maneras, pero yo pienso que en Minë se va a
quedar así. Lo malo es que cuando decidí este sistema ya había mucho
código escrito. Todo lo nuevo lo estamos escribiendo así (fíjate en los
dos últimos atributos de personaje.py), pero poco a poco hay que ir
cambiando lo anterior. Si te animas a colaborar...


> A ver si me explico, si en vez de acceder directamente a los
atributos, la clase sala me proporcionase métodos para acceder a ellos,
yo no tendría que saber nada de como está "parseada" la sala, o de como
está almacenada en memoria y si se modifica, sólo habría que modificar
los métodos de acceso y no todas las clases que accedan a esos datos
(que creo que son unas cuantas en el programa). Esto parece ahora una
chorrada, pero se puede convertir en una bola de nieve gigantesca y al
final no se tendrán ganas de arreglarlo y será un "monstruo".

Veamos. El cómo está parseada la sala si que está oculto, todos los
métodos de parseo son privados y no dejan ningún rastro público una vez
terminado.

En cuanto a la estructura en memoria, hay varios temas. Por un lado,
todas las estructuras de tipo {String:any} son equivalentes a una clase
con atributos. Por ejemplo, en vez del atributo encuentros tal cual,
sería más "ortodoxo" declarar una clase Encuentro con los atributos id,
probabilidad, maximo, dificultad y descripcion, y declarar el atributo
encuentros de salas como array de Encuentro. Esto a lo mejor lo hacemos
algún día, pero de momento así queda bastante compacto.

Y por otro, efectivamente sería mucho mejor dejar todos esos atributos
como privados y usar métodos para realizar operaciones sobre ellos. Si
te fijas, ya hay varios métodos de ese tipo: entrar_personaje,
coger_objeto, salida_cerrada, etc. Pasa lo de antes, al principio no lo
hicimos así, y aunque todo lo nuevo ya va de esa manera, habrá que ir
cambiando el código antiguo.

Aun así, probablemente habrá que dejar funciones de acceso que devuelvan
una copia de las estructuras, para poder leerlas pero sin modificarlas.



> Otra cosa, el parseado de la sala a partir del xml es algo "chapuza"
ya que por ejemplo depende del orden en que coloques las cosas en el
fichero (las descripciones antes que las salidas y cosas así). No se
atiende a la estructura "lógica" del fichero xml sino solo a la
estructura "física", y es algo extraño pq si en vez de preguntar por el
childNode[n] preguntas por el getTagByName["pepito"] (o algo así) no se
tendrían esos problemas. Estoy intentado revisar la información que
tengo sobre el minidom pero es escasa y un poco mareante así en frío,
creo que habría que hacer una depuración de las clases básicas de
información (sala.py, pnj.py, cualquier cosa en xml) y proporcionarles
métodos de acceso a los datos, métodos de modificación/eliminación y de
grabar a fichero. Es curioso pq la estructura "lógica" es muy buena pero
creo que se está desaprovechando, o está provocando que, por ejemplo, yo
tenga que trabajar mucho más de lo que debería ;)

Efectivamente, el parseado se puede mejorar. No te preocupes mucho por
el tema, que me lo estoy estudiando yo ahora. Mi próximo paso va a ser
precisamente implementar la lectura de los PNJs desde un descriptor, y
voy a escribir un código más avanzado, que luego se podrá aplicar a las
otras clases.

El problema básico es que este es nuestro primer proyecto en Python, y
estamos aprendiendo cosas sobre la marcha (una cosa es programar y otra
programar "bien" :) Y hemos "refactorizado" mucho código (antes estaba
aun peor O:), pero como nuestro tiempo es muy limitado, no damos abasto
a ponerlo todo perfecto, porque si no, no meteríamos nunca
funcionalidades nuevas, que es lo que más interesa.


> Por ahora nada más, una cosa, las críticas son constructivas y con
ánimo de mejorar, sólo es mi opinión después de haberme peleado un rato
ya con el código y como programador, no os lo toméis demasiado mal ;)
(yo tb hago código de ese tipo cuando voy con prisa o cuando empiezas
con algo, pensando que ya lo arreglarás pero al final pasa lo que
pasa...) Coméntame lo que pienses al respecto :)

No te preocupes, aquí somos aficionados a las críticas constructivas :)
Yo mismo tengo frito al pobre Pablo con sugerencias de estas todo el
tiempo...


> Venga nos vemos, un abrazo
> Gabi (y sigo con lo del nombre ;) )

Idem.

Hirunatan