The “Principle of Least Knowledge” is not a law, but rather a principle closely related to “Tell, Don’t Ask”. It advises against unnecessary communication with unfamiliar entities to avoid excessive coupling. Although it originates from object-oriented programming (OO), it is applicable beyond that paradigm. Violations of this principle are frequently observed in legacy code, making it difficult to comprehend and test. By understanding the principle, and being able to identify and resolve violations through refactoring, one can improve the design and make the code more testable.
Group participants in pairs and have them research the Law of Demeter to come up with three facts. Ask them to put the found facts on a shared board so everybody can see it.
Explain what the Law of Demeter says, but not necessarily why it says that. The advantages of LoD will be discussed in the final conclusion. Explain that the Law of Demeter is about information hiding. You may use a phrase along the lines of: “a software module or an object should not have the knowledge of the internal workings of other objects or modules”. It can be useful to mention the alternate name of “Principle of Least Knowledge”. In the following concrete practice the participants will have to look at code and recognize a violation of the LoD. When you used the phrase: “Don’t talk to strangers.”, it might be helpful to explain the concept of a neighbor and a stranger, too.
Use simple code examples that either show a violation of LoD or don’t. Have the participants work in pairs to draw the objects and their dependencies using boxes and arrows. When they see a dependency that is a violation they should paint the arrow red. Provide them with examples that make obvious that it is not just about dot counting. Here are some small code examples you may use.
Take a few minutes to present the participants solutions you liked in particular. This allows other learners to verify their own conclusions.
Demo how to resolve a small LoD violation by moving code to its neighbor. You may have to first use “extract method” before you can finally do a “move method” refactoring. Rely on automated, tool-assisted refactorings in your demo as often as you can. A nice kata for this purpose is the FantasyBattle-Refactoring-Kata.
Have the participants practice the same refactoring in pairs. In the FantasyBattle-Refactoring-Kata they will find many violations of LoD they can practice resolving.
Ask the participants what they think are some advantages of adhering to the Law of Demeter and put those on a wall for everybody to see.