Zu Beginn eine Warnung: der folgende Artikel ist ein wenig länger und eher abstrakt. Im wesentlichen geht es darum, dass die Verwendung von Java Interfaces in unseren XPages Projekten zu besserem, weil wartbaren, Code führt. Mit Hilfe des OpenNTF Projektes org.openntf.junit.xsp können Entwickler Java Interfaces benutzen, um besseren Test Code für Ihre XPages Projekte zu schreiben.
Zunächst muss ich gestehen, dass ich am Anfang meiner Java Entwicklung kein Freund von Java Interfaces war. Bisweilen konnte ich die Nützlichkeit erkennen, aber meistens machten Sie mir das Leben schwer, wenn ich den Code von jemand anders verstehen wollte. Meine normale Herangehensweise besteht darin, den Einstiegspunkt in den Teil zu suchen, der mich interessiert. Von dort aus schaue ich mir die Parameter, die übergeben werden, und die Rückgabewerte an. Die Verwendung von Interfaces verbirgt in dem Fall die Implementierung. Aber für das Verständnis ist das der relevante Teil. Die Suche nach der eigentlichen Implementierung macht es nur aufwendiger.
Seit ich mit XPages arbeite haben sich meine Präferenzen in diesem Bereich komplett umgedreht. Wie die meisten Notes Entwickler waren meine ersten Programmieraufgaben in Java eher klein. Wenn man einen Notes Agenten schreibt, um einen Web Service aufzurufen oder im ein PDF Dokument zu erzeugen, benötigt man nicht unbedingt eine wohl designte Klassenhierarchie.
Mit einem eigenem Java basierten XPages Framework stellen wir uns anderen Herausforderungen und suchen nach neuen Methoden, um mit der größer werdenden Komplexität umzugehen. Ein Aspekt bei dem uns Java Interfaces helfen, ist das Open/Close Prinzip. Vereinfacht ausgedruckt besagt das Open/Close Prinzip das Code offen für Erweiterungen und geschlossen für Anpassungen sein soll. Wobei mit Anpassungen die Art gemeint ist, die zu Änderungen bei den aufrufenden Methoden führt. Diese sind meistens aufwendig und fehleranfällig. Wenn die interne Struktur einer Klasse angepasst wird, damit der Algorithmus schneller läuft, ist nichts dagegen einzuwenden. Aber wenn sich die API ändert und an diversen Stelle die Aufrufe angepasst werden müssen, kann dieses schnell unangenehm werden.
Die Verwendung von Interfaces als Parameter und Rückgabewerte ist wie ein Vertrag. Die aufrufende Methode kann sich darauf verlassen, dass egal welche konkrete Klasse als Parameter übergeben bzw. zurückgegeben wird, keine Anpassungen notwendig sind. Die einzige Bedingung ist, dass das Interface implementiert wird. Wenn also eine neue Klasse wesentlich schneller als die bisherige Klasse ist, kann diese verwendet werden, ohne das in den Aufrufen etwas angepasst werden muss. Es muss lediglich sichergestellt werden, dass die neue Klasse das gleiche Interface unterstützt.. Sie haben eine coole neue OpenSource Bibliothek gefunden. Falls diese das gewünschte Interface nicht unterstützt, können Sie einfach einen Wrapper schreiben.
Zu Glauben, dass nach einem Austausch der Implementierung bestehender Code immer noch funktioniert, ist die eine Sache. Es definitiv zu wissen, ist eine andere. Das ist der Moment, wo Test Driven Development und JUnit Testing ins Spiel kommen. Die Idee, absolut sicher zu sein, dass nach einer grundlegenden Änderung trotzdem alles wie gehabt funktioniert, ist faszinierend.
Meine ersten Versuche mit JUnit waren ein wenig frustrierend. Im Domino Designer kann ein JUnit Test auf den Java Code in einem XPages Projekt nicht direkt zugreifen, weil die NSF aus Sicht von Eclipse ein virtuelles Dateisystem darstellt. Als Lösung blieb mir nur, den Java Code zu exportieren und dann in einem separaten Eclipse-Instanz meinen JUnit-Test laufen zu lassen. Um so mehr war ich erfreut, als ich von dem OpenNTF Projekt org.openntf.junit.xsp erfahren haben. Mit Hilfe dieses Plugins kann der JUnit-Test direkt aus einer XPage heraus gestartet werden.
Eine der Herausforderungen beim Schreiben von Test Code für eine spezielle Laufzeitumgebung, wie z.B. XPages, ist die Notwendigkeit Objekte aus dieser Umgebung zum Testen zu haben. Statt realen Objekten können auch so genannte Mock-Objekte eingesetzt werden. Auch hierbei kommen Java Interfaces ins Spiel. Statt ein existierendes Notes Dokument an den Test Code zu übergeben, kann ein Mock-Objekt übergeben werden. Die Klasse lotus.domino.Document ist nämlich nichts anders als ein Java Interface. Das bedeutet die Abhängigkeit für jetzt und alle Zeit eine Notes Session, eine Notes Datenbank und ein Notes Dokument vorzuhalten, das genau den Testanforderungen entspricht, entfällt.
Christian Güdemann hat für diesen Zweck EasyMock in org.openntf.junit.xsp integriert. Details dazu finden sich in seinem Blog "org.openntf.junit.xsp ? now with EasyMock support".
Java Interface helfen besseren Java Code zu schreiben, Insbesondere in größeren Java Projekten in XPages Projekten können sie gerade im Zusammenhang mit JUnit Tests segensreich sein,
Happy coding!
