A word of warning: the following article is quite lenghty and abstract. It basically says that using Java Interface in your XPages projects leads to better (that means more maintanable) code and that with the help of the OpenNTF project org.openntf.junit.xsp a developer can utilize Java Interfaces to write better test code for their XPages projects.
I have to confess that when I started with Java Development some time ago I didn't like Java Interfaces. While in some cases I could see that they are useful most of the time they gave me a hard time trying to understand the code of someone else. My usual approach for reading someone else code is to figure out how to invoke the part I'm interested in and then take a close look at the parameters that are passed to the method and the return value. Interfaces due to their nature shield the implementation.. But that the part I was interested in. Searching for the current implementation made it more complicated.
Since working with XPages my preferences had completely changed. Like most of the Notes developer which start with Java my code used to be small. If you write some Notes Agent to invoke a Web Service or generate a PDF document there is normally not much need for an elaborated design of your class hierarchy.
But nowadays as we developed our own XPages framework totally Java based the rules and approaches must cope with the arising complexity. One aspect were Java Interfaces helps us is the Open/closed principle. Simply speaking the Open/close principal state that code should be open for extension but closed for modification. With modification are those meant that leads to changes in calling methods and therefore are costly and error-prone. If you find a better way to implement an algorithm inside your class no one will complain. But if there is change in your API resulting into the necessity to change code in a lot of calling methods things might get messy.
By using Interfaces as parameters and return values it is like having a contract. The caller of your method can rely on whatever will be passed to the method and returned from it will work as long as it implements the Interface. If you write a new class which is way faster than your old code you can use it instead without worrying that you break something. This is true as long as the new code implements the same Interface. If you find a cool new OpenSource library which you would like to use instead and it does not implement the Interface, you can simply write a wrapper for it.
To believe nothing breaks by your change is one thing. To know it, is another thing. This is were Test Driven Development and JUnit Testing comes in. The idea to walk away from any change you made and to be absolute confident that everything works is amazing.
My first steps using JUnit were a little bit frustrating because there is no way to run JUnit test in Domino Designer directly for your XPages Java code due to the virtual file system a NSF is from Eclipse point of view. So I had to export my Java code and then run JUnit tests in a stand alone Eclipse.
I really was delighted when I read about the OpenNTF project org.openntf.junit.xsp. This project allows to execute the JUnit Tests from within an XPage.
One of the challenges with writing test code is that with systems running in a special environment like XPages you have to find a way to have living objects from this environment. A way around this issue is to use a mock object. And again with Java Interfaces this is easy. Instead of basing an existing Notes document to your test code you could pass a mock up object since lotus.domino.Document is a Java Interface. So there is no need to have a Notes Session, a Notes Database and a existing Notes Document that meets your test requirements for now and all the future to pass your JUnit test.
Christian Güdemann did a great job integrating EasyMock into org.openntf.junit.xsp. Read more in his blog post "org.openntf.junit.xsp ? now with EasyMock support".
Have a closer look into using Java Interfaces today. They really help you.
Happy coding!
