Eliminating code duplication with metaprogramming

Duplication of code is one of the worst code smells. It should be refactored in order to keep DRY if only possible. This is generally easy. But what if the code itself is not duplicated, but its structure is? That could be a little bit more difficult, but with Ruby‘s metaprogamming facilities it’s not that hard. Read on to see how.

The problem

In our project, we have a module called Factory that produces object needed by tests. It generally contains pairs of methods, new_something and create_something, like this:

module Factory
  def self.new_user options={}
    User.new({
      # some default values
    }.merge(options))
  end

  def self.create_user options
    u = new_user options
    u.save!
    u
  end
      
  def self.new_role options={}
    Role.new({
      # some default values
    }.merge(options))
  end

  def self.create_role options
    r = new_role options
    r.save!
    r
  end
      
  def self.new_permission options={}
    Permission.new({
      # some default values
    }.merge(options))
  end

  def self.create_permission options
    p = new_permission options
    p.save!
    p
  end

  def self.new_group options={}
    Group.new({
      # some default values
    }.merge(options))
  end

  def self.create_group options
    g = new_group options
    g.save!
    g
  end
  # ...snip...
end

Basically, the new_something methods merge provided and default options and return new, unsaved objects. In place of “some default values” there is always a list of attribute values that are needed for an object to pass validation (like login and password for user). This list is of course different for each type.

Notice the pattern with create_something methods?¹ Yes, they always do the same thing: call the paired new_something method, save the object and return it (although the type of the object is different). How to refactor this pattern and remove the duplication? There are several ways to do it. Let’s look at one of them.

The solution

My proposed solution is not to write the create_something methods at all. Instead, provide a method_missing implementation that will take care of creating objects. Like this:

module Factory
  def self.method_missing name, *args
    if name.to_s =~ /^create_(.+)/
      obj = self.send("new_#{$1}", *args)
      obj.save!
      obj
    end
  end

  # ...snip...
end

Now, if we intercept a call to create_something, we extract the ‘something’ with a regular expression and call the appropriate new_something method, passing all the arguments just as the original methods did. Then the object is saved and returned, as before. This part is 3 lines of code, but we can make it one line:

module Factory
  def self.method_missing name, *args
    if name.to_s =~ /^create_(.+)/
      returning(self.send("new_#{$1}", *args)) { |o| o.save! }
    end
  end

  # ...snip...
end

Or, if we (ab)use the Symbol#to_proc idiom (and forsake a little bit of readability), we can shorten it further to:

module Factory
  def self.method_missing name, *args
    if name.to_s =~ /^create_(.+)/
      returning self.send("new_#{$1}", *args), &:save!
    end
  end

  # ...snip...
end

What if one of the create_something methods differs from the pattern? E.g. create_user method might need to assign the created user to a role in order to let it login into the application. That’s no problem at all. Just write your create_user method as before and let it do all you need it to do. The method_missing method will not be called when create_user is not missing. The general rule is: method_missing handles the typical cases and create_something methods are necessary only when something extra is needed.

---

¹ There is also a pattern in the new_something methods, of course, but eliminating it is left as an exercise for the reader (and you still have to provide the default values somewhere).

About these ads