Friday, April 20, 2007

Ruby: Class Methods

It's very common when moving from Java or C# to be weary of Ruby's class methods. Many people have written about how static methods are evil in C# and Java, but do those arguments apply to Ruby?

Complaints
  1. Static methods cannot participate in an Interface. Ruby: No interfaces, thus irrelevant.
  2. Static methods cannot be abstract. Ruby: No concept of abstract, also irrelevant.
  3. Static methods are not polymorphic. Ruby: doesn't seem like it applies since you don't declare type in Ruby. Also, you don't access class methods directly from an instance.
  4. Static methods are hard to test. Ruby: Class methods are as easy to test and mock as any instance method. Perhaps this is because they are simply instance methods of the sington class.


At this point I ran out of complaints, but it's been over a year since I've touched C#. If you have complaints of your own that support or oppose this entry, please drop them in the comments.

Another thought about static methods is that they tend not to encourage proper object design. For example, a method that removes characters from a string is probably best served on the string itself.
class String
# an example class method
def self.delete(string, characters)
...
end

# a better instance method
def delete(characters)
...
end
end
You see this type of class method much less in Ruby since Ruby has open classes. But, it's good to remember to put methods on the object whose data is being manipulated when possible.

So what exactly is a class method?
class Parser
def self.process(script)
# ...
end
end

Parser.singleton_methods.inspect #=> ["process"]
From the example, you could say a class method is a singleton_method. Where do singleton methods live?

class Parser
def self.process(script)
# ...
end

def self.singleton
class << self; self; end
end
end

Parser.singleton.instance_methods(false).inspect
#=> ["singleton", "new", "superclass", "allocate", "process"]
Singleton (class) methods are actually all instance methods of the singleton class.

In fact, you can define a class method various ways, but the result is always an instance method on the singleton class.
class Parser
def self.self_process(script)
# ...
end

def Parser.parser_process(script)
# ...
end

class << self
def singleton_process(script)
# ...
end
end

def self.singleton
class << self; self; end
end
end

Parser.singleton.instance_methods(false).inspect
#=> ["singleton_process", "parser_process", "new",
"superclass", "allocate", "singleton", "self_process"]
Of course, the process method is also inherited by subclasses and the singleton classes of subclasses.
class Parser
def self.process(script)
# ...
end
end

class Object
def self.singleton
class << self; self; end
end
end

class HtmlParser < Parser

end

HtmlParser.singleton_methods.inspect
#=> ["singleton", "process"]
HtmlParser.singleton.instance_methods(false).inspect
#=> ["singleton", "new", "superclass", "allocate", "process"]
In a later post I'll talk about where those methods are stored in the underlying C code.

Thanks to James Lewis, Matt Deiters, and Mike Ward for help on this entry.
Post a Comment