Understanding the Law of Demeter in C++: A Beginner's Practice Guide
Introduction
The Law of Demeter (LoD), also known as the Principle of Least Knowledge, is a software design guideline that encourages loose coupling between classes. The principle states that an object should communicate only with its immediate collaborators and should not depend on the internal details of other objects.
In simple terms, an object should talk only to its direct friends, not to strangers. This means a class should avoid navigating through multiple objects to access or modify data. Long chains of method calls such as car.getEngine().getFuelPump().activate() are common signs of a violation of the Law of Demeter.
Instead, an object should expose higher-level operations that hide its internal structure. This makes the code easier to maintain because changes to internal components do not affect other parts of the application.
This document presents two practical examples demonstrating how the Law of Demeter can be applied in C++.
Example 1: Wallet and Customer System
This example demonstrates how a cashier should interact with a customer without directly accessing the customer's internal wallet.
Program (Violating the Law of Demeter)
Program (Applying the Law of Demeter)
Explanation
In the first version, the BadCashier class directly accesses the customer's wallet and modifies the wallet's internal balance. This creates a dependency on the internal implementation of the Customer class.
If the wallet implementation changes in the future, the cashier class must also be modified. This creates tight coupling and violates the Law of Demeter.
In the improved version, the cashier communicates only with the customer through the payBill() function. The customer internally manages its wallet and delegates the payment request to the wallet object.
The cashier no longer needs to know how the customer's money is stored or managed. This improves encapsulation, reduces coupling, and makes the system easier to maintain.
Example 2: Smart Home Automation
This example demonstrates how a home automation system can control lighting without navigating through multiple nested objects.
Program (Violating the Law of Demeter)
Program (Applying the Law of Demeter)
Explanation
In the first version, the application directly navigates through the House, Room, and LightBulb objects to adjust the brightness. This long chain of object access exposes the internal structure of the system and tightly couples the application to its implementation.
In the improved version, the application simply requests the House object to activate night mode. The house delegates the request to the room, and the room internally controls the light bulb.
Each class communicates only with its immediate collaborator, hiding internal implementation details from higher-level components. This follows the "Tell, Don't Ask" design philosophy and complies with the Law of Demeter.
Characteristics of the Law of Demeter
| Property | Description |
|---|---|
| Core Goal | Reduce coupling by limiting communication between unrelated objects. |
| Primary Rule | A method should interact only with itself, its parameters, objects it creates, or its direct member objects. |
| Warning Sign | Long chains of object access such as a.getB().getC().doSomething(). |
| Design Philosophy | "Tell, Don't Ask"—tell an object what to do instead of navigating through its internal structure. |
| Benefit | Improves encapsulation, flexibility, maintainability, and reduces dependency between classes. |
Conclusion
The Law of Demeter encourages developers to minimize dependencies by allowing objects to communicate only with their immediate collaborators. By hiding internal object structures and exposing meaningful high-level operations, software becomes easier to maintain, extend, and modify. As demonstrated in the Wallet–Customer and Smart Home examples, following the Law of Demeter reduces tight coupling, improves encapsulation, and leads to cleaner, more maintainable C++ programs.