Re: [Ambar-dev] los objetos en Minë

[Andres Moya]

El Domingo 17 Marzo 2002 23:13, Pablo Ruiz Múzquiz escribió:
> > [...] Entonces
> > no es lógico que dentro de un método de sala se hagan tiradas de
> > percepción, por ejemplo. Los métodos de coger y dejar deberían estar
> > hechos de tal manera que quien coja un objeto pueda ser un personaje, un
> > animal, un camión que pase por allí, etc.
>
> Hmm. Estoy de acuerdo pero aparte de la tirada de percepción (que es sólo
> un dato que se pasa como argumento y que todos los pnjs y camiones deberían
> tener asociado en principio) no veo mayor problema en cómo están las
> funciones de coger y dejar objetos.
>
>     def coger_objeto(self, personaje, nombre_objeto, tirada_percep_sala,
> numero=1):
>
>     def dejar_objeto(self, personaje, nombre_objeto, dif=0):
>
> tenemos un parámetro indispensable como es personaje (entrar y salir de
> sala lo tienen), nombre_objeto, que es un parámetro que se pasa desde la
> línea de comandos y que necesariamente procede de dialogonormal.py
> la dificultad y el numero son parámetros lógicos ¿no?
> ¿No crees que si hemos diseñado las salas con objetos con dificultad
> asociada el método de clase de coger o dejar objeto tendrá que importar el
> dato de tirada_percep_sala. No veo por qué un pnj, un cerdo o un camión no
> va a tener que hacer esa tirada automáticamente al entrar en la sala.
>
> Si el diseño es otro entonces ya sería verlo.


Hombre, estas cosas no son absolutas, y suele ocurrir que haya varias formas 
válidas de verlo. Sin embargo sigo creyendo que se mezclan cosas en esos 
métodos que no deberían. Cada elemento lógico debe ser gestionado en un único 
módulo, y cada función debe hacer una única cosa.

La función coger_objeto, tal como está ahora, hace tres cosas: verificar que 
el objeto que se va a coger es visible, retirarlo de la sala y colocarlo en 
el equipo del personaje. Creo que sólo debería hacer la segunda.

Ya que las tiradas de percepción se definen en la clase DialogoNormal, 
hagamos toda la gestión allí. Si, por ejemplo, hacemos el dialogo con el 
jugador de tal forma que sólo se pueda coger un objeto que ves (como lo que 
contabamos el sábado, que si pones "coger a" coges el primer objeto de la 
lista que ves, entonces el chequeo es redundante. Esto es más fácil de ver si 
el chequeo se hace en el mismo módulo que el resto. Si no, cuando esté 
modificando la clase DialogoNormal es fácil que se me olvide que tengo que ir 
a la clase Sala a cambiar cosas. Lo mismo con la otra operación: si más tarde 
modifico la variable "equipo" de Personaje para que sea un diccionario en vez 
de una lista, es fácil que me olvide de ir a sala a cambiar el append por 
otra cosa.

Creo que la verificación de si es visible debería ir en DialogoNormal (como 
ya se hace por ejemplo con las salidas de la sala en el comando mover), y lo 
de añadir el objeto al equipo podría ir en un método de Personaje o 
PersonajeJugador.

En cuanto a los parámetros de la función, las funciones deben tener sólo 
argumentos "propios". Por ejemplo, en entrar_personaje(), el personaje que 
entra es un argumento propio, porque es el "objeto" de la operación. En el 
caso de coger_objeto(), es distinto: el personaje no es el objeto que se 
coge, sino el agente que ordena la acción. Una clase no debería conocer los 
detalles de quien llama a sus métodos. Para mi, coger_objeto() debería tener 
un único parámetro: el id del objeto a coger, y devolver un único valor: la 
instancia del objeto. Y podría ponerse como precondición que el objeto 
exista, así nos evitamos comprobarlo (es probable que el llamante lo haya 
comprobado antes, en cuyo caso sería una comprobación redundante).

Dices también que como los objetos tienen dificultad, eso implica que todo el 
que los coja debe hacer una tirada de percepción. No necesariamente, son dos 
conceptos relacionados pero distintos.

Vaya ladrillo :) La verdad es que tiendo a ser bastante pesado con mis 
explicaciones. Tengo una base teórica bastante gorda, basada sobre todo en 
los libros de un investigador llamado Bertrand Meyer, pero tampoco tengo por 
qué andar echandosela encima a la gente :-P



> Respecto al resto de tu correo:
>
> Ahora mismo tú apuestas por unir las dos listas de objetos, la normal y la
> resumida. Me parece estupendo. La lista final sería algo como:
>
> [ {id:'vino01',probabilidad:0,dificultad:0,descripcion:'Una botella de
> vino',instancias:[123hhg,1234124ggd,wdfsf7343]},{....},{....} ]

Ok, lo único que falta es el máximo. Y sobre la descripción, al final 
quedamos en que iba a ser la misma que la de las instancias de objetos. Creo 
que es mejor quitarla de ahí, y cuando haga falta, cogerla del primer 
elemento de la lista de instancias.


> O sea, la lista resumida actual pero con la probabilidad añadida y el
> sistema de la lista de instancias y el efecto de la probabilidad.
> Además, habría que meter el asunto de la lista cuando un personaje
> entrase en la sala. Es decir, llamar desde entrar_sala a una función
> especializada en calcular nuevas instancias.

Esto no lo entiendo, ¿me lo puedes explicar? Yo no veo que haya que hacer 
nada cuando alguien entra en la sala :-?