The Law of Demeter Lo D and how




















- Slides: 20
The Law of Demeter (Lo. D) and how it should be used 10/2/2020 Lo. D: Class Design Copyright, 1996 © Dale Carnegie & Associates, Inc. 1
Law of Demeter • What is it: Style Rule for building objectoriented systems. • Proposed by my research group: The Demeter Research Group in 1987, published in 1988. • Covered in many major books on OO design and programming. 10/2/2020 Lo. D: Class Design 2
Law of Demeter Principle • Each unit should only use a limited set of other units: only units “closely” related to the current unit. • “Each unit should only talk to its friends. ” “Don’t talk to strangers. ” • Main Motivation: Control information overload. We can only keep a limited set of items in short-term memory. 10/2/2020 Lo. D: Class Design 3
Law of Demeter FRIENDS 10/2/2020 Lo. D: Class Design 4
“closely related” 10/2/2020 Lo. D: Class Design 5
Application to OO • Unit = method – closely related = • methods of class of this/self and other argument classes • methods of immediate part classes (classes that are return types of methods of class of this/self) • In the following we talk about this application of the Law of Demeter Principle to OO: example follows in a few slides. 10/2/2020 Lo. D: Class Design 6
Citibank Quote: Law of Demeter • The Law of Demeter forms one of the cornerstones of the design approach of the Global Finance Application Architecture (quote from: Global Finance Application Architecture: Business Elements Analysis, Oct. 1991, Citibank confidential document) • Widely used in big projects, for example, at JPL for the Mars exploration software. 10/2/2020 Lo. D: Class Design 7
Jet Propulsion Laboratory(JPL) Quote: Law of Demeter • The Law of Demeter … has taken a firm hold in many areas of JPL. Major systems which have used Lo. D extensively include … Mars Pathfinder Software (begun in 1993). We are going to use Lo. D as a foundational software engineering principle for the X 2000 Europa orbiter mission. 10/2/2020 Lo. D: Class Design 8
What others say about the Law of Demeter • To get a better understanding – Booch – Rumbaugh 10/2/2020 Lo. D: Class Design 9
Booch and the Law of Demeter Context Chapter: Classes and Objects, Section: On Building Quality Classes and Objects, Subsection: Choosing Relationships 10/2/2020 Lo. D: Class Design 10
Booch and the Law of Demeter Quote: The basic effect of applying this Law is the creation of loosely coupled classes, whose implementation secrets are encapsulated. Such classes are fairly unencumbered, meaning that to understand the meaning of one class, you need not understand the details of many other classes. 10/2/2020 Lo. D: Class Design 11
Rumbaugh and the Law of Demeter Context Chapter: Programming Style, Section: Extensibility 10/2/2020 Lo. D: Class Design 12
Rumbaugh and the Law of Demeter Quote: Avoid traversing multiple links or methods. A method should have limited knowledge of an object model. A method must be able to traverse links to obtain its neighbors and must be able to call operations on them, but it should not traverse a second link from the neighbor to a third class. 10/2/2020 Lo. D: Class Design 13
Law of Demeter (alternative formulation) A method should have limited knowledge of an object model. Leads to another Demeter favorite: Use grammars to define both class structure and an application-specific language. See the Structure-Shy Object Pattern. 10/2/2020 Lo. D: Class Design 14
Agreement that Lo. D Good Idea • How to follow Lo. D: good solutions exist but not widely known. Two approaches to following Lo. D: – OO approach – Adaptive approaches • Traversal support • APPC • Demeter/Java 10/2/2020 Lo. D: Class Design 15
Law of Demeter FRIENDS 10/2/2020 Lo. D: Class Design 16
The Law of Demeter (cont. ) Violation of the Law class A {public: void m(); P p(); B b; }; class B {public: C c; }; class C {public: void foo(); }; class P {public: Q q(); }; class Q {public: void bar(); }; void A: : m() { this. b. c. foo(); this. p(). q(). bar(); } 10/2/2020 Lo. D: Class Design 17
Violations: Dataflow Diagram m B A foo() 2: c 1: b C 4: q() bar() 3: p() P 10/2/2020 Lo. D: Class Design Q 18
Adaptive Following of Lo. D void A: : m() { (C) cg. fetch(this, ”A->C”). foo(); (Q) cg. fetch(this, ”A->Q”). bar(); } void A: : m() { this. b. c. foo(); this. p(). q(). bar(); } // violation 10/2/2020 Lo. D: Class Design 19
OO Following of Lo. D m foo 2 B 2: foo 2() 4: bar 2() A foo() c 1: b C bar 2 bar() 3: p() P 10/2/2020 Lo. D: Class Design q() Q 20