Notice how the return type of the show() method is an object of the same class and that the method now returns the "this" object, whereas before the return type was void and it returned nothing.

That's all there is to it!

Taking it even further you could end up writing code like below if you change the setTitle and println method to also return "this".

OutputWindow out = new OutputWindow().setTitle("Test").show().println("Line 1");

To lots of you this is probably a no-brainer, but then maybe there are other long-term Notes developers like myself who are only now venturing in to the real world of programming and still discovering little tricks like this.

Comments

Tim Tripcony used to be a big fan of chaining as well. But it's bad practice when you start testing complex code because it hides the point of failure in execution. If we take your last example, and that line resulted in a NullPointerException, how would you know whether it was the constructor, .setTitle(), or .show() that failed to return the correct object?

Restricting individual lines to single operation may bulk your code up a bit, but it makes it MUCH easier for a maintenance developer to come behind and diagnose a runtime error.

Doh, he outed me. Which amuses me, because I was about to leave essentially the same comment. If you're able to properly catch and handle all errors within each method, chaining is fine, but in general it does make debugging far more difficult. So, yes, when there's not much complexity enclosed, I suppose it's "safe", but what happens when the process evolves and suddenly one of those methods must become more complex? Do you then rewrite everything that calls it to remove the chaining and add null checks? We've found it saves more time in the long run to structure our code that way to begin with than we were previously saving by chaining methods, but, as Stephan would say, YMMV.

Chaining is a useful technique, but yes there are pitfalls. If you have a predictable chain / codebase, then it's a nice way of shortening things. If you're dealing with something like the godforsaken Domino Java API though, you're best off following Tim's advice, and keeping things in "long hand", if only to handle the proliferation of lame NotesExceptions and, even worse, the NPEs.

In the case of Notes I put all the functions/objects/methods in a library. Then I write an agent that uses every function/object/method in the library using parameters that test the boundary conditions of each method.

The returned values are tested for correctness. If side effects such as creating or changing a document, I write the code to check the correctness of these also.

One school of development writes the unit tests first, then writes the actual code.

Every time I change the library I run the unit test to see if it still works. If I add new methods then I add new unit tests.

In production if (when) a bug shows up that I trace back to the library and the bug isn't found by the unit test, I modify the unit test to reveal the bug. Next I fix the library and rerun the unit test to make sure the bug is fixed.

Writing the main code is a lot easier when you have well tested libraries to call.

Actually, at risk of sounding like a Luddite, not only does the debugging issue make sense, there is also readability.

We are all tempted to make use of 'clever' aspects of any particular language, or oop, but the issue comes when you have to take over someone else's code (or even your own, 6 months later!) - readability wins every time.