¿Cómo hacer que las variables de instancia sean privadas en Ruby?

Question

¿Hay alguna forma de hacer que las variables de instancia sean "privadas" (definición C++ o Java) en ruby? En otras palabras, quiero que el siguiente código genere un error.

class Base 
    def initialize() 
    @x = 10 
    end 
end 

class Derived < Base 
    def x 
    @x = 20 
    end 
end 

d = Derived.new 

Answer 1

Como la mayoría de las cosas en Ruby, variables de instancia no son verdaderamente "privado" y se puede acceder por cualquier persona con d.instance_variable_get :@x.

A diferencia de Java/C++, las variables de instancia en Ruby son siempre privadas. Nunca son parte de la API pública, como lo son los métodos, ya que solo se puede acceder con ese getter verboso. Entonces, si hay cordura en su API, no tiene que preocuparse de que alguien abuse de sus variables de instancia, ya que usarán los métodos en su lugar. (Por supuesto, si alguien quiere ir salvaje y tener acceso a métodos privados o variables de instancia, no hay una forma de detenerlos.)

La única preocupación es si alguien accidentalmente sobrescribe una variable de instancia cuando se extienden a su clase. Eso se puede evitar usando nombres poco probables, tal vez llamándolo @base_x en su ejemplo.

Answer 2

A diferencia de los métodos que tienen diferentes niveles de visibilidad, las variables de instancia de Ruby son siempre privadas (desde fuera de los objetos). Sin embargo, las variables de instancia de los objetos internos siempre son accesibles, ya sea desde el padre, la clase hija o los módulos incluidos.

Dado que probablemente no haya forma de alterar el acceso de Ruby @x, no creo que pueda tener ningún control sobre él. Escribir @x simplemente seleccionaría directamente esa variable de instancia, y dado que Ruby no proporciona control de visibilidad sobre las variables, convivir con ella, supongo.

Como dice @marcgg, si no desea que las clases derivadas toquen las variables de su instancia, no lo use en absoluto o encuentre una manera inteligente de ocultarlo de las clases derivadas.

Answer 3

Nunca utilice variables de instancia directamente. Solo use accessors. Se puede definir el lector como público y lo privado escritor por:

class Foo 
    attr_reader :bar 

    private 

    attr_writer :bar 
end 

Sin embargo, tenga en cuenta que private y protected no significan lo que usted piensa que significan. Los métodos públicos se pueden invocar contra cualquier receptor: named, self o implicit (x.baz, self.baz o baz). Los métodos protegidos solo pueden invocarse con un receptor propio o implícitamente (self.baz, baz). Los métodos privados solo pueden invocarse con un receptor implícito (baz).

En resumen, se está acercando al problema desde un punto de vista que no es de Ruby. Utilice siempre descriptores de acceso en lugar de variables de instancia. Use public/protected/private para documentar su intención, y suponga que los consumidores de su API son adultos responsables.

Answer 4

No es posible hacer lo que quiera, porque las variables de instancia no están definidas por la clase, sino por el objeto.

Si utiliza la composición en lugar de la herencia, no tendrá que preocuparse por sobrescribir las variables de instancia.

Answer 5

Sé que esto es antiguo, pero me encontré con un caso en el que no deseaba impedir el acceso a @x, pero sí quería excluirlo de los métodos que usan la reflexión para la serialización.Específicamente utilizo YAML::dump a menudo con fines de depuración, y en mi caso @x era de la clase Class, que YAML::dump se niega a volcar.

En este caso yo había considerado varias opciones

1. Dirigiéndose a esto sólo por yaml redefiniendo "to_yaml_properties"

   def to_yaml_properties 
       super-["@x"] 
   end 
   

   pero esto hubiera funcionado sólo para yaml y si otros volquetes (to_xml ?) no sería feliz

2. Dirigiéndose a todos los usuarios de reflexión mediante la redefinición de "variables de instancia"

   def instance_variables 
       super-["@x"] 
   end 
   

3. Además, he encontrado this en una de mis búsquedas, pero no lo he probado que el anterior parece más sencillo para mis necesidades

Así, mientras que éstos pueden no ser exactamente lo que el PO dijo necesitaba, si otros encuentran esta publicación mientras buscan la variable que se excluirá del listado, en lugar de acceder, entonces estas opciones pueden ser valiosas.

Answer 6

Existen dos elementos diferentes de este comportamiento. La primera es almacenar x en un valor de solo lectura, y la segunda es protegiendo el getter de ser alterado en subclases.

---

de sólo lectura valor

Es posible en Ruby para almacenar los valores de sólo lectura en tiempo de inicialización. Para hacer esto, usamos el comportamiento de cierre de los bloques de Ruby.

class Foo 
    def initialize (x) 
    define_singleton_method(:x) { x } 
    end 
end 

El valor inicial de x está ahora bloqueado en el interior del bloque se utilizó para definir el getter #x y nunca se puede acceder excepto llamando foo.x, y nunca puede ser alterado.

foo = Foo.new(2) 
foo.x # => 2 
foo.instance_variable_get(:@x) # => nil 

en cuenta que no se almacena como la variable de instancia @x, sin embargo, todavía está disponible a través del captador hemos creado usando define_singleton_method.

---

Protección del comprador

En Rubí, casi cualquier método de cualquier clase se pueden sobrescribir en tiempo de ejecución. Hay una forma de evitar esto utilizando el gancho method_added.

class Foo 
    def self.method_added (name) 
    raise(NameError, "cannot change x getter") if name == :x 
    end 
end 

class Bar < Foo 
    def x 
    20 
    end 
end 

# => NameError: cannot change x getter 

Este es un método muy severo para proteger el captador.

Requiere que se añade cada captador protegido al method_added gancho de forma individual, y aún así, se tendrá que añadir otro nivel de protección a method_addedFoo y sus subclases para evitar un codificador de sobrescribir el método method_added sí.

Es mejor aceptar que el reemplazo de código en tiempo de ejecución es una realidad cuando se usa Ruby.