Law of Demeter - Talk to Friends, Not to Strangers
Principle of least Knowledge with Real life Example
Hello guys, the Law of Demeter also known as the 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 the internal details of a particular object, there is a good chance that it will break as soon as the internal of that object changes.
Since Encapsulation is all about hiding internal details of an object and exposing only operations, it also asserts the Law of Demeter.
One mistake many Java programmer makes it exposing internal detail of object using getter methods and this is where the principle of least knowledge alerts you.
I first come to know about this principle, while reading Clean Code, one of the must-read programming books by Robert C. Martin's also known as Uncle Bob. Apart from many good things the book teaches you, the "principle of least knowledge" is one principle, which I still remember.
Like many bad things, you will tempt to violate the Law of Demeter, because of the beautiful chaining of methods written in a fluent style.
On the surface, it looks pretty good, but as soon as you think about the principle of least knowledge, you start seeing the real picture.
In this article, we will see a formal definition of the Law of Demeter and explore code snippets that violate this principle. Btw, In order to best understand design patterns, you need to work out some scenarios, examples, etc.
It's best to get this kind of knowledge as part of your work but even if you don't get there, you can supplement them by joining a comprehensive Java design pattern course like Design Patterns in Java on Udemy and doing some object-oriented software design exercises like How to design an efficient Parking lot and the ones given in Codemia.io
80% OFF on Grokking the Java Interview
Btw, before we start, I just want to let you know that I am running a 80% discount for next 48 hours on my book as a lot of people asked for discount coupons. I have created one, friends80 to get 80% discount but only valid for next 2 days.
If you are preparing for Java interview then you can get any of my book for 80% discount, the biggest discount I have ever given, except Gumroad Days.
Here are links -
And, if you want all of them, you can just get the Everything Bundle which has all of my books.
Law of Demeter Example in Java
According to the Law of Demeter, a method M of object O should only call the following types of methods:
Methods of Object O itself
Methods of Object passed as an argument
Method of an object, which is held in an instance variable
Any Object which is created locally in method M
More importantly, the 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".
Here is a diagram which illustrate this concept :
The "friends vs. strangers" metaphor works very well to remember the Law of Demeter, as it clearly communicates that classes should only interact with their immediate collaborators (friends) rather than reaching through them to access objects they don't directly know (strangers).
Apart from knowing object-oriented programming basic concepts e.g. Abstraction, Polymorphism, Inheritance, and SOLID design principle, it's also worth knowing useful principles like this, which has found it's way via experience.
In the 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 the Law of delimiter because now this method knows about Message class.
On the other hand calling method on the Order object is fine because it's passed to the method as a parameter.
This image nicely explains what you need to do to follow the Law of Demeter.
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 a lot of classes e.g.XMLMessage
XML
Book
BookHeader
BookCategory
This means this function knows about XMLMessage, XML, Book, BookHeader, and BookCategory.
It knows that XML has a 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 methods 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 is from XMLMessage class, which is passed to the method as an argument.
Instead of putting all this code in XMLUtils, should be putting on BookUtils or something similar, which can still follow the Law of Demeter and can return the required information.
That's all on this example of Law of Demeter or "Principle of least knowledge". It's better not to have a chain of methods, originating from unknown objects, which may change. I also suggest reading Chapter 6 of Clean Code, a must-read book for any software developer.
Other articles you may like
P. S. - If you are preparing for Java interview then you can get any of my book for 80% discount, the biggest discount I have ever given, except Gumroad Days.
 | A guest post by
|