[Miner-dev] Sobre metodos estáticos y atributos públicos

[Andres Moya]

Hola, programadores :) 

He estado repasando la documentación de Python, y ya sé cual es la forma
"guays" de escribir métodos estáticos, y también atributos públicos
controlando si dejamos leer y escribir o no. 

Funciona a partir de Python 2.2. Técnicamente me parece una solución
bastante buena, el único problema es que la sintaxis no me gusta mucho,
me parece un poco fea. Aun así, creo que es bueno que nos planteemos
hacerlo así. Además, dicen que para el próximo Python 3.0 buscarán una
sintaxis mejor... 

En primer lugar, hay que declarar las clases del estilo "nuevo", lo cual
significa hacer que deriven de "object". Y luego, para hacer métodos
estáticos sería: 

  class UnaClase(object): 
  
    def calculo():   # notar que no lleva self 
      return 10 * 6 
      
    calculo = staticmethod(calculo) 


Se llaman como cualquier método estático: x = UnaClase.calculo() 


Para declarar atributos públicos, se escriben los métodos "getter" y
"setter" (si es aplicable), y luego se declara una "property": 

  class Rectangulo(object): 

    def __init__(self, x, y): 
      self.__x = x 
      self.__y = y 

    def get_x(self): return __x 
    def set_x(self, x): self.__x = x 
    x = property(get_x, set_x, doc="coordenada horizontal") 

    def get_y(self): return __y 
    def set_y(self, y): self.__y = y 
    y = property(get_y, set_y, doc="coordenada vertical") 

    def get_area(self): return __x * __y 
    area = property(get_area, doc="area del rectangulo") 

Las "properties" se acceden igual que si fueran atributos públicos, pero
el acceso pasa siempre por los métodos que hayamos definido: 

    r = Rectangulo(5, 4) 
    print r.x, r.y, r.area 
    r.x = 10 
    r.y = 8 
    print r.x, r.y, r.area 
    r.area = 100 # Esto da error porque no hemos definido set_area 

Notar que no es imprescindible almacenar el valor en un atributo
privado, que los accesos pasan siempre por las funciones aunque no
pongamos (), y que podemos definir si queremos que se puedan escribir o
no. 

¿Qué os parece? ¿Usamos este sistema? Aquí os mando cómo quedaría la
clase Sala transformada. En realidad no es mucho más "feo" que lo de
definir las variables de esta manera (como lo estamos haciendo en las
clases nuevas): 

   class Rectangulo: 

    def __init__(self, x, y): 
      self.__x = x 
      self.__y = y 

    def x(self): return __x 
    def set_x(self, x): self.__x = x 

    def y(self): return __y 
    def set_y(self, y): self.__y = y 

    def area(self): return __x * __y 

La ventaja es que el uso es en forma r.x en vez de r.x(), que es un
futuro estándar, y que es más fácil que sea procesado por herramientas
(por ejemplo, el generador de UML del Boa Constructor, cuando implemente
esto). 

A ver qué opinamos. 

--- 
Hirunatan, "language lawyer"...

sala.py
Description: application/python