The Artima Developer Community
Sponsored Link

Ruby Buzz Forum
Law of Demeter: Canary in a coal mine

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Jay Fields

Posts: 765
Nickname: jayfields
Registered: Sep, 2006

Jay Fields is a software developer for ThoughtWorks
Law of Demeter: Canary in a coal mine Posted: May 14, 2007 7:26 PM
Reply to this message Reply

This post originated from an RSS feed registered with Ruby Buzz by Jay Fields.
Original Post: Law of Demeter: Canary in a coal mine
Feed Title: Jay Fields Thoughts
Feed URL: http://blog.jayfields.com/rss.xml
Feed Description: Thoughts on Software Development
Latest Ruby Buzz Posts
Latest Ruby Buzz Posts by Jay Fields
Latest Posts From Jay Fields Thoughts

Advertisement
I've always been a fan of the Law of Demeter. The Law of Demeter is most often summarized as “Only talk to your immediate friends.”
The fundamental notion is that a given object should assume as little as possible about the structure or properties of anything else (including its subcomponents).
Wikipedia
That's all well and good, but I quite like the Law of Demeter because it's the canary (warning device) in my coal mine (codebase).

I was recently looking over some code with Mike Ward, Shane Harvie, Muness Alrubaie, Martin Fowler, Dan Manges, and David Vollbracht. The code in question had around a hundred lines of def_delegator :object, method_name, new_method_name. No one in the room thought that the 100+ lines of delegation were a good thing, but we all had opinions on how to deal with the ugly code.

Despite the various opinions on solutions, one thing was clear: The Law of Demeter exposed other issues within the codebase. For example, the object in question was taking on far too much responsibility. It had become the DoAnything object of the system. Additionally, methods such as diamond.clarity= were being delegated from ring via the ring.diamond_clarity= method. These methods were required as the attributes of a diamond were changed. However, a possibly better solution would be a method such as ring.replace_diamond that set an entirely new diamond. With the replace_diamond method in place the ring no longer needed to expose the setters of the diamond.

An additional note that came from this conversation: If you are a mockist you will often prefer to follow the Law of Demeter because it makes mocking much easier. However, classicists don't seem to mind as much since they can use train-wreck syntax for state based tests without any pain. Being a mockist or classicist seems to greatly influence a person's opinion on whether or not to follow the Law of Demeter.

Read: Law of Demeter: Canary in a coal mine

Topic: Babbling in Portugese Previous Topic   Next Topic Topic: RejectConf 2, electric boogaloo

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use