Freitag, 27. Mai 2011

Shy coding

Schüchterner Quellcode minimiert die Abhängigkeiten zwischen Objekten. Die Reduzierung der Abhängigkeiten führt zu loser Kopplung, die wiederum isolierte testbare Softwarebausteine hervorbringt. Testbare Softwarebausteine mit ihren spezifischen Eigenschaften (gekapselt, kohäsiv, Mock freundlich, etc.), fördern die Evolvierbarkeit einer Software-Applikation.

Das „Law of Demeter (LoD)" definiert Regeln für schüchternen Quellcode. Das klassische Law of Demeter basiert auf einer Veröffentlichung von Karl Lieberherr und Ian Holland. Das Law of Demeter wird  mit dem "Principle of Least Knowledge" gleichgesetzt. Dieses Prinzip sagt aus, dass Objekte nur mit eng befreundeten Objekten sprechen sollen. Die Interaktionen zwischen Objekten sollen durch Einhaltung des Prinzips reduziert werden, sodass lose gekoppelte Software-Architekturen entstehen. Wird das Prinzip häufig verletzt, entstehen zerbrechliche Systeme, die schwer zu warten und zu verstehen sind.

Anfällig für die Verletzung des Prinzips sind Facaden, die eine einfachere Sicht auf ein komplexes Teilsystem bieten und Aggregatsobjekte (Kompositionen, Kontextobjekte, etc.), die eine Menge an Funktionalitäten bündeln. Vorsicht ist auch bei Mediatoren geboten, die komplexere Interaktionen zwischen Objekten vereinfachen sollen.

Entwicklungsumgebungen wie Eclipse unterstützen die Suche von Objekten durch ausgefeilte Kontextfunktionen. Dennoch ist es ratsam Interaktionen zwischen Objekten zu minimieren, sodass eine Suche nach Objekten nicht nötig ist. Die transitive Navigation führt dabei besonders zu unübersichtlichen Objektvernetzungen, die nur schwer aufgelöst werden können.

Beispiel für eine transitive Navigation:

long count = order.getProduct().getItems().countItems();

Besser ist:

long count = order.countItems();

Beispiel für einen Verstoß gegen das Law of Demeter:

Constructor(final Context context) {


     this.view = context.getFrame().getView();
}

Korrekt ist:

Constructor(final View view) {


     this.view = view;
}

Merkregeln, rufe nur Methoden auf von...
  1. dir selbst (normalerweise private Methoden),
  2. Objektreferenzen, die als Methodenargument übergeben wurden,
  3. jedem selbst erzeugten Objekt (in Methoden der Klasse erzeugten Objekten),
  4. in Assoziation stehenden Klassen (Attribute der Klasse)