Should you make use of private, protected, and public modifiers in Ruby?

Question

I come from more of a C# background yet am learning Ruby in my spare time.

Given classes, it is possible to make their methods private, public (default) or protected. While I understand their usage, is it typical for Ruby code to make use of such modifiers, despite being a dynamic language, in which the user can easily override access?

While using something like Send allows the user access to private methods regardless, I was just wondering what the best practice is regarding Ruby and access modifiers? In other words, should I be making use of them in my classes?

Answer 1

I would still use them in your code as it conveys a clear intent to the code reader and also give you the protection you need. If another dev is going to override your methods or call them directly via #send, they most likely either have or good reason or at least understand why they have to do it that way.

Using Private/Protected in your code makes things more explicit to the future dev who is going to override your methods and also works properly for you if no one ever overrides them

Answer 2

Given classes, it is possible to make their methods private, public (default) or protected. While I understand their usage, is it typical for Ruby code to make use of such modifiers, despite being a dynamic language, in which the user can easily override access?

It's still relatively common, because it conveys intent and minimizes the interface you're exposing. Some conventions to observe:

• Simply omit the public, since all methods are public unless you say otherwise, and methods are typically grouped by access modification.

• Even though a user can override access, that doesn't mean they should (in much the same way, you don't see C# developers doing crazy things like injecting IL stubs into classes so that they can access private methods). So it's still useful to have the distinction.

• Protected methods are somewhat rarer than they would be in C#, because Ruby doesn't really encourage inheritance as a means of passing on behavior. Common behavior can often be refactored into Modules and then include/extend-ed as necessary.

• Private methods are about as common as in C#; Ruby often favors lots of tiny methods that do very specific things, which you then compose together to get something useful. But you don't expose these methods, because they're not part of your public interface and you want to keep that clutter-free.

• Because private methods aren't considered part of the interface, you should be free to change them with impunity. By making them private, you've put others on notice that these methods and their implementation or definitions could change at any time.

Answer 3

I always figured it was about exposing an interface. You don't want your users to be overwhelmed with your implementation, so you make stuff like that private. It is kinder to them. For example, when dealing with Arrays, do you really want another 71 methods in your way (that you almost certainly don't care about?)

---

RUBY_VERSION                    # => "1.8.7"
Array.new.public_methods.size   # => 149
Array.new.private_methods.size  # => 71

---

Another important implication of private methods is that of "subject to change" When you commit yourself to an interface, you have to support it. You can't go breaking everyone's code every time they download a new version. Things that are private are understood to be volatile. They aren't exposed, so the implication is that you are free to change them. If users built code that relied on the private methods, then that isn't your fault (assuming they aren't doing it b/c you gave them a crap interface). So you can make it private to give yourself room to make it better in the future.