The Law of Demeter was proposed by Ian Holland in 1987. During the development of a system called Demeter using oriented object programming, Holland and his colleagues realized that the code that fulfilled a series of rules was less coupled. Although it is called The Law of Demeter, it is not really a law, but more of a guideline to help reduce coupling between components. When applying LoD to object orientated design, there is a set of four rules that formalizes the “Tell Don’t Ask” principle;
You may call methods of objects that are:
1. Passed as arguments
2. Created locally
3. Instance variables
4. Globals
A great example of this is:
class User {
Account account;
...
double discountedPlanPrice(String discountCode) {
Coupon coupon = Coupon.create(discountCode);
return coupon.discount(account.getPlan().getPrice());
}
}
class Account {
Plan plan;
...
}Here account.getPlan( ).getPrice( ) violated the LoD. The most obvious fix is to delegate/tell:
class User {
Account account;
...
double discountedPlanPrice(String discountCode) {
// delegate
return account.discountedPlanPrice(discountCode);
}
}
class Account {
Plan plan;
...
double discountedPlanPrice(String discountCode) {
Coupon coupon = Coupon.create(discountCode);
return coupon.discount(plan.getPrice());
}
}Each function should have a limited amount of knowledge as opposed to knowing about the whole object map so our neighboring objects need to know what we have done in order to depend on them to propagate that message to the correct location. Following this rule is hard, which is why it is called the “Suggestion of Demeter” by many because it is so easy to violate. Following this rule, though, is extremely beneficial because any function that “tells” instead of “asks” is decoupled from the rest of the code around it.
The blog I retrieved this information from was https://hackernoon.com/object-oriented-tricks-2-law-of-demeter-4ecc9becad85. The information was extremely easy to follow and understand. The coding examples given to show the difference between following the LoD and not following it were simple and clear. I also found the explanation of LoD given to be simple and to the point. Going forward with coding, although understanding that following LoD can be hard, I plan to utilize this guideline in order to enhance and simplify all of my future codes.
By following the LoD in future coding endeavors, my code will be easier to test, I can reuse classes more easily, the amount of coupling and dependencies between classes will be reduced, my code will more flexible when I make changes to it and it will be more maintainable.
Information gathered for this blog:
https://medium.com/better-programming/demeters-law-don-t-talk-to-strangers-87bb4af11694
https://hackernoon.com/object-oriented-tricks-2-law-of-demeter-4ecc9becad85
https://en.wikipedia.org/wiki/Law_of_Demeter
From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.
