Java-Code visualisieren: Stadtneurotiker

Data Class

Am anderen Ende des Spektrums finden sich oftmals Klassen, die „dumme“ Datenhalter sind. Sie besitzen allenfalls nur ein einfaches Verhalten, also eine (sehr) niedrige funktionale Komplexität. Ihre Daten werden vornehmlich von den Methoden anderer Klassen be- und verarbeitet. Das zu den Daten gehörende Verhalten findet sich somit zerstreut in anderen Klassen wieder. In der Literatur wird eine solche Entwurfsdisharmonie als Data Class bezeichnet.

„Datensäcke“ werfen einen Pfeiler der Objektorientierung um: die Kapselung. Durch das Offenlegen ihres internen und eigentlich geheimen Zustands sowie ihren Einladungen zur direkten, ungefilterten Manipulation dieses, untergraben Data Classes konsequent Vorteile der Objektorientierung wie Wartbarkeit, Verständlichkeit oder auch Testbarkeit. Sie verletzen fundamental das „Tell, Don’t Ask“-Prinzip, dessen korrekte Befolgung die Objektorientierung gut werden lässt.

Brain Class und Brain Method

Ein enges Verwandtschaftsverhältnis mit der God Class zeigt die Brain Class. So bezeichnen wir vereinfacht gesagt eine Klasse des untersuchten Systems, die im Unterschied zu einer God Class (1) entweder weniger Zugriffe auf die Attribute fremder Klassen oder eine geringfügig höhere Kohäsion besitzt und (2) eine oder mehrere Brain Methods enthält. Eine Methode wird als Brain Method bezeichnet, wenn sie:

  • sehr umfangreich ist (LOC ist sehr hoch)
  • eine sehr hohe Komplexität aufweist
  • tiefe Verschachtelungen besitzt
  • viele Variablen benutzt (Parameter, lokale Variablen, Felder und Konstanten)

Ein Brain Method zentralisiert die Funktionalität ähnlich wie eine God Class, allerdings auf der Ebene einer Klasse statt eines ganzen Subsystems [1].

Da sich die durch eine Brain Class entstandenen Probleme nur geringfügig von denen durch eine God Class verursachten unterscheiden, sind die Auswirkungen vergleichbar. Hinzu kommt die noch deutlich höhere Komplexität der Brain Methods, die die Verständlichkeit und Wartbarkeit des Codes erheblich erschwert. Eine Wiederverwendung ist ohne aufwendige Refaktorisierung nahezu unmöglich.

Die genannten Entwurfsdisharmonien können mithilfe von CodeCity grafisch hervorgehoben werden. Dies ist in Abbildung 2 wie folgt dargestellt: die God Class in Rot, die Data Class in Violett. Die Brain-Class-Disharmonie würde in Gelb dargestellt, tritt aber in der Abbildung nicht auf, aber die in oranger Farbe in der Abbildung dargestellte Disharmonie zeigt das gleichzeitige Auftreten der God- und Brain-Class-Disharmonie.

Abb. 2: Code City mit Klassendisharmonien
Feature Envy

Auf Methodenebene kann ein weiterer Entwurfsgeruch identifiziert werden, der Feature Envy genannt wird. „Neidische“ Methoden greifen auf viele Daten weniger anderer Klassen zu. Diese Disharmonie lässt sich häufig in der Beziehung zwischen God und Data Class finden. Der feine Unterschied zu den Methoden einer God Class ist, dass die Feature-Envy-Methoden nur die Daten weniger fremder Klassen benutzen. Dies ist wichtig, da sich hieraus im Verlauf des Artikels eine passende Lösungsstrategie ableiten lässt.

Problematisch hierbei ist, dass Methoden und Attribute, die eigentlich zusammengehören, durch Entwurfsfehler voneinander getrennt sind. Somit wirken sich Änderungen an den Daten auf die Methode aus. In Abbildung 3 sind im linken Teilbild Feature-Envy-Methoden violett dargestellt.

Abb. 3: Code City mit Methodendisharmonien (links) und ihre zugehörige Klasse (rechts), jeweils gelb umrandet
Shotgun Surgery

Die Disharmonie Shotgun Surgery liegt vor, wenn eine Methode von zu vielen Methoden zahlreicher anderer Klassen verwendet wird. Die Operation hat somit zu viele eingehende Abhängigkeiten; die anderen Klassen sind zu stark an die Klasse mit dem entsprechenden Verhalten gekoppelt.

Die Folgen sind klar: Eine Änderung an der einen Methode wirkt sich auf alle von ihr abhängigen Klassen aus. Nicht nur etliche Anpassungen sind in diesen anderen Klassen notwendig, es kann auch schnell passieren, dass erforderliche Änderungen in abhängigen Methoden vergessen werden. Das Resultat ist erneut eine deutliche Verschlechterung der Wartbarkeit des Softwaresystems. Shotgun-Surgery-Methoden sind links in Abbildung 3 rot hervorgehoben.

Allein die Menge macht das Gift

Die von uns beschriebenen Charakteristika der verschiedenen Entwurfsdisharmonien basieren immer auf Metriken, deren Werte gleichzeitig jeweils einen bestimmten Schwellwert über- oder unterschreiten. Die bei der zurückliegenden Beschreibung der sechs Disharmonien verwendeten Mengenangaben (viele, hohe, niedrige usw.) werden im praktischen Einsatz natürlich durch entsprechende Zahlenwerte ersetzt. Diese finden sich in der Literatur und beruhen auf der Auswertung einer Stichprobe von Softwaresystemen unterschiedlicher Anwendungsdomänen.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.