ActiveRecord, Delegation and Demeter

Many of you have heard of the Law of Demeter (LoD). For those who haven't, I recommend reading Robert C. Martin's great article (in his Engineering Notebooks), the Dependency Inversion Principle.

There are many great descriptions of LoD online but in practice, it boils down to dot chains are usually bad. (E.G. foo.bar.baz) The reason they are bad is because they generally represent a place where encapsulation is broken. In my example, the currently running code knows that foo provides bar, which is ok, but it also knows that bar provides baz. Really, the currently running code should only know the methods on foo. If it needs baz, it should call foo.baz. Note that this is not the case with Java's sb = new StringBuffer(); sb.append(str).append(str); since in this example, you are working on sb each time and not descending down into sb's children.

The problem with trying to implement LoD in real code is that short of a complicated framework for avoiding the dot chains, you tend to end up writing lots of small delegation methods and you tend to have to write new ones every time a child's implementation changes. Obviously this becomes fragile over time and explains why there are refactorings for adding and removing delegation in Martin Fowler's famous book, Refactoring.

Fortunately, I don't code in average languages anymore. These days, I am all about Ruby. In particular, I am usually writing Ruby in the context of Rails. Over the last couple of months, my boss and I have developed an elegant way to add delegation to ActiveRecord objects. Our technique could be extrapolated to a more general case but ActiveRecord models is where we want it so that is all we have done.

The following example explains how our code used to work.

class User < ActiveRecord::Base; end
class Agent < User
  has_one :agent_detail
end
class AgentDetail < ActiveRecord::Base
  belongs_to :agent
  belongs_to :address
end
class Address < ActiveRecord::Base
  has_one :agent_detail
end

This is backed by a database with these tables:

users: id, type, *
agent_details: id, agent_id, address_id, *
address: id, *

So, agents are users (and exist in the users table) but since agent needs more fields than user does and we didn't want to pollute the users table with the needs of every kind of user, we provide an agent_detail table that contains all the information that agents need and users don't. Also, since addresses are a cross-cutting concern in an application, we decided to store all addresses in one table which can be referenced by others like agent_details.

So, say you have an agent bob. To get bob's zip code, you would have to do bob.agent_detail.address.zip_code, breaking encapsulation and delving far too deep into implementation details of an agent. What we really want to be able to do is bob.zip_code. Our code shouldn't care how bob implements this field but it should be able to get this information directly from bob. We also need to be able to set this information on bob with bob.zip_code = '12345'. The normal and naive way to do this follows:

class Agent < User
  has_one :agent_detail

  def zip_code
    agent_detail.zip_code
  end

  def zip_code=(zip_code)
    agent_detail.zip_code = zip_code
  end
end
class AgentDetail < ActiveRecord::Base
  belongs_to :agent
  belongs_to :address

  def zip_code
    address.zip_code
  end

  def zip_code=(zip_code)
    address.zip_code = zip_code
  end
end

This allows us to do bob.zip_code but it has some problems. For one, at the moment, nothing is ensuring all agents have an agent_detail and all agent_details have an address. This means we are subject to nil problems (also know as NullPointerExceptions in the Java world). Also, say we wanted to change the name of zip_code to zip? We would have to change a table and a total of 8 lines of code in 2 different classes. Not exactly the most robust system. This also has some problems with saving dependent objects. If you do bob.zip = '12345'; bob.save, odds are the you expect the zip code change on address to be saved but it isn't.

Ruby and Rails have some great tools that can help us simplify the code above and remove some of the fragility of the interface in the face of change. Specifically, method_missing comes to the rescue to handle the bob.zip_code method and delegate it down and before_save and after_safe ActiveRecord callbacks help solve the save problems. This makes your code look like this:

class Agent < User
  has_one :agent_detail

  after_save {|agent| agent.agent_detail.save}

  def safe_agent_detail
    agent_detail.nil? : build_agent_detail ? agent_detail
  end

  def method_missing(method_id, *args)
    if safe_agent_detail.respond_to? method_id
      agent_detail.send(method_id, *args)
    else
      super
    end
  end

  def respond_to?(method_id)
    safe_agent_detail.respond_to?(method_id) || super
  end
end
class AgentDetail < ActiveRecord::Base
  belongs_to :agent
  belongs_to :address

  before_save {|agent_detail| agent_detail.address.save}

  def safe_address
    address.nil? : build_address ? address
  end

  def method_missing(method_id, *args)
    if safe_address.respond_to? method_id
      address.send(method_id, *args)
    else
      super
    end
  end

  def respond_to?(method_id)
    safe_address.respond_to?(method_id) || super
  end
end

This does neatly solve most of our problems but there is still one nagging itch, this code isn't very DRY. Most of the details in AgentDetail and Address are the same. What if we could take a page out of Rails and do this:

class User < ActiveRecord::Base; end
class Agent < User
  has_one_delegate :agent_detail
end
class AgentDetail < ActiveRecord::Base
  belongs_to :agent
  belongs_to_delegate :address
end
class Address < ActiveRecord::Base
  has_one :agent_detail
end

This is in fact, what my boss and I have done. The following code provides has_one_delegate and belongs_to_delegate:

module ActiveRecord
  class Base
    def self.belongs_to_delegate(delegate_id, options = {})
      delegate_to(:belongs_to, delegate_id, options)
    end

    def self.has_one_delegate(delegate_id, options = {})
      delegate_to(:has_one, delegate_id, options)
    end

    private

    def self.delegate_to(macro, delegate_id, options = {})
      send macro, delegate_id, options

      save_callback = {:belongs_to => :before_save, :has_one => :after_save}[macro]

      send save_callback do |model|
        model.send(delegate_id).save
      end

      delegate_names = respond_to?('safe_delegate_names') ? safe_delegate_names : []
      delegate_names = (delegate_names - [delegate_id]) + [delegate_id]

      def_string, source_file, source_line = <<-"end_eval", __FILE__, __LINE__

        def self.safe_delegate_names
          #{delegate_names.inspect}
        end

        def safe_delegates
          self.class.safe_delegate_names.collect do |delegate_name|
            send(delegate_name).nil? ? send("build_\#{delegate_name}") : send(delegate_name)
          end
        end

        def method_missing(method_id, *args)
          safe_delegates.each do |delegate|
            return delegate.send(method_id, *args) if delegate.respond_to?(method_id)
          end
          super
        end

        def respond_to?(*args)
          safe_delegates.any? {|delegate| delegate.respond_to?(*args)} || super
        end

      end_eval

      module_eval def_string, source_file, source_line + 1
    end
  end
end

The code itself isn't the most beautiful internally, but the simplicity it provides is elegant and effective. Also, because we eventually did need more than one delegate for the same class, it is robust enough to allow multiple delegates. Score one for the Ruby/Rails team. An entire class of refactorings goes from recipe to method call. This is why I love programming.

Eventually, we plan to release this as a plugin to the Rails community. Until then, let me know what you think. Would you use it?