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

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.