Closest Ruby Representation of a 'Private Static Final' and 'Public Static Final' Class Variable in Java

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.

Constants in Ruby and Java's final keyword

Like a lot of things in Ruby there is no "final", things are inherently dynamic and absolutely preventing people from doing things is never really going to happen. You can just make it difficult.

The one thing to note is in Ruby there's a difference between immutable and constant. A constant is a variable which will generate a warning when reassigned, that's all, and there's nothing to prevent you from modifying it. To prevent modifications you must "freeze" the object in question, though as with all things in Ruby, this is just a request that can be ignored by the object.

Typically you'll see code like this:

ADMIN_USER_TYPE = 'Admin'.freeze

Or this:

USER_TYPES = %w[
  Admin
].freeze

The freeze call is to catch cases where the list might be mangled by some method by accident. It does not absolutely prevent this, it's more of a safety measure. Consider this code:

def user_labels(types)
  types.map! { |t| [ t, t.downcase.to_sym ] }
end

Here a mistaken map! call would have the effect of rewriting the original array. In cases where you're calling it with a throw-away argument this is fine:

user_labels(%w[ Admin Test ])

When you're using the constant you'll permanently modify it, and that will cause it to get modified over and over each time it's called, creating a mess. The freeze flag trips a warning here and prevents that.

So the short answer is: No. The long answer is you have to be disciplined, the language will not prevent you from doing this if you're sufficiently determined. Pay attention to warnings and treat them seriously.

Set a Ruby variable and never be able to change it again?

They are called constants. A constant in Ruby is defined by a UPPER_CASE name.

VARIABLE = "foo"

It is worth to mention that, technically, in Ruby there is no way to prevent a variable to be changed. In fact, if you try to re-assign a value to a constant you will get a warning, not an error.

➜  ~  irb
2.1.5 :001 > VARIABLE = "foo"
 => "foo"
2.1.5 :002 > VARIABLE = "bar"
(irb):2: warning: already initialized constant VARIABLE
(irb):1: warning: previous definition of VARIABLE was here
 => "bar"

It's also worth to note that using constants will warn you if you try to replace the value of the constant, but not if you change the constant value in place.

2.1.5 :001 > VARIABLE = "foo"
 => "foo"
2.1.5 :002 > VARIABLE.upcase!
 => "FOO"
2.1.5 :003 > VARIABLE
 => "FOO"

In order to prevent changes to the value referenced by the constant, you can freeze the value once assigned.

2.1.5 :001 > VARIABLE = "foo".freeze
 => "foo"
2.1.5 :002 > VARIABLE.upcase!
RuntimeError: can't modify frozen String
    from (irb):2:in `upcase!'
    from (irb):2
    from /Users/weppos/.rvm/rubies/ruby-2.1.5/bin/irb:11:in `<main>'
2.1.5 :003 > VARIABLE
 => "foo"

Here's an example inside a class.

class MyClass
  MY_CONSTANT = "foo"
end

MyClass::MY_CONSTANT
# => "foo"

How make a variable public final in Ruby

class Person
  def initialize name
    @name = name
  end
  attr_reader :name
end

person = Person.new("Tom")
person.name         #=> Tom
begin
  person.name = "Bob"
rescue
  puts $!.message   # => Undefined method error
end
person.name         #=> Tom

Ruby has no constant values?

it depends what kind of action you want to do with your constants.

If you have an

ARRAY = [1,2,3]
#and then 
ARRAY << 4

Ruby won't complain.

However, if you

ARRAY = [1,2,3].freeze
#and
ARRAY << 4
#RuntimeError: can't modify frozen Array

You can still

ARRAY = [1,2,3,4]
#warning: already initialized constant ARRAY

Singleton or static class?

The very fact that you are providing a clear method to reset the state of your Singleton dictates that you should not use Singleton. This is risky behavior as the state is global. This also means that unit testing is going to be a big pain.

One more thing. Never ever declare instance variables as public. Declare them as private or protected and provide getters and setters. Also, there is no need to initialize instance variables with a value that is their default value.

---

Related Topics