A long time ago I started working on a set of related software projects, and I found that alot of repetetive tasks were being coded, for example, parsing a file in java is a 10 line escapade, no matter how you slice it, once you factor in exceptions, streams, etc.
So, being the nice little developer that I am, I decided to genericize such tasks into a single static Utilities class.
Over time the class got big. So I started making some of the "types" of utilities, for example collection handlers, sub static classes in that major Utilities class.
This has been an enormous benefit productivity wise... Anytime I need to do a mundane task like parse a line of text into a bean using reflection, or read through an excel file, or process a mathematical formula, I can access my generic Utilities using my favorite IDE's code completion tool...
hmmmmm - did I ever write a method to convert Floats to Doubles ? Then I just type Utilities.Maths..... and see all the methods that pop up.
One day I wake up and my nifty little Utilities class is +5000 lines of code.
This hasnt caused me any problems, and my boss sais that it needs to be broken up, regardless of how much code that relies on it needs to be gutted.
So who's right ? Are there performance / maintainability issues with a big Utilities class like this ? I find that most of the bugs in my applications happen due to incomplete business logic and poorly modelled data... and very few bugs have really arose out of this enormous class. and that very few bugs come from changes I make to the utilities class. This is because once a method is written to do something simple (for example , converting a float to a double, or inserting line breaks into a paragraph, etc...) it doesnt really get mucked with at all.
So the question is .... When is a big static Utility class "too big" ?
I'm not a big fan of having different objects for supporting variant common tasks. My experience is that, if you go down this road, you wind up "losing" useful classes, not due to bugs, but due to forgetfullness I like my Utilities class !!!
Any feedback would be appreciated, as Im not sure what to do here. Also, Im not sure how to "fix" all the code that will be broken if/when we do break the Utilities class up.
I would say that the moment you decided that there should be a "Utilities.Math" class, that's where you went wrong; you should instead have transitioned to a utilities package containing classes like MathUtils, FileUtils, XmlUtils, etc. I don't think the argument that keeping them as static member classes of Utilities keeps you from forgetting about utilities; it's just as easy to type MathUtils.<Alt-/> as it is to type Utilities.Math.<Alt-/>, if not easier.
Yes they can. Im wondering wether a class can delegate to other classes transparently in java ? That is... can a method call in java be aliased to another class/method?
posted 9 years ago
In response to Ernest : No, its not as easy to type "XMLUtils"... why ? Well, because of the way code completion tools work. You see... There are several thousand different classes titled "XMLUtils" that reside in various libraries and jars which are dependencies to my project. By nesting my own static utilities in my own class, my XMLUtils are directly brought up by my IDE when I type the specific class name of my global utilities class.
I usually categorize them based on the core package of the Java SE API. E.g. a generic (String/Number/primitive) utility class using only java.lang stuff, a DB utility class using only java.sql, another IO utility class using only java.io, again another Servlet utility class using only javax.servlet, etcetera.
No holds barred. And no bars holed. Except this tiny ad: