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.