Let’s say that you have a Person class, and that people in your system can sell things and/or publish articles. You can’t use subclasses, because a person can be an author and a seller at the same time. At first you might start with something like this:

class Person < ActiveRecord::Base
  has_many :articles
  has_many :comments, :through => :articles
  has_many :items
  has_many :transactions

  def is_seller?
    items.present?
  end

  def amount_owed
    # => some fancy math
  end

  def is_author?
    articles.present?
  end

  def can_post_article_to_homepage?
    # => some fancy permissions
  end
end

This might seem OK at first. You might say “Well, it’s the responsibility of Person to know about both the items they’ve sold, as well as the articles they’ve published.” I say that’s hogwash.

Imagine a new requirement: People can be buyers as well as sellers / authors

The way this is setup, you’d have to re-open the person class and add things like:

class Person < ActiveRecord::Base
  #  ...
  has_many :purchased_items
  has_many :purchased_transactions

  def is_buyer?
    purchased_items.present?
  end

  # ...
end

The first thing to notice is that this violates the open / closed principle (open for extension but closed to modification) because you’ve modified the class. Next, you’ll notice that naming can get very confusing in places where you’ve got a person who is on both sides of a transaction. Finally, this code has poor separation of concerns.

Imagine another new requirement: The Person class is now driven by an xml web service, or a non-ActiveRecord class

Now that you can’t use ActiveRecord and your has_many code doesn’t work, you have to rewrite all kinds of code, and feature development grinds to a halt.

Enter DelegateClass

Let’s say instead of modifying Person, you extended Person by creating delegate classes, like so:

class Person < ActiveRecord::Base
end

class Seller < DelegateClass(Person)
  delegate :id, :to => :__getobj__

  def items
    Item.for_seller_id(id)
  end

  def transactions
    Transaction.for_seller_id(id)
  end

  def is_seller?
    items.present?
  end

  def amount_owed
    # => some fancy math
  end
end

class Author < DelegateClass(Person)
  delegate :id, :to => :__getobj__

  def articles
    Article.for_author_id(id)
  end

  def comments
    Comment.for_author_id(id)
  end

  def is_author?
    articles.present?
  end

  def can_post_article_to_homepage?
    # => some fancy permissions
  end
end

The calls to this involve one extra step, so instead of:

person = Person.find(1)
person.items

You add:

person = Person.find(1)
seller = Seller.new(person)
seller.items
seller.first_name # => calls person.first_name

Now that this is in place, adding a Buyer is as simple as creating a Buyer delegate class like so:

class Buyer < DelegateClass(Person)
  delegate :id, :to => :__getobj__

  def items
    Item.for_buyer_id(id)
  end

  def is_buyer?
    purchased_items.present?
  end
end

Now when you need to make Person driven by something other than ActiveRecord::Base, your delegate classes don’t change at all.

Delegate classes aren’t the solution to every problem, and certain behavior, such as #reload can be very confusing at first:

person = Person.find(1)
seller = Seller.new(person)
seller.class # => Seller
seller.reload.class # => Person

Another gotcha is that id doesn’t delegate by default, so you have to add the following line to make sure you get the ActiveRecord id:

  delegate :id, :to => :__getobj__

However, delegate classes can go a long way to making your code more supple.

The post DelegateClass rocks my world appeared first on Pivotal Labs.