1. Smaller, More Evolvable Software: An Introduction to the Demeter Method
Karl J. Lieberherr
Northeastern University
College of Computer Science
1/11/2019
UBS/LoD

2. The Law of Demeter (LoD) and how it should be used in CUBE
1/11/2019
UBS/LoD
Copyright, 1996 © Dale Carnegie & Associates, Inc.

3. Overview Introduction to Demeter Law of Demeter Principle
How it was used at Citibank, JPL etc.
Recommendation
Benefits, Review of Benefits
Close
1/11/2019
UBS/LoD

4. Thanks to Industrial Collaborators/Sponsors
IBM: Theory of contracts, Adaptive Programming
Citibank, SAIC: Adaptive Programming
Mettler Toledo: OO Evolution
Xerox PARC: Aspect-Oriented Programming (Gregor Kiczales et al.)
supported by DARPA (EDCS) and NSF
1/11/2019
UBS/LoD

5. What is Demeter
A high-level interface to object-oriented programming and specification systems
Demeter System/OPL =
Demeter Method + Demeter Tools/OPL
So far: OPL = {Java, C++, Perl, Borland Pascal, Flavors}
Demeter Tools/OPL = Demeter/OPL
1/11/2019
UBS/LoD

6. History: Many good things come from Zurich
Hades (HArdware DEScription language by Niklaus Wirth at ETH Zurich)
Zeus (a brother of Hades, a silicon compilation language developed at Princeton University/MIT, implemented at GTE Labs; predecessor of VHDL)
Demeter (a sister of Zeus, used to implement Zeus, started at GTE Labs)
1982
82-85
1985-
1/11/2019
UBS/LoD

7. History Law of Demeter First traversal specifications
1987
Law of Demeter
First traversal specifications
Synchronization as an aspect
Fast and general compilation algorithm
APPCs (Adaptive Plug-and-Play Components)
1990
1993
1996/97
1998
1/11/2019
UBS/LoD

8. Law of Demeter What is it: Style Rule for building 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.
1/11/2019
UBS/LoD

9. 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.
1/11/2019
UBS/LoD

10. Law of Demeter
FRIENDS
1/11/2019
UBS/LoD

11. “closely related”
1/11/2019
UBS/LoD

12. 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.
1/11/2019
UBS/LoD

13. 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.
1/11/2019
UBS/LoD

14. 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 LoD extensively include … Mars Pathfinder Software (begun in 1993). We are going to use LoD as a foundational software engineering principle for the X2000 Europa orbiter mission.
1/11/2019
UBS/LoD

15. What others say about the Law of Demeter
Two examples:
Booch
Rumbaugh
1/11/2019
UBS/LoD

16. Booch and the Law of Demeter
Context
Chapter: Classes and Objects, Section: On Building Quality Classes and Objects, Subsection: Choosing Relationships
1/11/2019
UBS/LoD

17. 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.
1/11/2019
UBS/LoD

18. Rumbaugh and the Law of Demeter
Context
Chapter: Programming Style, Section: Extensibility
1/11/2019
UBS/LoD

19. 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.
1/11/2019
UBS/LoD

20. 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.
1/11/2019
UBS/LoD

21. Agreement that LoD Good Idea
How to follow LoD: good solutions exist but not widely known. Two approaches to following LoD:
OO approach
Adaptive approaches
Traversal support
APPC
Demeter/Java
1/11/2019
UBS/LoD

22. 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();}
1/11/2019
UBS/LoD

23. Violations: Dataflow Diagram
2:c
foo()
1:b B C A
4:q()
bar()
3:p() P Q
1/11/2019
UBS/LoD

24. OO Following of LoD m foo2 c foo() 1:b B C A 2:foo2() 4:bar2() bar2
3:p()
q() P Q
1/11/2019
UBS/LoD

25. Adaptive Following of LoD
void A::m() {
(C)
Traversal.long_get(this,”A->C”).foo();
(Q)
Traversal.long_get(this,”A->Q”).bar();}
this.b.c.foo(); this.p().q().bar();} // violation
1/11/2019
UBS/LoD

26. Law of Demeter
FRIENDS
1/11/2019
UBS/LoD

27. What if your friends are far away?
You pay them to travel to you or you send an agent to them to collect the information you need.
Approximate Directions: You give them or your agent directions about what kind of information to collect but you don’t care about accidental details of the travel.
Detailed Directions: You give them or your agent detailed travel directions.
1/11/2019
UBS/LoD

28. Adaptive Following LoDC A
FRIENDS a S X c b
a:From S to A
b:From S to B c:From S via X to C
1/11/2019
UBS/LoD

29. Traversal strategies create friends
Class Traversal is an intermediate class between classes that need to communicate
Traversal.long_get(Object o, Strategy s)
1/11/2019
UBS/LoD

30. Are not friends for accidental reasons
Other classes exist for other reasons
Ideal class graph: all are friends, even “far” away classes.
1/11/2019
UBS/LoD

31. Adaptive Following LoD: Key idea
Introduce an ideal class graph
Write current behavior in terms of ideal class graph
Map ideal class graph flexibly into concrete class graph using traversal strategies
1/11/2019
UBS/LoD

32. Adaptive Following of LoD: Key Idea
Collaborations are not explicit in the software. This is what APPCs will support. So why?
1/11/2019
UBS/LoD

33. Motivation OOAD Implementation --> Tangling Collab-1 C1 C4 C2 C3 C5Z C1 C4 C2 C3 C5
Collab-4
Collab-2
Collab-3 C1 C2 C3 C4 C5
Object-oriented languages do not provide adequate constructs to capture
collaborations between several classes.
Has been recognized in different forms in the object-oriented community:
OO accommodates the addition of new variants of data types better than
procedural programming but, the opposite is true when new operations on existing
data types are needed
visitor pattern: the matter of concern -- definition of new operations on
an existing object structure (aggregation is involved besides inheritance)
several works complain the lack of constructs for expressing
collaboration-based designs
Implementation
Collaboration --
a distinct (relatively independent aspect of an application that involves several
participants, or roles
roles played by application classes
each class may play different roles in different collaborations
each role embodies a separate aspect of the overall class behavior
--> Tangling
1/11/2019
UBS/LoD
Collaboration-based design s Require to view oo applications in two different ways:
(a) in terms of participants or types involved
(b) in terms of the tasks or concerns of the design

34. What is the Problem? “OO technology has not met its expectations
when applied to real business applications partly
due to the fact that there is no place where to put
higher-level operations which affect several objects.
… if built into the classes involved, it is impossible to get
an overview of the control flow. It is like reading a road
map through a soda straw'’
[Lauesen, IEEE Software, April ‘98]
1/11/2019
UBS/LoD

35. SE Group at UBI Lab Important work done there: Framework integration
Role modeling
1/11/2019
UBS/LoD

36. Design Goal: Adaptiveness
one generic
collaboration P3 P1
reused
APPL 1 C1 C1
APPL C2 C4 n C2
Requirements on the design:
Generic specification of the collaboration with respect to the class
structure it will be applied to: \
(a) the same component to be used with several different
concrete applications, and
(b) one collaborative component to be mapped in different
ways, i.e., with different class-to-participant
mappings, into the same class structure.
Loose coupling of behavior to structure C3 C3 C4 C5
with a family of concrete applications
1/11/2019
UBS/LoD

37. Design Goal: Adaptiveness
one generic
collaboration P3 P1
reused
with different mappings
of participants to classes
APPL 1 C1
APPL C1 1 C4 C4 C5 C5 C2 C3 C2 C3
OK, we want a construct
(1) orthogonal to the standard object-oriented models -
not substitute, rather complement classes
(2) support a decomposition granularity that lies between classes and package
modules a la Oberon
But, what do we mean by adaptive?
of the same application
1/11/2019
UBS/LoD

38. Recommendation
I recommend that the CUBE project use the Law of Demeter Principle in OO designs and programs and that the Law of Demeter be followed in an adaptive, collaboration-based style (Demeter style).
Justfication: Works well for Citibank, JPL, Hewlett-Packard and many other companies.
1/11/2019
UBS/LoD

39. Benefits of following Law of Demeter in Demeter Style
robustness to changes
shorter programs
design matches program
more understandable code
partially automated evolution
keep all benefits of OO technology
improved productivity
ideas can be used without tools
Applicable to design and documentation
of your current systems with immediate benefits.
1/11/2019
UBS/LoD

40. Benefits Review
Robustness to changes: Elimination of violations of LoD in OO style leads to many tiny methods. Statistics from (Wilde, Matthews, Huitt, 1993): More than half of the member functions and methods have fewer than two C++ statements or four Smalltalk lines of code. Those tiny methods will be generated.
1/11/2019
UBS/LoD

41. Benefits Review
Shorter programs : Tiny methods observed by Wilde et al. don’t have to be written and maintained. Programs get shorter.
1/11/2019
UBS/LoD

42. UML Class Diagram busStops BusRoute BusStopList buses 0..* BusStop
BusList
Example for developing strategies and writing adaptive programs
waiting
0..*
passengers
Bus
PersonList
Person
0..*
1/11/2019
UBS/LoD

43. find all persons waiting at any bus stop on a bus route
Traversal Strategy
from BusRoute through BusStop to Person
busStops
BusRoute
BusStopList
buses
0..*
BusStop
BusList
waiting
0..*
passengers
Bus
PersonList
Person
0..*
1/11/2019
UBS/LoD

44. Robustness of Strategy
find all persons waiting at any bus stop on a bus route
Robustness of Strategy
from BusRoute through BusStop to Person
villages
BusRoute
BusStopList
buses
VillageList
busStops
0..*
0..*
BusStop
BusList
Village
waiting
0..*
passengers
Bus
PersonList
Person
0..*
1/11/2019
UBS/LoD

45. Benefits Review
Design matches program: Because each behavior is written for an ideal class graph behavior is well encapsulated and easier to understand because of noise elimination.
1/11/2019
UBS/LoD

46. Benefits Review
Partially automated evolution: tiny traversal methods are automatically regenerated when structure changes. Programmer needs to test them.
1/11/2019
UBS/LoD

47. Benefits Review
Keep all benefits of OO technology: all code is written in plain Java with a traversal package added. You can use all good ideas of OO technology.
1/11/2019
UBS/LoD

48. Benefits Review
Improved productivity: Several testimonials. Example: Hewlett-Packard Printer Installation Software is written in Demeter Style using C++.
Televised Demeter class with student in Vancouver, Canada, lead to prototype.
Prototype was so successful that entire package was re-implemented.
1/11/2019
UBS/LoD

49. Dangers if Law of Demeter Principle not followed adaptively
CUBE might get as hard to maintain as ABACUS because structural information will be duplicated many times.
CUBE code will be tangled: hard to understand and to maintain.
1/11/2019
UBS/LoD

50. During implementation separate issues are mixed together
What is the problem? Tangling!
During implementation
separate issues
are mixed together
in den vorherigen Kapiteln wurde erklärt:
1. in der Informatik darum, Rechnermodelle zu bauen, die Prozessen in der
reellen Welt simulieren.
2. Es gibt formale Mitteln, die es erlauben, die Modelle in eine für den
Rechner verständlich en Sprache zu schreiben.t.
In dieser Vorlesung erden wir das sogenannte objekt-orientierte Programmiermodel als das Mittel für die Beschreibung der Modelle benutzen.
Mit anderen Worten, werden wir objekt-orientierte Rechnermodelle der reellen
Welt bauen. Wir werden zuerst, die Konstrukte des objekt-orientierten Programmiermodels kennenlernen, d.h. die Bestandteile unsere Toolboxes.
Als zweites werden wir kurz
During maintenance individual
issues need to be
factored out of the tangled code
1/11/2019
UBS/LoD

51. Cross-cutting of components and aspects
better program
ordinary program
structure-shy
functionality
Components
structure
Aspect 1
avoid tangled programs
AOP
synchronization
Aspect 2
1/11/2019
UBS/LoD

52. Close
I recommend that the Law of Demeter Principle be used in a Demeter Style in the CUBE project.
Benefits: More flexible and simpler programs that can more easily be adapted to new business needs.
1/11/2019
UBS/LoD

53. Questions ?!

54. More details
Traversal support
Strategy graphs
APPCs
1/11/2019
UBS/LoD

55. Traversal Support for Java: class Traversal
static Object long_get(Object o, Strategy s);
static Iteration long_collect(Object o, Strategy s);
static Object traverse(Object o, Strategy s, Visitor v[]);
1/11/2019
UBS/LoD

56. Traversal Support for Java
static X long_get(Object o, Strategy s);
starting at object o, traverse down following s and return target object of s
s must have a single target and s must specify unique path
1/11/2019
UBS/LoD

57. Traversal Support for Java
static Iteration long_collect(Object o, Strategy s);
starting at object o traverse following s and return the collection of target objects of s.
1/11/2019
UBS/LoD

58. Traversal Support for Java
static Object traverse(Object o, Strategy s, Visitor v[]);
starting at object o traverse down following s and execute the visitors in v. Return the object returned by first visitor.
1/11/2019
UBS/LoD

59. Traversal Support: visitors
class SampleVisitor extends Visitor{
// local variables
public SampleVisitor(); // initialize
public void before(Visited host);
public void after (Visited host);
public void before_z(X source, Y dest);
public void after_z (X source, Y dest);
Object get_return_val();
public void start();
public void finish(); }
1/11/2019
UBS/LoD

60. Traversal Support: visitors
abstract class Visitor {
// GENERATED CODE EXAMPLE
public Visitor() {super();}
public void start() { }
public void finish() { }
public void before(Visited host);
public void after (Visited host);
public void before_p(Q source, H dest);
public void after_p (Q source, H dest); … }
1/11/2019
UBS/LoD

61. Refinement definition
A graph G is a refinement-instance of a graph S, if S is a connected subgraph of the pure transitive closure of G with respect to the node set of S.
1/11/2019
UBS/LoD

62. Pure transitive closure
The pure transitive closure of G=(V,E) with respect to a subset W of V is the graph G*=(V,E*), where E*={(i,j): there is a W-pure path from vertex i to vertex j in G}.
A W-pure path from i to j is a path where i and j are in W and none of the inner points of the path are in W.
1/11/2019
UBS/LoD

63. G1 refinement G2 F F D D E E B B C C G2 G1 A A
refinement: connectivity of G2
is in pure form in G1
Allows extra connectivity. G1 A A

64. The APPC Pattern
Benefiting from advances in component software technology using standard languages
1/11/2019
UBS/LoD

65. Design patterns and programming language features
They are conceptually equivalent.
Useful to explain language features using design pattern terminology.
Danger of design patterns: workarounds needed to implement them can be tedious. Patterns are only used if benefit outweighs the cost.
1/11/2019
UBS/LoD

66. Motivation
New component software ideas have a big acceptance threshold if they require non-standard language extensions.
Use many of the good ideas with standard languages and suitable libraries/frameworks without language extension.
Describe ideas using pattern terminology for easy reuse by designers/programmers.
1/11/2019
UBS/LoD

67. The APPC Pattern
Benefiting from advances in component software technology using standard languages
1/11/2019
UBS/LoD

68. A C
View B
Map A C X
Host B
1/11/2019
UBS/LoD

69. Design patterns and programming language features
They are conceptually equivalent.
Useful to explain language features using design pattern terminology.
Danger of design patterns: workarounds needed to implement them can be tedious. Patterns are only used if benefit outweighs the cost.
1/11/2019
UBS/LoD

70. Motivation
New component software ideas have a big acceptance threshold if they require non-standard language extensions.
Use many of the good ideas with standard languages and suitable libraries/frameworks without language extension.
Describe ideas using pattern terminology for easy reuse by designers/programmers.
1/11/2019
UBS/LoD

71. APPC:Intent
Filter out noise from implementations: Describe popular behavior in terms of an idealized class structure (ideal class graph = view), using traversal strategy graphs and visitors as appropriate.
Map idealized class structure to concrete class structure using traversal strategy graphs as appropriate.
1/11/2019
UBS/LoD

72. APPC:Motivation
Have an encapsulated unit for behavioral abstraction for new behavior covering multiple classes.
Concrete class structures are overworked and to favor reusability each behavior should be expressed in terms of an idealized class structure that is mapped flexibly into a concrete class structure.
1/11/2019
UBS/LoD

73. Motivation
ICG/CCG approach not only favors reusability, but it also makes programs simpler.
Program towards an abstract structure.
Distinguish between "IS-A" and "PLAYS-THE-ROLE-OF" relationships.
1/11/2019
UBS/LoD

74. Motivation Make visitor pattern more flexible.
Reuse with different class structures or multiple times in same class structure.
1/11/2019
UBS/LoD

75. APPC:Applicability Use to implement "popular" behaviors.
Whenever you have a class hierarchy (IS-A) and a behavior assignment to classes (PLAYS-THE-ROLE-OF) so that the IS-A structure cross-cuts the behavior assignment.
1/11/2019
UBS/LoD

76. APPC:Applicability
Whenever the implementation of a behavior uses classes that are not central to the behavior.
1/11/2019
UBS/LoD

77. APPC:Structure Strategy graph, expansion Ideal class graph, expansion
An APPC has local data and functions and a constructor and an upstream and downstream interface.
1/11/2019
UBS/LoD

78. APPC:Structure
An APPC provides an implementation for a set of functions (the upstream interface) that modify classes that implement the downstream interface of the APPC.
1/11/2019
UBS/LoD

79. APPC:Implementation Code runs in CCG objects.
Demeter/Java also uses this approach
1/11/2019
UBS/LoD

80. APPC:Implementation
Mapping from ICG to CCG is best specified with Traversal Support for Java.
1/11/2019
UBS/LoD

81. Law of APPCs
The downstream interface must be a set of pure abstract functions.
Clients of the APPC must not use the downstream interface.
1/11/2019
UBS/LoD

82. Law of APPCs
The implementation of the popular functions must be protected against changes by the client classes.
1/11/2019
UBS/LoD

83. Law of APPCs
The implementation of popular functions is allowed to use the DI/UI/local methods and methods of classes returned by the DI/UI/local methods and nothing more (Application of Law of Demeter Principle).
Less restrictive but it is ok to have violations of standard LoD.
1/11/2019
UBS/LoD

84. Simulating APPCs Translate UI into Java interface.
Assigning to class structure: use delegation to ego objects.
1/11/2019
UBS/LoD