Last September, I attended JavaZone in Oslo (I blogged about the event at the time). Since then, the organisers have uploaded the presentations and videos of the sessions.
You can find the recordings on-line at http://www.javazone.no/incogito/session. One session that I had not attended was clean code by Robert Martin. (I do regret missing this one as it sounds like it was an excellent session!)
The whole session is a treatise on writing simple, explanatory code and I do recommend that you take a look at it. One slide that caught my eye (slide 39, if you’re interested) talks about the ideal number of arguments for a function.
This got me thinking. When developing a Mule application, services are designed to take advantage of Mule’s reflection-based entry-point resolver. This mechanism relies on the payload type, as well as the method signature. Ultimately, this violates Robert Martin’s first rule – “The ideal number of arguments for a function is zero”.
The thing is, while you can invoke a method which does not take in any arguments, Martin’s rule makes more sense when developing classes used within applications rather than services used within Mule.
Based on this, I decided to come up with my own rules for arguments:
1. The ideal number of arguments for a method in a service is 1.
2. This can be closely followed by multiple arguments. In certain cases, you can transfer maps around and then unpack the map into a set of named arguments.
3. Using zero arguments in a message flow requires very special justification. It can be done, but if you need to invoke a method without passing data to it, you should ask yourself if this really is part of the message flow or not.