Law of Demeter (LoD) Um das Law of Demeter (Gesetz von Demeter) in
der Softwareentwicklung geht es im achten Wissenshäppchen. TL;DR
Mit dem Law of Demeter hältst du deinen Code unabhängig vom inneren
Aufbau anderer Objekte, indem du Aufgaben an die zuständigen
Objekte weitergibst. An einem Versicherungsbeispiel zeige ich dir,
wie dadurch fachliche Logik in die passenden Klassen gelangt und
Tests einfacher werden. Zusätzliche Methoden können dabei
Boilerplate erzeugen, weshalb du bei weitgehend festen
Objektstrukturen abwägen solltest, wie konsequent du die Regel
anwendest. Kapitelmarken [00:00:00] Einstieg ins Law of Demeter
[00:00:39] Woher der Name Demeter stammt [00:01:18] Definition und
Prinzip des geringsten Wissens [00:03:08] Verkettete Zugriffe am
Beispiel Person und Adresse [00:05:02] Kapselung und
Geheimnisprinzip [00:06:32] Abhängigkeiten bei internen Änderungen
[00:08:04] Aufwand für Tests und Stubs [00:09:37] Merkhilfe:
Methoden sprechen mit ihren Freunden [00:10:29] Globale Variablen
und Singletons [00:11:26] Praxisbeispiel: Gesamtbeitrag einer
Versicherungspolice [00:13:09] Fachliche Logik auf die zuständigen
Klassen verteilen [00:15:28] Vorteile für verständlichen und
testbaren Code [00:16:43] Boilerplate und weitgehend feste
Objektstrukturen [00:19:07] Regel im Überblick [00:19:54] Warum
Zwischenvariablen die Abhängigkeit erhalten [00:20:31] Buchhinweis
und weiterführende Codebeispiele Inhalt Das Law of Demeter sagt
aus, dass eine Methode nur Zugriff auf die folgenden
Objekte/Methoden haben sollte: Andere Instanzmethoden in ihrer
eigenen Klasse Ihre Parameter Methoden in Objekten, die sie selbst
erzeugt Globale Variablen Eine einfache andere Definition lautet:
Verkette keine Methodenaufrufe ("method chaining"). Oder: Verwende
nicht mehr als einen ., wenn du auf etwas zugreifst. Ein anderer
Name für das LoD ist "Prinzip des geringsten Wissens" ("principle
of least knowledge"). Der Name stammt von Demeter, einer
griechischen Göttin. Der "Erfinder" des Prinzips entwickelte in den
80er-Jahren ein System mit diesem Namen. Erklärung Vorweg: Globale
Variablen waren in den 80ern hip, heute nicht mehr. Bitte verwende
sie am besten gar nicht. Je mehr "Punkte" in einer Aufrufhierarchie
auftreten, desto mehr Kenntnis hat eine Komponente vom "Innenleben"
der aufgerufenen Komponenten. Je mehr Kenntnis eine Komponente über
die von ihr verwendeten Komponenten hat, desto stärker bindet sie
sich an diese. Wenn sich die genutzten Komponenten ändern, muss sie
sich mit ändern bzw. ist kaputt. Das verletzt das Geheimnisprinzip
und die Kapselung, nach der wir eigentlich in der
Objektorientierung arbeiten wollen. Je mehr solcher Abhängigkeiten
eine Methode hat, desto schwerer ist sie zu verstehen und zu
testen. Code, der sich an das LoD hält, gilt auch als "schüchtern",
weil er "nur mit seinen Freunden spricht". Beispielcode Um an den
Gesamtbeitrag einer Versicherungspolice zu kommen, ist die Kenntnis
über die darin enthaltenen versicherten Personen und deren Tarife
nötig. Da es sich dabei jeweils um Listen handelt, ist sogar noch
ein "Flachklopfen" der Strukturen nötig. Der Code sieht vielleicht
cool aus, ist aber stark an die Strukturen gekoppelt. Das heißt,
ein Test müsste sehr viel Aufwand betreiben, um die nötigen
Strukturen zu schaffen (z.B. mit Mocks). class Tarif def
initialize(name) @name = name end def beitrag 123.45 end end class
VersichertePerson def initialize(name) @name = name @tarife = [
Tarif.new("KFZ"), Tarif.new("Hausrat") ] end def tarife @tarife end
end class Versicherungspolice def initialize @versicherte_personen
= [ VersichertePerson.new("Stefan Macke"),
VersichertePerson.new("Klaus Meyer") ] end def versicherte_personen
@versicherte_personen end end # cool, aber schwer verständlich,
anfällig für Anpassungen und auch schwer zu testen puts
Versicherungspolice.new .versicherte_personen .flat_map { |vp|
vp.tarife } .inject(0){|summe,tarif| summe + tarif.beitrag } Um
dies zu vermeiden, können die einzelnen Klassen von ihren inneren
Strukturen abstrahieren und stellen simple Zugriffsmethoden für die
gewünschten Ergebnisse bereit. Der finale Aufruf sieht nun schon
fast langweilig aus. Dafür liegt die fachliche Berechnungslogik da
wo sie hingehört: in den jeweiligen Klassen und nicht beim
Aufrufer. class Tarif def initialize(name) @name = name end def
beitrag 123.45 end end class VersichertePerson def initialize(name)
@name = name @tarife = [ Tarif.new("KFZ"), Tarif.new("Hausrat") ]
end def beitragssumme @tarife.inject(0){|summe,tarif| summe +
tarif.beitrag } end end class Versicherungspolice def initialize
@versicherte_personen = [ VersichertePerson.new("Stefan Macke"),
VersichertePerson.new("Klaus Meyer") ] end def gesamtbeitrag
@versicherte_personen.inject(0){|summe,vp| summe + vp.beitragssumme
} end end # langweilig, aber einfach zu verstehen und zu testen
puts Versicherungspolice.new.gesamtbeitrag Vorteile Der Code wird
verständlicher, weil nicht mehrere Strukturen bekannt sein müssen.
Fachliche Logik landet evtl. eher da, wo sie hingehört. Anstatt
externen Komponenten Zugriff auf die inneren Daten zu geben, werden
Abstraktionen geschaffen. Die Komponenten sind unabhängiger
voneinander und lassen sich leichter testen. Große Test-Setups mit
vielen Mocks, die weitere Mocks zurückgeben, lassen sich vermeiden.
Interne Änderungen an verwendeten Komponenten wirken sich nicht auf
deinen Code aus. Du hast also weniger Anpassungsaufwand. Nachteile
Wenn du die Regel exakt befolgen möchtest, musst du womöglich recht
viel Boilerplate-Code schreiben, z.B. simple Getter, die an
Instanzvariablen delegieren. Wenn sich die verwendeten Strukturen
selten ändern, ist der zusätzliche Aufwand vermutlich unnötig.
Literaturempfehlungen Zu diesem Wissenshäppchen gibt es ein
separates Kapitel in einem meiner absoluten Lieblingsbücher zur
Softwareentwicklung: The Pragmatic Programmer*. Es ist vor Kurzem
in der 20-Jahre-Edition neu aufgelegt worden, aber das Law of
Demeter ist immer noch Thema. * Links Permalink zu dieser
Podcast-Episode RSS-Feed des Podcasts Gesetz von Demeter –
Wikipedia Law Of Demeter Demeter’s Law: Don’t talk to strangers!
Zusammenfassung Was das Law of Demeter bedeutet Wenn du als
IT-Azubi Methoden schreibst, hilft dir das Law of Demeter, die
Abhängigkeiten zu anderen Objekten überschaubar zu halten. Es heißt
auch Prinzip des geringsten Wissens beziehungsweise Principle of
Least Knowledge. Der Name stammt aus einem Softwareprojekt namens
Demeter, das nach der griechischen Göttin benannt wurde. Die Regel
kommt aus den 1980er-Jahren. Eine Methode sollte nach der
vorgestellten Definition auf Folgendes zugreifen dürfen: Andere
Instanzmethoden ihrer eigenen Klasse. Objekte, die sie als
Parameter erhält. Methoden von Objekten, die sie selbst erzeugt.
Globale Variablen. Den letzten Punkt streiche ich für heutigen Code
aus meiner Empfehlung. Globale Variablen können von überall
verändert werden, wodurch sich bei der Fehlersuche schwer
nachvollziehen lässt, wer ihren Wert geändert hat. Dieselbe
Empfehlung gilt hier für Singletons. Als Merkhilfe kannst du dir
vorstellen, dass eine Methode nur mit ihren "Freunden" spricht: mit
Objekten, die ihr unmittelbar bekannt sind. Was bei verketteten
Aufrufen passiert Bei einem Aufruf wie
person.getAdresse().getStrasse().getErsterBuchstabe() bewegst du
dich durch mehrere Ebenen einer Objektstruktur. Damit du diesen
Code schreiben kannst, musst du wissen, wie die Person ihre Adresse
enthält und wie du darüber zur Straße gelangst. Die Faustregel
"höchstens ein Punkt beim Objektzugriff" macht solche Zugriffe
sichtbar. Je nach Programmiersprache steht dafür ein anderer
Operator, etwa ein Pfeil. Bei Stream-Operationen wie map, filter
oder reduce bleibst du innerhalb einer Stream-Verarbeitung. Für das
Law of Demeter sind insbesondere Ketten relevant, bei denen du
schrittweise innere Bestandteile anderer Objekte hervorholst. Auch
wenn du die Adresse und anschließend die Straße jeweils in einer
eigenen Variablen speicherst, bleibt dein Code an dieselbe innere
Struktur gebunden. Die Abhängigkeit besteht über mehrere Zeilen
hinweg weiter. Warum der innere Aufbau verborgen bleiben sollte
Durch Getter, die innere Objekte herausgeben, kann aufrufender Code
tief in deren Struktur eingreifen. Damit wird die Kapselung
aufgebrochen, die Daten und zugehörige Methoden als Einheit
zusammenhalten soll. Brauchst du den ersten Buchstaben der Straße
einer Person, kann die Person dafür eine passende Methode anbieten.
Sie kümmert sich intern darum, wie sie diesen Wert ermittelt. Für
deinen Aufruf reicht die öffentliche Methode. Führt ein:e
Entwickler:in später eine zusätzliche Ebene ein oder benennt einen
Bestandteil um, müssen alle Aufrufe angepasst werden, die diesen
Aufbau kennen. Das Geheimnisprinzip erlaubt es, den inneren Aufbau
einer Klasse zu ändern, während ihre öffentliche Schnittstelle
bestehen bleibt. Dadurch bleiben aufrufende Komponenten von solchen
internen Änderungen unabhängig. Wie sich das auf Tests auswirkt Um
eine tief verkettete Methode zu testen, musst du die beteiligten
Objekte passend aufbauen oder durch Stubs ersetzen. Im
Personenbeispiel muss die Adresse eine Straße liefern, über die
sich der gewünschte Buchstabe abrufen lässt. Fehlt ein benötigtes
Objekt, kann ein Null-Pointer-Fehler entstehen. Sobald sich die
Struktur ändert, betrifft das auch dieses Test-Setup. Mit einer
direkten Methode für den benötigten Wert werden die Tests kürzer
und hängen weniger stark vom inneren Aufbau ab. Mein Beispiel:
Beiträge einer Versicherungspolice Für mein Beispiel enthält eine
Versicherungspolice mehrere versicherte Personen. Jede Person
besitzt wiederum Tarife, etwa für eine Kfz- oder
Hausratversicherung. ...
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.