Law of Demeter 232883 225693105 2008-07-14T22:53:59Z Jwolter 158821 Clarified Objects A, B, and "other object" by adding object C to description. Also added that A could know about C. The '''Law of Demeter (LoD)''', or '''Principle of Least Knowledge''', is a design guideline for developing [[software]], particularly [[Object-oriented programming|object-oriented programs]]. The guideline was invented at [[Northeastern University (Boston, Massachusetts)|Northeastern University]] towards the end 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). 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. Note that it is debatable if bottom-up (or synthetic) is the correct analogy. It can be argued that software evolves or grows, which is appropriate given Demeter's mythological role. 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, C, 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. Or A should have a direct reference to object C and make the call directly. If the law is followed, only object B knows its own internal structure. More formally, the Law of Demeter for functions requires that a method ''M'' of an object ''O'' may only invoke the methods of the following kinds of objects: # ''O'' itself # ''M'''s parameters # any objects created/instantiated within ''M'' # ''O'''s direct component objects In particular, an object should avoid invoking methods of a member object returned by another method. For many modern object oriented languages that use a dot as field identifier, the law can be stated simply as "use only one dot". That is, the code "a.b.Method()" breaks the law where "a.Method()" does not. There is disagreement as to the sufficiency of this approach.[http://www.dcmanges.com/blog/37][http://pivots.pivotallabs.com/users/alex/blog/articles/273-lovely-demeter-meter-maid] As a simple example, when one wants to walk a dog, it would be meaningless to command the dog’s legs to walk directly; instead one commands the dog and lets it take care of its legs itself. [http://c2.com/cgi/wiki?DontConfuseYourDog] 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 sometimes requires writing a large number of small “wrapper” methods (sometimes referred to as Demeter [[Transmogrifier (computer science)|Transmogrifiers]]) to propagate method calls to the components. Furthermore, a class’s interface can become bulky as it hosts methods for contained classes resulting in a class without a cohesive interface. 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 Lieberherr|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. * Andrew Hunt and David Thomas: ''The Pragmatic Programmer: From Journeyman to Master''. Addison-Wesley, Copyright 2002, pp 140-141. * Craig Larman: ''Applying UML and Patterns , 3rd Edition''. Prentice hall, Copyright 2005, pp 430-432 (from this book, "Law of Demeter" is also known as "Don't talk to strangers") * Steve McConnell: ''Code Complete, 2nd Edition''. Microsoft press, Copyright 2004, page 150. == External links == * [http://www.cmcrossroads.com/bradapp/docs/demeter-intro.html Brad Appleton: “Introducing Demeter and its Laws”] * [http://www.ccs.neu.edu/home/lieber/LoD.html Law of Demeter (Web site)] * [http://www.ccs.neu.edu/research/demeter/papers/law-of-demeter/oopsla88-law-of-demeter.pdf “Object-Oriented Programming: An Objective Sense of Style” (OOPSLA '88 Proceedings) (PDF)] * [http://brian.maybeyoureinsane.net/blog/2006/12/15/law-of-demeter-or-how-to-avoid-coding-yourself-into-a-corner-in-rails/ Law of Demeter applied to Ruby on Rails] [[Category:Object-oriented programming]] [[de:Gesetz von Demeter]] [[fr:Loi de Déméter]] [[it:Legge di Demetra]] [[hu:Demeter törvénye]]