The Law of Demeter

Law of demeter. Cartoon of a child saying no, and some code: {myObject.never.talksToStrangers}

The Law of Demeter (LoD) is a guideline for software design. It is also known as the principle of least knowledge. Its aim is to reduce the amount of coupling between objects. It does this by limiting their interconnections and inter-dependencies.

We must always try to minimise the coupling between objects. The more an object knows about another object, the more tightly coupled they are. Tight coupling can lead to increased complexity and more difficult maintenance. Loose coupling promotes the separation of concerns, which makes software more flexible and easier to modify and maintain.

Obeying the Law of Demeter is an easy way for us as developers to reduce the number of bugs in our code.

Basics of the Law of Demeter

The Law of Demeter says that each unit should have only limited knowledge about other units. These other units can only be units that are “closely” related to the current unit. A unit here could be a class, a module, a package, etc.

There are three recommendations that are easy to remember:

  • Each unit should only know about the units that are closely related to it.
  • Each unit should only talk to its immediate friends.
  • They shouldn’t talk to strangers.

An unit should assume as little as possible about the data structure or properties of anything else (including its subcomponents). This conforms to the principle of information hiding.

Simply put: “Only talk to your immediate friends, don’t talk to strangers.”

TechSpeak

An object a can call a method of an object instance b. But object a should not “reach through” object b to access yet another object, c, to request its services. By doing so would mean that object a implicitly needs more knowledge of object b’s internal structure. This creates tight coupling between a and b.

A better approach will be to modify the interface of object b, so it can directly serve object a’s request. Alternatively, a might have a direct reference to object c and make the request directly. If the Law of Demeter is followed, only object b knows its own internal structure.

The Law of Demeter bans the direct access and manipulation of instance variables in another class. If we allow variables to be directly referenced, it limits the way we can modify existing classes. The only variables that should be accessed directly are the static constants defined in that class. All instance variable should only be accessed via accessor methods. This includes any instance variables that belong to the super-classes.

To summarise, inside a method of a class, we can only call methods of the following classes (our preferred suppliers):

  • The class and base class of the current object.
  • The classes of the method arguments. This includes the class itself via the this object.
  • The classes of local and instance variables.

Calling methods on global objects is allowed, but we should avoid it because of increased coupling. Fortunately, Java doesn’t support the creation of global variables.

Law of Demeter from a Security Perspective

The Law of Demeter aligns with the security principle of least privilege. The principle of least privilege dictates that a user or entity — like a module — should only have access to the specific data, resources and applications that it needs to complete its required task.

So if you follow the Law of Demeter, you will also be doing your bit towards a more secure system!

Some History

The Law of Demeter was proposed in 1987 by Ian Holland, who was working on the Demeter Project. The Demeter Project was the birthplace of many of the AOP (Aspect-Oriented Programming) principles.

They were working on a hardware description language called Zeus, and were looking for a tool to simplify its implementation. They were trying to decide on a name for the tool that was related to Zeus in some way. They chose Demeter, who was a sister of Zeus in Greek mythology.

Demeter was the goddess of agriculture. Demeter-style software development is about growing software as opposed to building software. This empathizes a bottom-up philosophy of programming.

Further Reading

Wikipedia has the usual technical article on the Law of Demeter.

InfoWordl has an easy to read article demystifying the Law of Demeter.

There is a detailed article on the Baeldung website with some Java code examples.

And if you’re dying for even more to read, this page is fairly academic, and contains dozens of additional links.

Was this interesting? Please share your comments, and as always, stay safe and keep learning!

Leave a Comment

Your email address will not be published. Required fields are marked *

Thank You

We're Excited!

Thank you for completing the form. We're excited that you have chosen to contact us about training. We will process the information as soon as we can, and we will do our best to contact you within 1 working day. (Please note that our offices are closed over weekends and public holidays.)

Don't Worry

Our privacy policy ensures your data is safe: Incus Data does not sell or otherwise distribute email addresses. We will not divulge your personal information to anyone unless specifically authorised by you.

If you need any further information, please contact us on tel: (27) 12-666-2020 or email info@incusdata.com

How can we help you?

Let us contact you about your training requirements. Just fill in a few details, and we’ll get right back to you.