After you zoquo, do you ushnu?
One of the most crippling forms of design paralysis I’ve witnessed is something I call library fever: when a team cannot write a single null check or status verification without a static method tucked away in some *Util class. Similar to architecture astronauts, these guys and gals weave intricate designs for core libraries that promise to eliminate all ad-hoc conditionals. What these people fail to produce is working software. In this post, The Rontologist reminds all you coding hitch hikers around the galaxy to always remember your towel. Sound advice, but let’s remember what those towels are for…
The best custom libraries don’t come from deciding up front that you want to check the status of a variable, they come from discovering repeated patterns in your codebase where the expressivity of recasting those patterns as well-named methods outweighs the dependency that is introduced. In doing so, you must consider the semantics, not just the mechanics. For example, Ron suggests replacing this code[1]:
1 2 3 | if (request.getParameter(“name”) != null && request.getParameter(“name”).length > 0) { // code } |
With this code:
1 2 3 | if (!WebUtil.isEmpty(request.getParameter(“name”)) { // code } |
This is a perfectly sound mechanical implementation refactoring with which most developers would have no qualms. Yet if we delve deeper beyond the logic into the intention we can make it clearer (and after a few methods, it will border on humane, but won’t get insane.) If the purpose is checking for a parameter in the request, why not call a spade a spade?
1 2 3 | if (WebUtil.containsParameter(request, "name")) { // code } |
In addition to making the intent clear, this replaces a negated conditional with a bare one that is more readily read. Suppose we wanted to look for an attribute instead. Any isEmpty() method seems silly now — what would we pass it, an Object? So now the code would be:
1 2 3 | if (null != request.getAttribute("name")) { // code } |
And now two actions with similar intention have different local idioms. Following the previous pattern, we simply add a method:
1 2 3 | if (WebUtil.containsAttribute(request, "name")) { // code } |
Same signature, similar method name, cleaner code. The coup de grace (and the humanity) comes when you want to check for the presence of a string in the request and you don’t care where it comes from: perhaps the information may be parameter for a direct request but in an attribute for a forward. Rather than this:
1 2 3 | if (!WebUtil.isEmpty(request.getParameter("name")) && null != request.getAttribute("name")) { // code } |
We have this:
1 2 3 | if (WebUtil.contains(request, "name")) { // code } |
If you thought it were appropriate, you could even wrap the request into a custom version and simplify the code to request.contains(“name”). The intention doesn’t get much clearer than that.
The point is not that the DRY principle is wrong, but that you can’t know for sure the best single, unambiguous, authouritative representation for any single datum within a larger system until you have working code that you can refactor. Call it tracer bullets, iterative development, or agile, it all boils down to the same basic principles: make your code right, make your code clean, make your code fast. Necessarily in that order.
There’s no point in getting DRY if you didn’t get wet…
[1] I’m not having a go at the Rontologist because I know he’s just making up code for an example (although it does look suspiciously like code I would’ve written not too long ago!), but I do want to point out the dangers of micro-refactoring.
