Skip to content
Sag Hallo!

Die Kunst der Integration

Wie man externe Bibliotheken sauber in die eigene Architektur einbettet

Sebastian Bergandy

Grüne und schwarze Pflanze auf weißer Wand

Foto von Elena Joland auf Unsplash

Die unsichtbare Verantwortung

Täglich arbeiten wir mit Code von Drittanbietern. Was hat das mit Clean Code zu tun, wenn der Code nicht von uns stammt? Überraschenderweise sehr viel. Es geht nicht darum, wie der externe Code selbst geschrieben ist, sondern wie wir dessen Verwendung nach Clean-Code-Prinzipien gestalten. Selbstverständlich können wir auf Drittanbieter-Bibliotheken nicht verzichten – ohne sie wäre moderne Softwareentwicklung kaum möglich.

Strategien für saubere Integration

Hier sind die wichtigsten Ansätze für den sauberen Umgang mit externem Code:

  • Tests zur Validierung von Annahmen

  • Komplexität kapseln und verstecken

  • Adapter Design Pattern nutzen

  • Klare Boundaries definieren

  • Und weitere Praktiken...

Von der experimentellen Nutzung zu stabilen Tests

Wenn wir eine neue Bibliothek erkunden, schreiben wir oft eine temporäre Main-Methode mit Konsolenausgaben, um das Verhalten zu verstehen. Diese Experimente werden häufig als PoC (Proof of Concept) bezeichnet und später gelöscht.

Doch warum diesen wertvollen Code wegwerfen? Stattdessen könnten wir automatisierte Tests schreiben. Mit einem Test-Runner haben wir eine perfekte Umgebung, um Code auszuführen und unsere Annahmen zu überprüfen. So stellen wir sicher, dass der Drittanbieter-Code wie erwartet funktioniert. Ein weiterer entscheidender Vorteil: Bei Version-Upgrades können wir diese Tests erneut ausführen und prüfen, ob unsere Annahmen weiterhin gültig sind. Selbst einfache Tests mit Konsolenausgaben sind wertvoller als gelöschter Code.

Komplexität hinter fachlichen Abstraktionen verbergen

Ein klassisches Beispiel für das Verstecken von Komplexität ist die Verwendung von HashMap. Diese leistungsfähige Datenstruktur wird oft unterschätzt und in Sprachen wie Go häufig direkt für Geschäftslogik eingesetzt. Man kann die technische API einer HashMap direkt im Code verwenden:

Map<AutoId, TuvReport> tuvReports = new HashMap<>();
var report = tuvReports.get(id);

Oder man kann sie hinter einer fachlich benannten Klasse verbergen:

class TuvReports {
   public void addReport(autoId, report);
   public boolean hasValidReport(autoId);
   // ...
}

Mit diesem Ansatz gewinnt man eine saubere, domänenspezifische Schnittstelle. Wir folgen dem Single Responsibility Principle und erleichtern das Schreiben von Tests.

Das Adapter-Pattern als Brücke

Wenn die Schnittstelle einer Drittanbieter-Bibliothek für uns unpassend oder zu komplex erscheint, können wir einen Adapter implementieren. Wie bereits in früheren Artikeln erwähnt, ist API-Design ein entscheidendes Thema. Mit dem Adapter-Pattern können wir die Schnittstelle selbst so gestalten, dass sie fachlich zum Rest unseres Codes passt. Das verbessert sowohl die Lesbarkeit als auch das Verständnis.

Klare Grenzen definieren

Setzen Sie immer deutliche Boundaries, wenn Sie mit externem Code arbeiten. Nehmen Sie sich die Zeit zu überlegen: Wann, wie und wo möchte ich diesen Code einsetzen, damit mein eigener Code weiterhin die Kern-Domäne klar abbildet? Kapseln und verstecken Sie die konkreten Technologien. Validieren Sie Ihre Annahmen und Erwartungen durch gezielte Tests.

Diese bewusste Gestaltung der Schnittstellen zu externem Code ist ein wesentlicher, oft übersehener Aspekt von Clean Code, der langfristig zu deutlich wartbareren Systemen führt.

Author

Sebastian Bergandy
Sebastian Bergandy