Considere el siguiente ejemplo:
[~/srcLPP/inheritance]$ cat VariableInheritance.rb class Point def initialize(x,y) @x,@y = x, y end def to_s "#@x #@y" end end class Point3D < Point def initialize(x, y, z) super(x, y) @z = z end def to_s "#@x #@y #@z" end end if __FILE__ == $0 q, r, s = Point3D.new(1,1,1), Point3D.new(2,2,2), Point3D.new(3,3,3) puts q, r, s print "The instance variables of point 'q' are: " puts q.instance_variables.join(',') endObserve como en la línea 18 accedemos a las referencias
@x
y @y
de la superclase Point
.
Este código funciona como cabría esperar:
[~/srcLPP/inheritance]$ ruby VariableInheritance.rb 1 1 1 2 2 2 3 3 3 The instance variables of point 'q' are: @x,@y,@z [~/srcLPP/inheritance]$
Puesto que las variables de instancia no están relacionadas con la herencia, se deduce que una variable de instancia usada por una subclase no puede ocultar una variable de instancia definida usada en la superclase. Si una subclase usa una variable de instancia con el mismo nombre que una variable utilizada por uno de sus ancestros, sobreescribirá el valor de la variable de su ancestro. Esto puede ser que se haga con intencionalidad, para cambiar la conducta del ancestro o puede que ocurra por accidente. En este último caso seguramente dará lugar a bugs.
q
llamando a q.instance_variables
Casiano Rodriguez León 2015-01-07