Law of Demeter
The Law of Demeter ( English Law of Demeter , short LoD ) is a draft directive in the object-oriented software development . It basically says that objects should only communicate with objects in their immediate vicinity. This is intended to reduce the coupling (i.e. the number of dependencies) in a software system and thus increase maintainability . This is why it is sometimes referred to as the “principle of confidentiality”.
history
The guideline was proposed in 1987 at Northeastern University in Boston . The name goes back to the Demeter project in which the guideline was first recognized. This project was developed for a hardware description language named after the Greek god Zeus , which is why the name Demeter - a sister of Zeus in Greek mythology - was chosen. It was only later that the idea was promoted that software development had more to do with growing software ( Demeter is the goddess of agriculture) and less with building software.
The law was explained in detail by Karl J. Lieberherr and Ian Holland in 1989 in the paper Assuring Good Style for Object-Oriented Programs . The formal specification makes it possible to use it as a software metric. The LoD can therefore be used for the early detection of maintenance problems.
description
The guideline can be colloquially summarized as the statement "only speak to your closest friends". In this context, one speaks of shy code . "Shy Code" sends as few messages as possible to other pieces of code. Expressed formally, a method m of a class K should only access the following program elements:
- Methods by K himself
- Methods of objects that are passed as parameters to m
- Methods of objects that are stored in instance variables of K.
- Methods of objects that generated m
example
The following example (in Java ) violates Demeter's law, as the class Fahrerindirectly accesses Autoa method of the class via the class Motor:
class Motor {
public void anlassen() {
// den Motor starten.
}
}
class Auto {
private Motor motor;
public Auto() {
motor = new Motor();
}
public Motor getMotor() {
return motor;
}
}
class Fahrer {
public void fahren() {
Auto zuFahrendesAuto = new Auto();
zuFahrendesAuto.getMotor().anlassen(); //hier wird gegen das Gesetz verstoßen
}
}
A solution here would be to introduce a wrapper method in the class Auto, which Motor delegates the call to the class :
class Auto {
private Motor motor;
public Auto() {
motor = new Motor();
}
public void fahrbereitmachen() {
motor.anlassen();
}
}
class Fahrer {
public void fahren() {
Auto zuFahrendesAuto = new Auto();
zuFahrendesAuto.fahrbereitmachen();
}
}
This solution has the advantage that the fahrbereitmachenmethod can now be modified as required without the caller having to know details about it. An electric car without a starter could thus be operated in the same way. The method getMotor()is then not required at all for this application, so it is not part of the interface for a Auto.
Advantages and disadvantages
When applying Demeter's law, the lower dependency ( coupling ) of the objects on the internal structure of other objects should result in better maintainability , testability and adaptability of the software (= essential quality criteria for software according to ISO / IEC 9126 ).
On the other hand, the application often requires intermediary methods ( wrappers ), which can increase the initial development effort if no automated tools are used to generate them. In addition, wrappers can degrade performance slightly and increase memory consumption slightly.
Individual evidence
- ↑ What is Demeter? Retrieved on December 30, 2009 (English): “The Law of Demeter was developed early during the Demeter project by Ian Holland et al. and it provided the motivation for the work on Adaptive Programming. We called it "Law of Demeter" because we discovered it while working on Demeter but it is a general style rule for structure-shy programming. ... The Demeter project was named after Demeter because we were working on a hardware description language Zeus and we were looking for a tool to simplify the implementation of Zeus. We were looking for a tool name related to Zeus and we chose a sister of Zeus: Demeter. Later we promoted the idea that Demeter-style software development is about growing software as opposed to building software. "
- ^ Karl J. Lieberherr, I. Holland: Assuring good style for object-oriented programs . In: IEEE software . S. 38-48 ( psu.edu [accessed February 27, 2010]).