Monday, April 28, 2014

How to get rid of helper and utils classes

There you go once again, while performing a code review or after having justified a quick coding in the name of urgency and priority: it clearly stand in front of you yet another helper class. But everything works fine and the show must go on, release after release, so that helper class soon becomes a monster class, providing tons of static methods, freely growing in its utils package, often a no man land of technical debts where the object oriented design didn’t dare to step in. The provided facility is centralized and hence DRY – would shout some developer, may be its coder. It’s fast because everything is static – may claim somebody else within the team, may be the one who added another static method in its list. It’s easy to use, we kept it simple – you could hear in the room, yet another misunderstanding of KISS.

We could argue that often helper and utils classes come to hand really easily, especially when we can’t modify the right target class of the new functionality (located in an external library, for instance) or we actually can’t find that target (unclear domain model, PoC, lack of requirements), or we simply don’t want to find it (laziness, the main global source of helper classes). The big problem though is that’s clearly not an object oriented solution and by the time (and by lack of team communication, resources rotation, quick fixes and workarounds) it could lead to endless containers of static methods and maintenance headaches (you wanted to be DRY, but you end up having ten methods providing almost the same functionality, if not the same; you wanted to be fast, but now you can’t easily add a cache mechanism in that static monster or you get in troubles with concurrency; you wanted to keep things simple, but your IDE now provides a long list of heterogeneous methods which doesn’t simplify your task). But don’t worry, we’ll try to solve it.

Read more here

Leave a Reply

All Tech News IN © 2011 & Main Blogger .