|
The Law of Demeter (LoD) is a design guideline for developing software, particularly object-oriented programs. The guideline was invented at Northeastern University, Boston in the fall of 1987, and can be succinctly summarized as "Only talk to your immediate friends". The fundamental notion is that a given object should assume as little as possible about the structure or properties of anything else (including its subcomponents). Computer software (or simply software) refers to one or more computer programs and data held in the storage of a computer for some purpose. ...
In computer science, object-oriented programming, OOP for short, is a computer programming paradigm. ...
Northeastern University is a private university located in Boston, Massachusetts, in the New England region of the United States. ...
1987 is a common year starting on Thursday of the Gregorian calendar. ...
It is so named for its origin in the Demeter Project, an adaptive programming and aspect-oriented programming effort. This project was named in honor of Demeter, "distribution-mother" and goddess of agriculture, to signify a bottom-up philosophy of programming which is also embodied in the law itself. In Software Engineering, the programming paradigm of aspect-oriented programming (AOP) (also called aspect-oriented software development (AOSD)) attempts to aid programmers in the separation of concerns, or the breaking down of a program into distinct parts that overlap in functionality as little as possible. ...
Dêmêtêr (or Demetra) (DEH-MEH-ter) (mother-goddess or perhaps distribution-mother) is the Greek goddess of agriculture, the pure nourisher of youth and the green earth, the health-giving cycle of life and death, and preserver of marriage and the sacred law. ...
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 propagate 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: - itself
- its parameters
- any objects it creates/instantiates
- its direct component objects
In particular, an object should avoid invoking methods of a member object returned by another method. 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 propagate 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.
Literature - V. Basili, L. Briand, W.L. Melo: A Validation of Object-Oriented Design Metrics as Quality Indicators. IEEE Transactions on Software Engineering. October 1996. pp. 751-761. Vol. 22, Number 10.
- Karl J. Lieberherr, I. Holland: Assuring good style for object-oriented programs. IEEE Software, September 1989, pp 38-48.
- Karl J. Lieberherr: Adaptive Object-Oriented Software: The Demeter Method with Propagation Patterns. PWS Publishing Company, International Thomson Publishing, Boston, 1995.
External links |