Hilfe, mein Code ist abhängig!

Wir stellen immer wieder fest, dass kleine Objekte besser sind als große Objekte, dass kurze Codeblöcke besser sind als lange. Kleine Objekte und kurze Codeblöcke sind auch besser wiederverwendbar. Wir wissen, dass ein einzelnes Objekt möglichst genau eine Aufgabe haben soll beziehungsweise es nur einen Grund geben soll, dieses Objekt zu ändern.

Die Kehrseite der Medaille ist allerdings, dass ein kleines Objekt alleine nicht so wahnsinnig viel erreichen kann. Wir können und das vorstellen wie einen Bautrupp, der ein Hochhaus bauen soll. Jeder einzelne Bauarbeiter ist wichtig, aber ein Bauarbeiter alleine könnte unmöglich das ganze Hochhaus bauen. Dafür gibt es einfach zu viele Dinge, die erledigt werden müssen, ganz abgesehen davon, dass viele Tätigkeiten einfach zwei oder mehr Menschen benötigen.

Wie würde man beispielsweise gleichzeitig aus dem Führerhaus eines Krans den Überblick bei der Bedienung behalten und auf dem Boden sicherstellen, dass die Last aufgenommen oder abgestellt wird?

In der Webentwicklung entsprocht das Hochhaus einer HTML-Seite, die im Browser dargestellt wird. Wie diese entsteht und wer hinter den Kulissen daran beteiligt war, wird für den Benutzer nicht sichtbar, und wenn wir ehrlich sind, interessiert es diesen auch nicht.

Sobald wir es geschafft haben, kleine und wiederverwendbare Objekte zu erstellen, die genau eine (überschaubar große) Aufgabe gut erledigen können, ergibt sich ein neues Problem: Wir müssen es schaffen, mehrere, genau genommen sogar ziemlich viele dieser kleinen Objekte zusammenarbeiten zu lassen.

@@@KEY-MESSAGE@@@ Objektorientierung ist Kollaboration. Das gilt sowohl für Objekte als auch für Menschen.

Das wiederum bedeutet: Objekte bekommen Abhängigkeiten, vermutlich sogar mehrere. So richtig viele werden es erfahrungsgemäß nicht, weil ja jedes einzelne Objekt nicht allzu viel tut. An dieser Stelle kann es sich übrigens lohnen, sich mit dem Integration Operation Segregation-Prinzip zu beschäftigen.

Wir sollten allerdings nicht die erste Regel von Abhängigkeiten vergessen:

@@@KEY-MESSAGE@@@ Regel 1: Vermeide Abhängigkeiten, wo es geht.

Ein Objekt soll nur die Abhängigkeiten haben, die es auch wirklich braucht. Künstliche Komplexität in Form von zu vielen Abhängigkeiten ist eine Wurzel von sehr viel Übel. Gemeint sind hier technische Abhängigkeiten, beispielsweise die Abhängigkeit eines Geschäftsobjekts von einer Datenbank, einem Service Container oder einer Fabrik.

Fachliche Abhängigkeiten dagegen sollen und müssen sein. Dennoch gilt auch hier, dass Abhängigkeiten begründet und notwendig sein müssen. Es ist beispielsweise offensichtlich, dass eine Rechnung die Anschrift eines Kunden als Abhängigkeit hat:

ex

Ohne Anschrift können wir keine rechtsgültige Rechnung ausstellen. Diese Abhängigkeit ist also fachlich notwendig und damit unvermeidbar.

Möglicherweise basiert eine Rechnung auf einem Auftrag und listet im Wesentlichen die dort bestellten Posten auf:

ex

Auch das ist eine fachlich begründete Abhängigkeit, aber nicht für jede Rechnung, die wir ausstellen. Eine Storno-Rechnung beispielsweise basiert auf der Rechnung, die sie storniert, unabhängig davon, warum und wie die ursprüngliche Rechnung entstanden ist:

ex

DEs gibt allerdings noch weitere Regeln:

@@@KEY-MESSAGE@@@ Regel 2: Wenn Du Abhängigkeiten nicht vermeiden kannst, dann mache sie explizit.

Schauen wir uns dazu Beispiele für implizite Abhängigkeiten an:

Eine implizite Abhängigkeit zeigt sich nicht in der Schnittstelle eines Objekts:

ex

Das bedeutet, dass wir bei der Wiederverwendung dieser Klasse auf Probleme stossen werden:

Wiederverwendung bedeutet, etwas in einem anderen Kontext zu verwenden. Wir nehmen also ein Objekt

siehe artikel implizite vs. explizite abhängigkeiten

Es gibt insgesamt vier Ebenen von Kopplung:

Vererbung

Subklasse. Stärkste Kopplung, die es gibt. Ohne Elternklasse kann sie Subklasse nicht überleben. Es gibt einen Kontrakt zwischen Subklasse und Elternklasse.

Komposition

Ein Objekt hat ein anderes als Property. Das koppelt die Lebensdauer der beiden Objekte. Wenn der Träger Garbage collected wird, wird auch die Abhängigkeit entfernt, außer sie lebt länger, weil noch jemand Referenzen darauf hat.

Nachrichten

Ein Objekt schickt einem anderen Objekt Nachrichten. Es wird als Parameter für einen Methodenaufruf übergeben.

Schauen wir uns bei