Respect Demeter's Law through Rails Plugin

Posted by Sebastien Auvray on Oct 25, 2007

Community

Ruby

Topics

Ruby on Rails ,

Design

Tags

Design Guideline ,

Demeter Law

The Law of Demeter or Principle of Least Knowledge is a design guideline for developing software. The fundamental notion is that a given object should assume as little as possible about the structure, properties and behavior of anything else (including its subcomponents). Dan Manges helped to clarify the concept and the way to apply it in Ruby, notably through the use of the Forwardable module. Using mocks and stubs, Luke Redpath came across Demeter's law violation when writing his Unit Tests:

class WidgetsControllerCreateActionTest < Test::Unit::TestCase
  def setup
    # usual rails controller test setup here
    @user = mock('user')
    User.stubs(:find).returns(@user)
  end

  def test_should_create_new_widget_for_parent_user_using_posted_widget_params
    widgets_proxy = mock('association proxy')
    @user.stubs(:widgets).returns(widgets_proxy)
    # Demeter's Law Violation here by using the widget_proxy through User object
    widgets_proxy.expects(:create).with(:name => 'my funky widget')
    post :create, :widget => {:name => 'my funky widget'}
  end

The solution is to add a delegate method on all your models. But that quickly becomes boring, which is the reason why Luke introduced the Demeter's Revenge plugin which will create a collection of Demeter-compliant methods for your has_many and has_and_belongs_to_many associations:

# given a User that has_many Widgets you'll be able to use:
user.build_widget(params) # => user.widgets.build(params)
user.create_widget(params) # => user.widgets.create(params)
# ...

But aren't laws made to be broken? And the fact that a plugin can automate a so called "Law" isn't this making it null and void?

1. Back to top

   Just to clarify a few things.

   Oct 25, 2007 11:36 AM by Luke Redpath

   I thought I'd made this clear on my blog but I'd like to respond to the final comment regarding a law being null and void because it can apparently be "fixed automatically". My plugin targets a very specific instance of demeter violation - that is, violations found in the inherent design of ActiveRecord - and nothing more.
   
   I wasn't happy with the way ActiveRecord practically forces you into breaking encapsulation by exposing the internals of its associations and the pain felt writing stubs and mocks is simply what drove me to finally do something about it; thanks to Ruby's dynamic nature, I was able to save myself writing the same repetitive wrapper (encapsulating) methods time and time again.
   
   I'm sure most readers will recognise that there is far more to the law of demeter than the one specific issue that my plugin sets out to solve and if you'd like to read more google provides a variety of articles on the subject.
   
   I'm somewhat concerned that some people seem to be interpreting this plugin as some kind of 'silver bullet' for all of your demeter violating woes (I thought I was quite explicit about that) and my blog entry links to some other articles that explore the fundamental issues more closely which I encourage people to read.

   Reply

2. Back to top

   A DRY way to apply Law of Demeter with demeter gem

   Nov 26, 2009 8:44 PM by Emerson Leite

   A DRY way to apply Law of Demeter with demeter gem
   
   github.com/emerleite/demeter
   gemcutter.org/gems/demeter

   Reply

• Older >