„Gesetz von Demeter“ – Versionsunterschied

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen
[ungesichtete Version][ungesichtete Version]
Inhalt gelöscht Inhalt hinzugefügt
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
Zeile 82: Zeile 82:
* [http://www.bradapp.com/docs/demeter-intro.html ''Introducing Demeter and its Laws'']
* [http://www.bradapp.com/docs/demeter-intro.html ''Introducing Demeter and its Laws'']
* [http://www.ccs.neu.edu/home/lieber/LoD.html Law of Demeter]
* [http://www.ccs.neu.edu/home/lieber/LoD.html Law of Demeter]
* [http://www.ccs.neu.edu/research/demeter/papers/law-of-demeter/oopsla88-law-of-demeter.pdf Object-Oriented Programming: An Objective Sense of Style]
* [https://dzone.com/articles/the-genius-of-the-law-of-demeter The Genius of the Law of Demeter]


{{Navigationsleiste Prinzipien objektorientierten Designs}}
{{Navigationsleiste Prinzipien objektorientierten Designs}}

Version vom 20. Mai 2017, 00:50 Uhr

Das Gesetz von Demeter (englisch: Law of Demeter, kurz: LoD) ist eine Entwurfs-Richtlinie in der objektorientierten Softwareentwicklung. Sie besagt im Wesentlichen, dass Objekte nur mit Objekten in ihrer unmittelbaren Umgebung kommunizieren sollen. Dadurch soll die Kopplung (das heißt die Anzahl von Abhängigkeiten) in einem Softwaresystem verringert und somit die Wartbarkeit erhöht werden. Es wird deswegen manchmal auch als „Prinzip der Verschwiegenheit“ bezeichnet.

Geschichte

Die Richtlinie wurde 1987 an der Northeastern University in Boston vorgeschlagen. Der Name geht auf das Demeter-Projekt zurück, in dem die Richtlinie erstmals erkannt wurde. Dieses Projekt wurde für eine nach dem griechischen Gott Zeus benannte Hardware-Beschreibungssprache entwickelt, weshalb der Name Demeter – in der griechischen Mythologie eine Schwester von Zeus – gewählt wurde. Später erst wurde die Idee beworben, dass Softwareentwicklung mehr mit dem Wachsen von Software (Demeter ist die Göttin der Landwirtschaft) und weniger mit dem Bauen von Software zu tun hat. [1]

Das Gesetz wurde auf der 3. OOPSLA 1988 in San Diego, California von K. Lieberherr, I. Holland und A. Riel im Paper Object-Oriented Programming: An Objective Sense of Style beschrieben.[2]

Eine detaillierte Erläuterung hat nochmals von Karl J. Lieberherr und Ian Holland 1989 im Paper Assuring Good Style for Object-Oriented Programs stattgefunden.[3] Durch die formale Spezifikation ist die Verwendung als Softwaremetrik möglich. Es bietet sich somit ein Einsatz des LoD zur Früherkennung von Wartungsproblemen an.

Beschreibung

Definition

Für alle Klassen K und für alle Methoden m von K sei, dass alle Objekte an die m Nachrichten sendet, gilt

  • es ist Methodenparameter von m einschließlich des Objekts selbst
  • es ist eine Instanzvariable von K

(Objekte, die durch m oder durch Methoden, die m aufgerufen hat, erzeugt wurden und Objekte im globalen Variablen werden wie Methodenparameter von m behandelt.)

Auslegung

Die Richtlinie kann umgangssprachlich zu der Aussage „Sprich nur zu deinen nächsten Freunden“ zusammengefasst werden. Man spricht in diesem Zusammenhang auch von schüchternem Code. „Schüchterner Code“ schickt so wenige Nachrichten wie möglich an andere Codeteile. Formal ausgedrückt soll eine Methode m einer Klasse K ausschließlich auf folgende Programm-Elemente zugreifen:

  • Methoden von K selbst
  • Methoden der Parameter von m
  • Methoden der mit K assoziierten Objekte
  • Methoden von Objekten, die m erzeugt

Beispiel

Das folgende Beispiel (in Java) verstößt gegen das Demeter-Gesetz, da die Klasse Fahrer indirekt über die Klasse Auto auf eine Methode der Klasse Motor zurückgreift:

class Motor {
    public void starten() {
        // den Motor starten.
    }
}
class Auto {
    public Motor motor;
    public Auto() {
        motor = new Motor();
    }
}
class Fahrer {
    public void fahren() {
        Auto zuFahrendesAuto = new Auto();
        zuFahrendesAuto.motor.starten(); //hier wird gegen das Gesetz verstoßen
    }
}

Eine Lösung wäre hier, eine Wrapper-Methode in der Klasse Auto einzuführen, welche den Aufruf an die Klasse Motor delegiert:

class Auto {
    private Motor motor;
    public Auto() {
        motor = new Motor();
    }
    public void anlassen() {
        motor.starten();
    }
}
class Fahrer {
    public void fahren() {
        Auto zuFahrendesAuto = new Auto();
        zuFahrendesAuto.anlassen();
    }
}

Diese Lösung hat den Vorteil, dass nun die anlassen-Methode beliebig ergänzt werden kann, ohne dass der Aufrufer Details über das Anlassen eines Autos kennen muss.

Vor- und Nachteile

Bei Anwendung des Gesetzes von Demeter sollte sich durch die geringere Abhängigkeit (Kopplung) der Objekte von der internen Struktur anderer Objekte eine bessere Wartbarkeit, Testbarkeit und Anpassbarkeit der Software (= wesentliche Qualitätskriterien für Software nach ISO/IEC 9126) ergeben.

Andererseits erfordert die Anwendung häufig Vermittler-Methoden (Wrapper), was den initialen Entwicklungsaufwand erhöhen kann, sofern keine automatisierten Werkzeuge zu ihrer Erzeugung eingesetzt werden. Außerdem können Wrapper die Performance geringfügig verschlechtern und den Speicherverbrauch leicht erhöhen.

Einzelnachweise

  1. What is Demeter? Abgerufen am 30. Dezember 2009 (englisch): „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.“
  2. K. Lieberherr, I.Holland, A.Riel: Object-Oriented Programming: An Objective Sense of Style. In: OOPSLA'88 Proceding. September 1988 (neu.edu [PDF; abgerufen am 20. Mai 2017]).
  3. Karl J. Lieberherr, I. Holland: Assuring good style for object-oriented programs. In: IEEE Software. S. 38–48 (psu.edu [abgerufen am 27. Februar 2010]).