This article is exceptionally a little theoretical, but it is for the good cause.
I wish today to speak to you about the law of Demeter.
This is an essential law that any developer must know.
At the end of this article, you will be able to adapt your code to use this law and improve the overall quality of your application.
Where does the problem come from?
Generally, when you develop a class, you do not always pay attention to the dependencies of it.
A class can use several other classes either by composition or by passing arguments in the methods.
As a result, when you write a class, it will generate dependencies to other classes and sometimes transiently, that is:
- a class A uses a class B
- a method of B returns a type C
- class A will be able to use type C
Until then, you’ll tell me it’s classic. However, it is possible to make design choices precisely in this case.
Law of Demeter
The law of Demeter can be stated as follows:
Each unit must have limited knowledge of other units: it must see only units closely related to the current unit.
Translated differently, we could say: “Each unit must speak only to its friends. Do not talk to strangers “.
In practice, this means that a method of a class can invoke methods:
- of the object itself
- arguments of the method
- objects created in the method
- properties and fields of the object
By following Demeter’s law, your code will be easier to maintain and therefore easier to adapt.
As a result, your classes will be less dependent on the internal structure of other classes.
Practical example of the Law of Demeter
Finally, I propose a practical example to illustrate the Law of Demeter.
The example is one that is often used in literature: the Paperboy (newspaper delivery), the customer and the wallet.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
public class Paperboy { decimal fundsCollected; public Paperboy() { Customers = new List(); } public List Customers { get; set; } } public class Customer { public Customer() : this(null) { } public Customer(Wallet wallet) { Wallet = wallet; } public Wallet Wallet { get; set; } } public class Wallet { public Wallet(decimal money) { Money = money; } public decimal Money { get; set; } } |
Imagine that we had to write a method to request the payment of the journal to all customers.
We could then write this method in C#:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
public void CollectPayments() { // The newspaper costs $1 decimal payment = 1m; foreach (Customer customer in Customers) { if (customer.Wallet.Money >= payment) { customer.Wallet.Money -= payment; fundsCollected += payment; } } } |
This code works well but it poses a problem: the CollectPayments method has a deep knowledge of the Wallet class (because it uses Money).
In re-reading the Law of Demeter, one realizes that the problem must be corrected because of the strong dependence.
If you change the Wallet class (if you rename Money for example), it would have an impact on the CollectPayments method (which is not good).
So we could modify this method to write this:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
// Add this method in the Customer class // She manages the payment public decimal MakePayment(decimal amount) { if (Wallet.Money >= amount) { Wallet.Money -= amount; return amount; } return 0m; } // New version of CollectPayments (in PaperBoy) public void CollectPayments() { decimal charge = 1m; foreach (Customer customer in Customers) { decimal payment = customer.MakePayment(charge); if (payment != 0m) { fundsCollected += payment; } } } |
The law of Demeter is interesting for several reasons:
- First, it is easy to understand and easy to implement
- It allows to better separate behaviors (each method achieves one thing, it joins the SRP principle)
- It makes maintenance easier since Paperboy becomes independent of Wallet modifications (which was not the case before).
- In short, you’ll understand: I strongly advise you to set it up. This will greatly simplify your code.
And like every time: do not modify all your existing code. Make small changes.
For example, start by applying Demeter’s law to your new code.
