Einmal im halben Jahr komme ich an Dan Mangles' Blogeintrag über Missverständniss des Gesetz von Demeter vorbei. Und meistens - das scheint eine Eigenart von mir zu sein - lese ich ihn nochmal. So auch vor ein paar Tagen. Und auch dieses Mal habe ich das Gefühl ihn bisher noch nicht richtig gelesen zu haben.

Der Inhalt ist eine nette kleine Geschichte - weniger: ein Geschichtsfragment -, das von einem Kunden, einem Zeitungsjungen und einer Brieftasche handelt. Zunächst wird die Geschichte in Form der naivsten Implementierung (die Geschichte ist eigentlich nur Ruby-Code) erzählt. Der Zeitungsjunge bekommt die Brieftasche des Kunden und nimmt sich selbst das Geld für die Zeitung. Da niemand freiwillig dem Zeitungsjungen seine Brieftasche gibt, wird das Gesetz von Demeter ('Sprich nicht mit Fremden') (oder technisch: 'keine Aufrufe mit mehr als einem Punkt') eingeführt und die Geschichte wird noch einmal erzählt, jetzt wird die Brieftasche aber nicht aus der Hand gegeben.

Dan Mangles untersucht die Richtung der Delegation der Aufrufe - und das ist mir erst dieses Mal so richtig aufgefallen. Bei der Datendelegation ist die Richtung genau umgekehrt zur Verhaltensdelegation. Datendelegation: Der Zeitungsjunge bekommt den Kunden und nimmt sich vom Kunden die Brieftasche. Der Zeitungsjunge hat also die Brieftasche in der Hand. Bei der Verhaltensdelegations sagt der Zeitungsjunge dem Kunden 'bezahl' und der Kunde sagt der Brieftasche 'Geld her'. Es ist nicht das Datum (Brieftasche) was nach außen, sondern das Verhalten ('Bezahl') was als Aufforderung nach innen wandert.

Diese Unterscheidung ist so interessant, weil sie davor schützt LOD-Verletzungen einfach durch Datendelegation zu lösen. Wenn der Kunde auf einmal eine Geldmenge hätte, er also seine Innereien ausstellen würde, wäre dem Gesetz der 'Zwei-Punkte-Vermeidung' genüge getan, aber substantiell hätte sich nichts geändert. Also: Richtungsumkehr und Verhaltensdelegation.

Dan Mangles kluge Gedanken gehen noch weiter. Er bringt ein Beispiel aus einem View. Dort wird eine Bestellung dargestellt. Diese Bestellung hat einen Kunden, der Kunde hat einen Namen. Das bedeutet wir haben im View eine Stelle mit zwei Punkten: bestellung.kunde.name. Die Verletzung lässt sich in der bekannten Art auflösen. Die Bestellung bekommt neben dem Kunden eine Methode kunde_name. Das ist fachlich unsinnig, eine Bestellung sollte keinen Kundennamen haben. Dan Mangles fragt sich, was das für das Gesetz von Demeter bedeutet. Er kommt zu dem Schluss, das ein View kein Geschäftsobjekt sei und deshalb sei für die Darstellung eine Verletzung des Gesetzes von Demeter erlaubt, besser: er sagt das Gesetz von Demeter beziehe sich eigentlich nur auf das Verhältnis von Geschäftsobjekten.

Und das habe ich erst beim zweiten oder dritten Besuch verstanden. Was wohl beim nächsten Besuch auf mich wartet?