Law of Demeter in Java – Principle of least Knowledge – Real life Example

Law of Demeter also known as principle of least knowledge is a coding principle, which says that a module should not know about the inner details of the objects it manipulates. If a code depends upon internal details of a particular object, there is good chance that it will break as soon as internal of that object changes. Since Encapsulation is all about hiding internal details of object and exposing only operations, it also assert Law of  Demeter. One mistake many Java programmer makes it exposing internal detail of object using getter methods and this is where principle of least knowledge alerts you. I first come to know about this principle, while reading one of the must read programming book, Robert C. Martin’s Clean code. Apart from many good thing the book teaches you, “principle of least knowledge” is one principle, which I still remember. Like many bad things, you will tempt to violate Law of Demeter, because of beautiful chaining of methods written in fluent style. On surface it looks pretty good, but as soon as you think about principle of least knowledge, you start seeing the real picture. In this article, we will see formal definition of Law of Demeter and explore code snippet which violates this principle.

Law of Demeter

According to Law of Demeter, a method M of object O should only call following types of methods :

  1. Methods of Object O itself
  2. Methods of Object passed as an argument
  3. Method of object, which is held in instance variable
  4. Any Object which is created locally in method M

More importantly method should not invoke methods on objects that are returned by any subsequent method calls specified above and as Clean Code says “talk to friends, not to strangers”. Apart from knowing object oriented programming basic concepts e.g. Abstraction, Polymorphism, Inheritance and SOLID design principle, it’s also worth knowing useful principle like this, which has found it’s way via experience. In following example, we will see how a method can violate above rules to violate Law of Delimiter.

public class LawOfDelimterDemo {

    /**
     * This method shows two violations of "Law of Delimiter" or "Principle of least knowledge".
     */
    public void process(Order o) {

        // as per rule 1, this method invocation is fine, because o is a argument of process() method
        Message msg = o.getMessage();

        // this method call is a violation, as we are using msg, which we got from Order.
        // We should ask order to normalize message, e.g. "o.normalizeMessage();"
        msg.normalize();

        // this is also a violation, instead using temporary variable it uses method chain.
        o.getMessage().normalize();

        // this is OK, a constructor call, not a method call.
        Instrument symbol = new Instrument();

        // as per rule 4, this method call is OK, because instance of Instrument is created locally.
        symbol.populate(); 

    }
}

You can see that when we get internal of Order class and  call a method on that object, we violate Law of delimiter, because now this method knows about Message class. On the other hand calling method on Order object is fine because its passed to the method as parameter.  This image nicely explains what you need to do to follow Law of Demeter.

Law of Demeter in Java with Example

Let’s see another example of code, which violates the Law of Demeter and how does it affect code quality.

public class XMLUtils {
   public Country getFirstBookCategoryFromXML(XMLMessage xml) { 
       return xml.getXML().getBooks().getBookArrary(0).getBookHeader().getBookCategory();
   }
}

This code is now dependent upon lot of classes e.g.
XMLMessage
XML
Book
BookHeader
BookCategory

Which means this function knows about XMLMessage, XML, Book, BookHeader and BookCategory. It knows that XML has list of
Book, which in-turn has BookHeader and which internally has BookCategory, that’s a lot of information. If any of the intermediate class or accessor method in this chained method call changes, then this code will break. This code is highly coupled and brittle. It’s much better to put the responsibility of finding internal data into the object, which owns it. If we look closely, we should only call getXML() method because its method from XMLMessage class, which is passed to method as argument. Instead of putting all this code in XMLUtils, should be putting on BookUtils or something similar, which can still follow Law of Demeter and can return the required information.

Related Whitepaper:

Bulletproof Java Code: A Practical Strategy for Developing Functional, Reliable, and Secure Java Code

Use Java? If you do, you know that Java software can be used to drive application logic of Web services or Web applications. Perhaps you use it for desktop applications? Or, embedded devices? Whatever your use of Java code, functional errors are the enemy!

To combat this enemy, your team might already perform functional testing. Even so, you're taking significant risks if you have not yet implemented a comprehensive team-wide quality management strategy. Such a strategy alleviates reliability, security, and performance problems to ensure that your code is free of functionality errors.Read this article to learn about this simple four-step strategy that is proven to make Java code more reliable, more secure, and easier to maintain.

Get it Now!  

One Response to "Law of Demeter in Java – Principle of least Knowledge – Real life Example"

  1. incze says:

    you probably have a spell checker with that “law of delimiter”.

Leave a Reply


− 1 = five



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books