Jay Fields' Thoughts

There are several ways to define class methods in Ruby.

class Person
 def Person.find(id)
 ...
 end
end

This is the version that recent Java/C# converts seem to prefer. I'm not a big fan of this version because it requires me to change all the class method definitions if I change the name of the class.

class Person
 def self.find(id)
 ...
 end
end

I prefer this version. The syntax is concise and descriptive. When browsing a file of code, the use of self. makes it very clear that the method is a class method. This is the version I use by default.

class Person
 class << self
 protected
 def find(id)
 ...
 end
 end
end

This is the version I use when I need to make the method protected. For more information on why this is necessary you can check my previous entry: Protected Class Methods

class Object # http://whytheluckystiff.net/articles/seeingMetaclassesClearly.html
 def meta_def name, &blk
 (class << self; self; end).instance_eval {define_method name, &blk }
 end
end

class Service
 def self.responses(hash)
 hash.each do |method_name, result|
 meta_def method_name do
 result
 end
 end
 end
 
 responses :success => 20, :unreachable => 23
end

Service.success # => 20
Service.unreachable # => 23

This version is by far the most complicated to write and read. The justification for using this version is that you can create class methods that declaratively define other class methods. This version requires the use of define_method instead of def because variables from the surrounding context are necessary. I tend to only use this version when I'm metaprogrammatically defining other class methods.

class Person
 instance_eval do
 def find(id)
 ...
 end
 end
end

It's also possible to define class methods inside an instance_eval sent to a class. For an explaination of why this works check out instance_eval and class_eval method definitions. As the linked entry states, I have run into this by accident, but I don't think I've ever actually used instance_eval to define class methods on purpose.

Are there ways that you define class methods that I've left off. If so, please let me know how and why in the comments (with an explanation inline or a link to a blog post on your site).

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.