Demeter Helps You Fend Off the One True Constant: Change

There have been some good discussion lately around the Law of Demeter.  The worst thing about Law of Demeter is that it has the word “Law” in it.  Like all of the SOLID principles, it should be considered a rule of thumb and your experience and knowledge of the domain should tell you when it it appropriate.  However, I would consider staying consistent with this principles (as with all of the others) the starting point and transgress only under special circumstances.

If you haven’t heard of Demeter, the formal definition is that methods of a given class should only access:

  1. Fields and Methods on the object.
  2. Any object created within the method.
  3. Any direct properties or methods of an argument to the method

By following Demeter, you have stronger encapsulation in your objects.  This will lead to fewer coupling points in your application and thereby lowering coupling in your system.  When you do violate this principle it is easy to get into the situation where a change in one part of system has repercussions in other parts that were not touched for a specific release.  That’s when your day after release becomes a nightmare of chasing down bugs in production you can’t explain.

Recently I was was brought on to a very large application that has been in development for over a year.  When pairing with one the devs on a new feature, the implementation he proposed broke Demeter in several places, accessing child properties and methods a few levels deep.  When I brought this to his attention and explained to him that if you’re absolutely sure the object in question will always be created with the Properties in question, then you can considerate an allowable break of the rule.

The developer I was partnering did not think it was possible to construct the object in which this violation would ever cause a problem.  He’s a smart guy and I have no reason to doubt him, but as the title of of this post states, change is the one true constant.  We know that requirements change over time.  We also know that end users are very creative in using applications for solving problems they are not designed for.

Staying consistent with Demeter is my default way of developing new features.  Even if I think the chances of getting into an invalid state are infinitesimal, I still try to stay consistent with this principle.  It gives me greater flexibility to change the system as necessary and keeps my dependencies to getting to “sticky”, where I have to worry about who is accessing a property inappropriately  when it is time to change them.

This entry was posted in Law of Demeter, Software Design, SOLID. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • George

    I totally agree. In fact I’m working on a project right now where I’ve encountered the same issue and it hasn’t even been released yet!

  • If the word “Law” is worst thing, then why not start calling it “Principle of Least Knowledge” instead :) . That way all SOLID will have word “Principle” in it

  • I would but LoD already has the mindshare for this concept. I’d rather live with a bad name than make it even more confusing for new devs to find info that can help them write better software

  • AFAIK the L in SOLID actually stands for Liskov Substitution Principle – SOLID is a set of principles not laws!

  • I find LoD curious, the rationale is sound–that is, minimise touch points. In practice though, it leads to things like:


    as opposed to:


    Now, the latter is IMO *very* representative of the domain, so any changes to that would happen anyway when the requirements change. Also, the latter just seems more natural, and doesn’t violate the DRY principal (Customer already has a Name, so why introduce the same into Invoice?).

    This is the same scenario that Phil Haack introduce in

  • @Eric
    There are two schools of thought about the problem you mention. One would be if your domain dictates that you cannot create an invoice without a customer, than this is an acceptable violation of Demeter.

    The other side would say that if this is an important part of an invoice, than it should available directly from the invoice anyway. It may live in the Customer object, but it’s important to get this from the invoice, so make that connection explicit.

    The upside to making the CustomerName explicit is that it makes your Invoice object more flexible. You know have more control over invoice.GetCustomerName() than you do with Invoice.Customer.Name. Given that it is likely that the Customer object is going to be used in more contexts in your system than just invoices, doesn’t it make sense to let those different contexts behave differently?

    As it is with applying all of the SOLID principles, the answer is almost always “It depends”. As I said in the post, my experience and knowledge of the domain will determine what approach is right, but I always start with following LoD as my default approach.

  • Would like to reiterate that Law of Demeter is not a SOLID principle

  • @Neil – I’ve seen John present on the SOLID principles on a couple of occasions, so I believe he fully understands the ‘L’ in SOLID doesn’t stand for “Law of Demeter”. I take his reference to SOLID to be his appeal to a potentially wider understanding of the SOLID principles (because they get much more press than does LoD) as how you should also approach LoD.