Respect Demeter's Law through Rails Plugin

| by Sebastien Auvray 0 Followers on Oct 25, 2007. Estimated reading time: 1 minute |
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?

Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Just to clarify a few things.

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.

A DRY way to apply Law of Demeter with demeter gem

A DRY way to apply Law of Demeter with demeter gem

github.com/emerleite/demeter
gemcutter.org/gems/demeter
Close

by

on

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Login to InfoQ to interact with what matters most to you.