SDSU CS535 Object-Oriented Programming & Design
Fall Semester, 1996
Doc 32, Law of Demeter

[To Lecture Notes Index]
San Diego State University -- This page last updated Dec 10, 1996
----------

Contents of Doc 32, Law of Demeter

  1. References
  2. Principles for Achieving Modularity
  3. Law of Demeter1 
Doc 32, Law of Demeter Slide # 1

References


Meyer, Object-Oriented Software Construction, 1988

Lieberherr, Holland, Riel, Object-Oriented Programming: An Objective Sense of Style, OOPSLA 1988 Proceedings


Doc 32, Law of Demeter Slide # 2

Principles for Achieving Modularity

Few Interfaces


Every module should communicate with as few others as possible


Required for:
Continuity
Protection


Small Interfaces


Modules should exchange as little information as possible


Required for:
Continuity
Protection


Counter-example:
Fortran Garbage Common Block 
Doc 32, Law of Demeter Slide # 3
Principles for Achieving Modularity
Explicit Interfaces


Communication between modules must be obvious from the text of the modules


Required for:
Decomposability Composability                 Continuity Understandability

Counter-example:
Aliasing with pointers


Information Hiding

All information about a module should be private unless it is specifically declared public


Required for:
       Decomposability Composability          Continuity Understandability                  

Doc 32, Law of Demeter Slide # 4

Law of Demeter[1]

Weak Form

Inside of a method M of a class C, data can be accessed in and messages can be sent to only the following objects:


Law of Demeter
Strong Form

* Use accessor function to access data members defined in parent classes


Doc 32, Law of Demeter Slide # 5

Law of Demeter Example
class Inside {
   Instructor boring = new Instructor();
   int pay = 5;

   public Instructor getInstructor() {
      return boring;
   }

   public Instructor getNewInstructor() {
      return new Instructor();
   }

   public int getPay() {
      return pay ;
   }

   other public & private methods
   }

class C {
   Inside test = new Inside();

   public void badM() {
      test.getInstructor().fired();
   }

   public void goodM() {
      test.getNewInstructor().hired();
   }

   public int goodOrBadM() {
      return getpay() + 10;
   }
}

Doc 32, Law of Demeter Slide # 6
Correcting badM 
class Inside {
   Instructor boring = new Instructor();
   int pay = 5;

   public Instructor fireInstructor() {
      boring.fired();
   }

   public Instructor getNewInstructor() {
      return new Instructor();
   }

   public int getPay() {
      return pay ;
   }

   other public & private methods
   }

class C {
   Inside test = new Inside();

   public void reformedBadM() {
      test.fireInstructor();
   }

   public void goodM() {
      test.getNewInstructor().hired();
   }

   public int goodOrBadM() {
      return  getpay() + 10;
   }
}


Doc 32, Law of Demeter Slide # 7

Law of Demeter
Benefits

* Coupling control
Reduces data coupling


* Information hiding
Prevents a method from directly retrieving a subpart of an object
* Information restriction
Restricts the use of methods that provide information

* Few interfaces
Restricts the classes that can be used in a method


* Small interfaces
Restricts the amount of information passed in a method


* Explicit interfaces
Explicitly states which classes can be used in a method


----------