I recently came across this blog post from the venerable Chris Wanstrath (of github / err the blog fame) which took me somewhat aback. Chris suggests that using class << self to contain class methods (C# / Java programmers read ’static methods’) is a harmful habit that should be discouraged.
I dislike class methods generally: they remind me of procedural programming, and can be awkward to test. Yet I actually rather like this ruby idiom and I believe that there are some very good reasons to use it especially when refactoring.
Disadvantages
Following a thorough discussion of the advantages and disadvantages on the RSpec mailing list, I can tell you the reasons why you would not want to use it:
- It can cause confusion for programmers who are inexperienced, or new to Ruby, who find the unfamiliar syntax and concepts hard to understand.
- It can cause confusion for any programmer when working on a class file so long that the class definition has scrolled off the top of the screen, so you can’t tell if you’re looking at an instance method or a class method.
- Your code will run (a bit) slower.
- Some people might think you’re being overly-clever and showing off. As Mark Wilden puts it:
> look at me, ma, I’m opening the eigenclass!
Advantages
Here is a summary of the reasons why you might:
- You can do things like make certain class methods private, and define attribute accessors for instance variables of the eigenclass.
- You might think it looks cleaner.
- It can help you to think in an object-oriented way about the class methods you’re defining.
- You might find it aids refactoring.
My Take
In the end, I thought Brian Takita summed it all up very well, after some verbal jousting with Mark Wilden:
> I’m wondering if this is a discussion about taste. I have my
> experience with both approaches and you have yours. Just because
> something works better for you does not mean its going to work better
> for me and vice versa. I know that using class << self has been very
> helpful in making my design better and it helps me to understand the
> code vs the def self.methodname.
>
> I see def self.methodname as a useful shortcut in irb or when there
> are few (0 to many depending on the person and situation) simple
> methods on the class. There is a point to where it, IMO, makes the
> code more difficult to understand, though.
So it’s a pretty subtle and subjective thing, and perhaps less risky in a situation where all the people working on the code have a feeling for what makes a good design.
When reading code, I’m generally doing some basic warm-up refactorings to get used to the code, and one of the first things I want to do is group up all the class methods which are often sprinkled around the file together, clearing away the clutter so I can see the instance methods that define the actual behaviour of the class.
At this point, class << self is only marginally useful. I can quite easily group all the class methods just by putting them at the top or bottom of the file. Using a class << self block would allow me to fold them closed in Textmate, but that’s not really all that important to me.
Now let’s imagine that one of these private methods is long and ugly.
As I start to extract smaller methods, I want to be able to mark them as private so it’s clear that they’re not part of the public interface of the class.
This is the point where class << self starts to add value. It’s a safe and painless step to move the methods inside a class << self block, remove the ’self.’ prefix from the method definitions. Now I’m in a position where I can extract smaller private methods from the class methods.
Often, as I do this, I start to see responsibilities in the eigenclass methods that could belong together in another class. Factories often start as a class method, for example. As soon as it becomes clear that a break needs to be made, it’s easy to move the methods into the newborn class. This refactoring can be gently introduced by delegating to the new class from within the eigenclass.
Refactoring Example
Imagine that we have a model where Dogs are born with a temperament (playful, angry, etc.) that cannot be trained out of them during their lifetime:
class Dog
attrreader :temperament
def initialize(temperament)
@temperament = temperament
end
end
Now suppose we want to limit those temperaments to just a couple. A valid way to do this might be to create a few factory methods, and mark the initializer method as private:
class Dog
attrreader :temperament
def self.newhappy
new(:happy)
end
def self.newangry
new(:angry)
end
private
def initialize(temperament)
@temperament = temperament
end
end
Although the current example is trivial, I’m going to refactor those class methods inside an eigenclass block, just so you can see what it looks like:
class Dog
attrreader :temperament
class << self
def newhappy
new(:happy)
end
def new_angry
new(:angry)
end
end
private
def initialize(temperament)
@temperament = temperament
end
end
Same code, different convention. Whatever.
Now suppose we get a requirement that all Dogs must have an owner. It has do be defined when the Dog is born. Now we’re going to have to take the owner as a parameter on all those factory methods:
class Dog
attrreader :temperament, :owner
class << self
def newhappy(owner)
new(:happy, owner)
end
def newangry(owner)
new(:angry, owner)
end
end
private
def initialize(temperament, owner)
@temperament, @owner = temperament, owner
end
end
How boring. Now obviously this is a silly and simplistic example, but with something in the real world, we can imagine a situation where the evidence for factoring out a DogFactory would start to weigh up. Here we go:
class DogFactory
def initialize(owner)
@owner = owner
end
def newhappy
Dog.new(:happy, owner)
end
def new_angry
Dog.new(:angry, owner)
end
private
def owner
@owner
end
end
So you can see that our shiny new DogFactory looks a lot like the eigenclass that was hiding inside of the Dog back there.
And what does our Dog class look like now?
class Dog
attrreader :temperament, :owner
private
def initialize(temperament, owner)
@temperament, @owner = temperament, owner
end
end
Nice and tidy. If we need to support clients who are used to the old factory methods on Dog, we can do it like this:
class Dog
def self.newhappy(owner)
warn("Please use a DogFactory for creating Dogs.")
end
…
Note that I deliberately used ’self.’ here to define the method. To me, the refactoring is now complete and this deprecated method is starting to wither away and die, and so it’s OK if it takes an evolutionary step backwards again. Right now I don’t really care whether it’s defined in a class << self block or not.
Wow. If you’re still with me, I hope that gives you an insight into how I think this technique can help you to clean up your Ruby code.
I probably spend at least as much of my time refactoring other people’s code as I do writing new code, so that may affect my perspective on this. Time after time when refactoring, I’ve seen methods move from instance methods on a class, to class methods, then finally off onto a shiny new (testable) class as instance methods. I think that anything that helps you to see the new class that could be formed around a group of methods and responsibilities is a good thing. On the other hand, I’m uncomfortable with the idea of leaving code behind that’s confusing to people less experienced than me.
What do you think?
