{"id":5801,"date":"2013-10-09T18:34:34","date_gmt":"2013-10-09T15:34:34","guid":{"rendered":"http:\/\/railsware.com\/blog\/?p=5801"},"modified":"2021-08-11T17:51:35","modified_gmt":"2021-08-11T14:51:35","slug":"better-ruby-choosing-convention-for-class-methods-definition","status":"publish","type":"post","link":"https:\/\/railsware.com\/blog\/better-ruby-choosing-convention-for-class-methods-definition\/","title":{"rendered":"Better Ruby: choosing convention for class methods definition"},"content":{"rendered":"\n
Ruby doesn’t have procedural module akin to Python or Perl module. Usually, one uses class methods as a typical way to mimic this functionality.<\/div>\n\n\n\n

Class methods in Ruby are also very handy for supporting instance methods with fabrics and other common-for-class functionality. This is clearly seen in ActiveRecord::Base with dozens of supportive class methods (e.g. #find, #create, #where).<\/p>\n\n\n\n

There are two standard approaches for defining class method in Ruby. The first one is the “def self.method” (let’s call it Style #1), and the second one is the “class << self” (let’s call it Style #2). Both of them have pros and cons. So, let’s take a look at them and try to decide which style is better and why.<\/p>\n\n\n\n

Code sample<\/h2>\n\n\n\n

Here is “def self.method” style:<\/p>\n\n\n\n

# Style #1\nclass User < ActiveRecord::Base\n  def rating\n  end\n\n  def self.most_popular\n  end\n\n  def title_with_rating\n  end\n\n  def self.the_king\n  end\nend\n<\/pre>\n\n\n\n
And the same example for “class << self” style:<\/p>\n\n\n\n
# Style #2\nclass User < ActiveRecord::Base\n  class << self\n    def most_popular\n    end\n\n    def the_king\n    end\n  end\n\n  def rating\n  end\n\n  def title_with_rating\n  end\nend\n<\/pre>\n\n\n\n
Pros of “def self.method” style<\/h2>\n\n\n\n
1. It’s shorter and easier to add one method<\/h3>\n\n\n\n
It’s obvious, that Style #1 is two lines shorter due to the “class << self; end” part. This difference is noticeable for one\/two methods. Also, it’s easier to add first class method because you don’t have to type “class << self” wrapper.<\/p>\n\n\n\n
2. More simple for newbies<\/h3>\n\n\n\n
Usually Style #2 looks more exotic than Style #1; and, at first, the “class << self” part looks a little bit awkward.<\/p>\n\n\n\n
Pros of “class << self” style<\/h2>\n\n\n\n
1. Class and instance methods are separated<\/h3>\n\n\n\n
Glancing over class definition, in Style #1 it’s hard to say, whether it’s a class or instance method. You need to focus on name part. On the other side, in Style #2 indentation and “class << self” wrapper clearly says who is who.<\/p>\n\n\n\n
Another benefit of Style #2 – it’s easy to see amount of class and instance methods. They are not intermixed. Without clear separation it’s harder to work with class – you need to go over mix of methods and look for the required method.<\/p>\n\n\n\n
Of course, you can take convention, for grouping class methods in one place, but it’s another rule, which should be followed by all, and it’s so easy to violate it occasionally. With Style #2 is much harder to accidentally create another “class << self” scope.<\/p>\n\n\n\n
2. Easier to add batch of methods<\/h3>\n\n\n\n
What I especially appreciate in Style #2 – it’s easiness of adding new class methods. While Writing a new method, you shouldn’t be focused on adding “self.”-part in name. Class and instance method definition have the same syntax.<\/p>\n\n\n\n
When I started my way in Ruby, it frustrated me a lot when I added class method and it didn’t work. And only then I realised that I actually forgot to add “self.”-prefix.<\/p>\n\n\n\n
I strongly believe that a programmer should focus more on what he does and less on various language quirks. And after I switched to Style #2, these kinds of errors just disappeared from everyday coding.<\/p>\n\n\n\n
3. Simpler search of method definition<\/h3>\n\n\n\n
“grep”-ing for some method is simpler to always search by “def name” combination. Style #1 also requires search by “def self.name”. This item is not a showstopper, but I run into this issue from time to time while searching through a code of different gems.<\/p>\n\n\n\n
4. Simpler refactoring<\/h3>\n\n\n\n
What is started as object-oriented class can turn out to be a procedural module with a bunch of functions. To refactor instance methods into class methods you just need to add “class << self” wrapper and adjust indentation, which can be easily done in any editor.<\/p>\n\n\n\n
On the other side, Style #1 requires to put “self.”-prefix in every method, which is tedious and can’t be archived with usual means.<\/p>\n\n\n\n
Also, there is a case when you go into the opposite direction. Thing, which started as procedural module use some common context and should be refactored into class with instance methods. And again Style #1 requires removing of “self.”-prefix from all names, when in Style #2 you just remove “class << self \/ end” wrapper and adjust indentation.<\/p>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
It’s clearly seen, that “class << self” style has much more benefits than more commonly used “def self.method”. For me, the most crucial part is clear separation between class and instance stuff – because it improves code readability. I also like that Style #2 removes one class of errors from my Ruby programming.<\/p>\n\n\n\n
Generally, we stick to the rules below while using it:<\/p>\n\n\n\n
  1. Create “class << self” wrapper even for one method<\/li>
  2. Put class-methods part at the top of the class<\/li><\/ol>\n\n\n\n
    Following these rules will allow you to always find class-methods in a predictable place and in a predictable style.<\/p>\n","protected":false},"excerpt":{"rendered":"
    Ruby doesn’t have procedural module akin to Python or Perl module. Usually, one uses class methods as a typical way to mimic this functionality. Class methods in Ruby are also very handy for supporting instance methods with fabrics and other common-for-class functionality. This is clearly seen in ActiveRecord::Base with dozens of supportive class methods (e.g….<\/p>\n","protected":false},"author":25,"featured_media":9441,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[3],"tags":[],"coauthors":["Sergii Boiko"],"class_list":["post-5801","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-development"],"acf":[],"aioseo_notices":[],"categories_data":[{"name":"Engineering","link":"https:\/\/railsware.com\/blog?category=development"}],"post_thumbnails":"https:\/\/railsware.com\/blog\/wp-content\/themes\/railsware\/vendors\/images\/article-thumbnail-default.jpg","amp_enabled":true,"_links":{"self":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/5801","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/users\/25"}],"replies":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/comments?post=5801"}],"version-history":[{"count":28,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/5801\/revisions"}],"predecessor-version":[{"id":13925,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/5801\/revisions\/13925"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/media\/9441"}],"wp:attachment":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/media?parent=5801"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/categories?post=5801"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/tags?post=5801"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/coauthors?post=5801"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}