Closest Ruby representation of a 'private static final' and 'public static final' class variable in Java?

Question

Given the Java code below, what's the closest you could represent these two static final variables in a Ruby class? And, is it possible in Ruby to distinguish between private static and public static variables as there is in Java?

public class DeviceController
{
  ...
  private static final Device myPrivateDevice = Device.getDevice("mydevice");
  public static final Device myPublicDevice = Device.getDevice("mydevice");
  ...
  public static void main(String args[])
  {
   ...
  }
}

Answer 1

There really is no equivalent construct in Ruby.

However, it looks like you are making one of the classic porting mistakes: you have a solution in language A and try to translate that into language B, when what you really should do is figure out the problem and then figure out how to solve it in language B.

I can't really be sure what the problem is you are trying to solve from that small codesnippet, but here is one possible idea for how to implement it in Ruby:

class DeviceController
  class << self
    def my_public_device;  @my_public_device  ||= Device['mydevice'] end

    private

    def my_private_device; @my_private_device ||= Device['mydevice'] end
  end
end

Here's another:

class DeviceController
  @my_public_device  ||= Device['mydevice']
  @my_private_device ||= Device['mydevice']

  class << self
    attr_reader :my_public_device, :my_private_device
    private :my_private_device
  end
end

(The difference is that the first example is lazy, it only initializes the instance variable when the corresponding attribute reader is first called. The second one initializes them as soon as the class body is executed, even if they are never needed, just like the Java version does.)

Let's go over some of the concepts here.

In Ruby, as in every other "proper" (for various definitions of "proper") object-oriented language, state (instance variables, fields, properties, slots, attributes, whatever you want to call them) is always private. There is no way to access them from the outside. The only way to communicate with an object is by sending it messages.

[Note: Whenever I write something like "no way", "always", "the only way" etc., it actually no means "no way, except for reflection". In this particular case, there is Object#instance_variable_set, for example.]

In other words: in Ruby, variables are always private, the only way to access them is via a getter and/or setter method, or, as they are called in Ruby, an attribute reader and/or writer.

Now, I keep writing about instance variables, but in the Java example we have static fields, i.e. class variables. Well, in Ruby, unlike Java, classes are objects, too. They are instances of the Class class and so, just like any other object, they can have instance variables. So, in Ruby, the equivalent to a class variable is really just a standard instance variable which belongs to an object which just happens to be a class.

(There are also class hierarchy variables, denoted with a double at sign @@sigil. Those are really weird, and you should probably just ignore them. Class hierarchy variables are shared across the entire class hierarchy, i.e. the class they belong to, all its subclasses and their subclasses and their subclasses ... and also all instances of all of those classes. Actually, they are more like global variables than class variables. They should really be called $$var instead of @@var, since they are much more closely related to global variables than instance variables. They are not entirely useless but only very rarely useful.)

So, we have covered the "field" part (Java field == Ruby instance variable), we have covered the "public" and "private" parts (in Ruby, instance variables are always private, if you want to make them public, use a public getter/setter method) and we have covered the "static" part (Java static field == Ruby class instance variable). What about the "final" part?

In Java, "final" is just a funny way of spelling "const", which the designers avoided because the const keyword in languages like C and C++ is subtly broken and they didn't want to confuse people. Ruby does have constants (denoted by starting with a capital letter). Unfortunately, they are not really constant, because trying to modify them, while generating a warning, actually works. So, they are more of a convention than a compiler-enforced rule. However, the more important restriction of constants is that they are always public.

So, constants are almost perfect: they cannot be modified (well, they shouldn't be modified), i.e. they are final, they belong to a class (or module), i.e. they are static. But they are always public, so unfortunately they cannot be used to model private static final fields.

And this is exactly the point where thinking about problems instead of solutions comes in. What is it that you want? You want state that

1. belongs to a class,
2. can only be read not written,
3. is only initialized once and
4. can be either private or public.

You can achieve all of that, but in a completely different way than in Java:

1. class instance variable
2. don't provide a setter method, only a getter
3. use Ruby's ||= compound assignment to assign only once
4. getter method

The only thing you have to worry about, is that you don't assign to @my_public_device anywhere, or better yet, don't access it at all. Always use the getter method.

Yes, this is a hole in the implementation. Ruby is often called a "grown-up's language" or a "consenting adults language", which means that instead of having the compiler enforce certain things, you just put them in the documentation and simply trust that your fellow developers have learned that touching other people's privates is rude ...

---

A totally different approach to privacy is the one used in functional languages: use closures. Closures are blocks of code that close over their lexical environment, even after that lexical environment has gone out of scope. This method of implementing private state is very popular in Scheme, but has recently also been popularized by Douglas Crockford et al. for JavaScript. Here's an example in Ruby:

class DeviceController
  class << self
    my_public_device, my_private_device = Device['mydevice'], Device['mydevice']

    define_method :my_public_device  do my_public_device  end
    define_method :my_private_device do my_private_device end

    private :my_private_device
  end # <- here the variables fall out of scope and can never be accessed again
end

Note the subtle but important difference to the versions at the top of my answer: the lack of the @ sigil. Here, we are creating local variables, not instance variables. As soon as the class body ends, those local variables fall out of scope and can never be accessed ever again. Only the two blocks which define the two getter methods still have access to them, because they close over the class body. Now, they are really private and they are final, because the only thing in the entire program which still has access to them is a pure getter method.

This is probably not idiomatic Ruby, but for anyone with a Lisp or JavaScript background it should be clear enough. It is also very elegant.

Answer 2

The closest thing I can think of to a final variable is to put the variable in question as an instance variable of a module:

class Device
    # Some static method to obtain the device
    def self.get_device(dev_name)
        # Need to return something that is always the same for the same argument
        dev_name
    end
end

module FinalDevice
    def get_device
        # Store the device as an instance variable of this module...
        # The instance variable is not directly available to a class that
        # includes this module.
        @fin ||= Device.get_device(:my_device).freeze
    end
end

class Foo
    include FinalDevice
    def initialize
        # Creating an instance variable here to demonstrate that an
        # instance of Foo cannot see the instance variable in FinalDevice,
        # but it can still see its own instance variables (of course).
        @my_instance_var = 1
    end
end

p Foo.new

p (Foo.new.get_device == Foo.new.get_device)

This outputs:

#<Foo:0xb78a74f8 @my_instance_var=1>
true

The trick here is that by encapsulating the device into a module, you can only access the device through that module. From the class Foo, there's no way to modify which device you're accessing, without directly acting upon the Device class or the FinalDevice module. The freeze call in FinalDevice may or may not be appropriate, depending on your needs.

If you want to make a public and private accessor, you can modify Foo like this:

class Foo
    include FinalDevice

    def initialize
        @my_instance_var = 1
    end

    def get_device_public
        get_device
    end

    private
    def get_device_private
        get_device
    end

    private :get_device
end

In which case you'll probably need to modify FinalDevice::get_device to take an argument as well.

Update: @banister has pointed out that @fin as declared in FinalDevice is indeed accessible by an instance of Foo. I had lazily assumed that since it wasn't in the default text output by Foo#inspect, it wasn't inside Foo.

You can remedy this by more explicitly making @fin an instance variable of the FinalDevice module:

class Device
    def self.get_device(dev_name)
        dev_name
    end
end

module FinalDevice
    def get_device
        FinalDevice::_get_device
    end

    protected
    def self._get_device
        @fin ||= Device.get_device(:my_device).freeze
    end
end

class Foo
    include FinalDevice

    def get_device_public
        get_device
    end

    def change_fin
        @fin = 6
        @@fin = 8
    end

    private
    def get_device_private
        get_device
    end

    private :get_device
end

f = Foo.new
x = f.get_device_public
f.change_fin
puts("fin was #{x}, now it is #{f.get_device_public}")

Which correctly outputs:

fin was my_device, now it is my_device