# Abgrenzung In unserem Code setzten wir oft auf die Implementation von anderen. Sei es eine Datenstruktur der Core Library oder eine API eines Drittanbieters, wir schreiben selten all unseren Code selbst. Setzt man aber auf die Implementation von jemand anderem, lebt man immer mit einer Gefahr: die Implementation kann sich ändern. In allen Fällen ist es also wichtig die Abhängigkeiten möglichst gering zu halten. Wie können wir diese Unabhängigkeit jedoch erreichen, ohne den Aufwand aus dem Rahmen zu sprengen? ## Wrapper Klassen Eine gute Möglichkeit, vor Allem bei der Implementation von simplen Datenstrukturen, sind Wrapper Klassen und/oder Methoden. Das Ziel ist, die Aufrufe der externen API möglichst einzukapseln und mit selbstgeschriebenen "Verpackungen einzupacken". Angenommen wir haben eine Klasse die Noten in einer Map speichern muss. ```Java Map grades = new HashMap(); ``` und wir wollen diese Noten anhand von einer ID aufrufen können: ```Java Grade grade = (Grade)grades.get(gradeId); ``` Bei jeder Interaktion mit der Map müssten wir also zuerst den Return Value von *Object* zu *Grade* Parsen. Wenn sich die Implementation von Map ändern würde (wie tatsächlich in der Java Version 5 geschehen ist) müssten wir alle Aufrufe anpassen. Das ist weder sauber noch schlau. Eine saubere abgekapselte Implementation könnte stattdessen folgendermassen aussehen: ```Java public class Grades { private Map grades = new HashMap(); public Grade getById(String id) { return (Grade)grades.getById(id); } } ``` und endsprechend ```Java Grades grades = new Grades(); Grade grade = grades.getById(gradeId); ``` Wenn sich jetzt die Implementation ändert oder wir uns beispielsweise entscheiden, auf eine generische Variante zu wechseln müssten wir nur die *Grades* Klasse anpassen und der Rest wäre noch in Takt. Die Abhängigkeit wurde so von der ganzen Code Base auf nur diese eine Klasse reduziert. Dies ist ausserdem auch sauberer in Bezug auf das *Single Responsibility Prinzip*. ## Lern Tests Ein weiteres Konzept, welches ich bei der Implementation von Drittanbieter Code empfehle, ist, diesen Code ausführlich zu testen. Es scheint wahrscheinlich anfangs fragwürdig, fremden Code für das eigene Projekt zu testen. Dies kommt jedoch mit zwei sehr hilfreichen Vorteilen: Durch die Tests lernen wir wie der Code wirklich funktioniert und welche Reaktionen wir erwarten können und wir wissen genau was nicht mehr funktioniert, wenn die Implementation sich geändert hat. Bevor wir also wild drauflos anfangen die neue API in unser System einzubauen macht es Sinn, zuerst ausführlich alle Teile, die wir verwenden wollen zu testen (wie bei TDD). Wenn wir diese Testsuite einmal geschrieben haben, können wir einfach bei jeder Änderung der API die Tests ausführen, um sicher zu stellen, dass alles noch funktioniert. Wenn ein Test *failed*, wissen wir direkt, was nicht mehr funktioniert.