When applied to object-oriented programs, the Law of Demeter can be more precisely called the "Law of Demeter for Functions/Methods" (LoD-F). In this case, an object A can request a service (call a method) of an object instance B, but object A cannot "reach through" object B to access yet another object to request its services. Doing so would mean that object A implicitly requires greater knowledge of object B's internal structure. Instead, B's class should be modified if necessary so that object A can simply make the request directly of object B, and then let object B propogate the request to any relevant subcomponents. If the law is followed, only object B knows its internal structure.
More formally, the Law of Demeter for functions requires that any method M of an object O may only invoke the methods of the following kinds of objects:
The advantage of following the Law of Demeter is that the resulting software tends to be more maintainable and adaptable. Since objects are less dependent on the internal structure of other objects, object containers can be changed without reworking their callers.
A disadvantage of the Law of Demeter is that it requires writing a large number of small "wrapper" methods to propogate method calls to the components - these can increase initial development time, increase space overhead, and noticeably decrease performance. Automated tools exist to at least partially counteract these problems.
Basili et al published experimental results in 1996 suggesting that the Law of Demeter was a valid way to reduce the probability of software faults.
External Links