OO Programming in Java

Class 7 Material

Law of Demeter


Full Report (Postscript)

Brief Excerpts Given Below

\/




Karl J. Lieberherr and Ian Holland

We introduce a simple, programming language independent rule (known in­house as
the Law of Demeter) which encodes the ideas of encapsulation and modularity in an
easy to follow form for the object­oriented programmer. The rule achieves the following
related benefits if code duplication, the number of method arguments and the number
of methods per class are minimized: Easier software maintenance, less coupling between
your methods, better information hiding, methods which are easier to reuse, and easier
correctness proofs using structural induction. We show relationships between the Law and
software engineering techniques, such as coupling control, information hiding, information
restriction, localization of information, narrow interfaces and structural induction. We
discuss two important interpretations of the Law (strong and weak) and we prove that
any object­oriented program can be transformed to satisfy the Law. We express the
Law in several languages which support object­oriented programming, including Flavors,
Smalltalk­80, CLOS, C++ and Eiffel.

Our experience has been that the Law promotes maintainability and comprehensibility of the
software. This is a result of the small method size and the predicable message­passing patterns,
both of which are caused by the application of the Law. In other words, following the Law in
concert with rules such as, minimizing code duplication, minimizing the number of arguments,
and minimizing the number of methods, produces code with a characteristic and manageable
form
.
We have also seen that adherence to the Law prevents programmers from encoding details of
the class hierarchy structure in the methods. This is critical to the goal of making the code
robust with respect to changes in the hierarchy structure. These changes occur very frequently
in the early stages of development.

The goal of the Law of Demeter is to organize and reduce the behavioral dependencies between
classes. Informally, one class behaviorally depends on another class when it calls a method
(through a message sent to an object) defined in the other class. The behavioral dependencies
encoded in the methods of an object­oriented program determine the complexity of the pro­
gram's control flow and the level of coupling between the classes. This paper examines these
relationships and illustrated how the Law impacts their existence.

The key contribution of the Demeter system is to improve programmer productivity by sev­
eral factors. This is achieved in a number of ways. First, Demeter provides a comprehensive
standard library of utilities. Second, a significant amount of code is generated from the pro­
grammers object­oriented design. Third, Demeter includes a number of tools that automate
common programming practices.

Definition : A supplier object to a method M is an object to which a
message is sent in M. The preferred supplier objects to method M are:

- the immediate parts of self or
- the argument objects of M or
- the objects which are either objects created directly in M or objects in
global variables.

The programmer determines the granularity of the phrase ``immediate subparts'' of self for the
application at hand. For example, the immediate parts of a list class are the elements of the
list. The immediate parts of a ``regular'' class object are the objects stored in its instance
variables.