The Law of Demeter
An object should only concern itself with its own affairs.
Core Principle
It recommends that objects should avoid accessing the internal data and methods of other objects.
To put this more clearly, an object should only invoke methods on:
- Itself.
- Its direct dependencies (fields or instance variables).
- Objects passed in as arguments.
- Objects it creates.
Explanation
An object should only concern itself with its own affairs or those that truly pertain to it. It should not know what is happening beyond its own life. This is a way for the object to be at peace and have as little information as possible about what is going on around it.
By following the Law of Demeter, you often naturally create classes with more focused responsibilities, thus supporting the Single Responsibility Principle. Conversely, when a class adheres to SRP, it's often easier to follow the Law of Demeter because it has a well-defined boundary and fewer reasons to reach out to distant objects.
Benefits
- Loose Coupling: Changing a part of the system will not break another part.
- Encapsulation : Each class is responsible for its own logic.
- Better Maintainability: Less knowledge about other objects’ structures means fewer dependencies.
History
The Law of Demeter was proposed by Ian Holland in 1987 at Northeastern University as part of the Demeter Project, an adaptive programming and aspect-oriented programming effort. The project was named after Demeter, the Greek goddess of agriculture, to signify a bottom-up philosophy of programming that is also embodied in the law itself.