Law of Demeter

The Law of Demeter (English: Law of Demeter, in short: LoD ) is a draft directive in object-oriented software development. It essentially says that objects should only communicate with objects in their immediate environment. This is to the coupling ( that is, the number of dependencies) decreases in a software system, and thus the maintainability can be enhanced. It is therefore sometimes referred to as the "principle of secrecy ."

History

The directive was proposed at Northeastern University in Boston in 1987. The name goes back to the Demeter Project, in which the policy was first recognized. This project was developed for a named after the Greek god Zeus hardware description language, which is why the name of Demeter - was elected - in Greek mythology, the sister of Zeus. Later the idea was advertised that software development with the growth of software ( Demeter is the goddess of agriculture) more and has less to do with the building of software.

The law was explained in detail by Karl J. Lieberherr and Ian Holland 1989 Paper Assuring Good Style for Object-Oriented Programs. Due to the formal specification of the use is possible as a software metric. It thus lends itself to a use of the LoD for early detection of maintenance problems.

Description

The policy can be colloquially summarized with the statement " Speak only to your closest friends ." One speaks in this context of a shy code. " Shy Code" so send a few messages as possible to other parts of the code. Formally expressed to a method m of a class K only access the following program elements:

• Methods of K itself
• Methods of parameters of m
• Methods associated with K objects
• Methods of producing objects, the m

Example

The following example ( in Java) violates the Law of Demeter, because the class driver relies indirectly on the class car on a method of the class Engine:

Class Engine {      public void start () {          / / Start the engine.      } } class Car {      public motor motor;      public Car () {          engine = new Engine ();      } } class Driver {      public void run () {          ZuFahrendesAuto car = new Car ();          zuFahrendesAuto.motor.starten (); / / here is against the law      } } A solution here would be to introduce a wrapper method in the Car class, which delegates the call to the class Engine:

Class Car {      private motor car;      public Car () {          engine = new Engine ();      }      public void start () {          motor.starten ();      } } class Driver {      public void run () {          ZuFahrendesAuto car = new Car ();          zuFahrendesAuto.anlassen ();      } } This solution has the advantage that now the start method can be supplemented without the caller must know details about starting the car.

Pros and Cons

In application of the Law of Demeter through the lower dependency ( coupling) should be the objects of the internal structure of other objects better maintainability, testability, and adaptability of the software result ( = essential quality criteria for software according to ISO / IEC 9126 ).

On the other hand, the application often requires intermediaries methods ( wrapper ), which may increase the initial development effort, provided that no automated tools are used for their production. In addition, wrappers can degrade performance slightly and slightly increase memory usage.