The Law of Demeter - Clean Code

A well-known heuristic called the Law of Demeter says a module should not know about the innards of the objects it manipulates.

In simpler terms, think of it like this:
When you ask a friend for something, you should only speak to your friend directly and not to your friend's acquaintances. If your friend has to get something from someone else, let your friend do it and give you the result, instead of you reaching out to the third person.

In terms of tech and especially OOP, Objects should not expose its internal structure through accessors.

Here is a simple example in Java:

final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

This example violates the Law of Demeter:

• ctxt is calling getOptions(), which gives you an object.

• Then, on that returned object, getScratchDir() is called.

• Finally, getAbsolutePath() is called on the result of getScratchDir().

Another example could be:

Expenses expenses = new Expenses(100, 10);
Employee employee = new Employee();
employee.getDepartment().getManager().approveExpense(expenses);

• employee.getDepartment() fetches the Department object associated with the employee.

• getManager() fetches the Manager object from the Department.

• approveExpense(expenses) is called on the Manager object.

Does it violate the Law of Demeter?

Ans: YES

Why?

The Law of Demeter says that a method should only interact with:

• Its own class’s methods.

• Objects it created.

• Objects passed as parameters.

• Objects it directly owns (fields or instance variables).

In the above (employee) example:

• employee is directly calling getDepartment(), breaking encapsulation by reaching into the Department object.

• It then calls getManager() on the returned Department object, reaching even further.

• Finally, it calls approveExpense(expenses) on the returned Manager object.

Solution

public class Employee {
    private Department department;

    public void approveExpense(Expenses expenses) {
        department.approveExpense(expenses);
    }
}

public class Department {
    private Manager manager;

    public void approveExpense(Expenses expenses) {
        manager.approveExpense(expenses);
    }
}

public class Manager {
    public void approveExpense(Expenses expenses) {
        // Logic for approving the expense
    }
}

Now we can call methods as:

Expenses expenses = new Expenses(100, 10);
Employee employee = new Employee();
employee.approveExpense(expenses);

• The Employee now only interacts with its Department through a single method, approveExpense().

• The Department handles the interaction with its Manager.

• Each class focuses on its own responsibilities, reducing the coupling between Employee, Department, and Manager.

Conclusion

The Law of Demeter is a simple rule that helps us write cleaner and more maintainable code. It says that an object should only interact with the objects it directly knows about, not with objects it indirectly reaches through others. Think of it as "talking to your friends, not your friends’ friends."

Following this principle makes our code less tangled and easier to work with. It avoids unnecessary dependencies between parts of the program, making it easier to change or update one part without breaking others. This means fewer bugs, less frustration, and more flexibility as your software grows.