This week's book giveaway is in the Cloud/Virtualization forum.
We're giving away four copies of Learning OpenStack Networking: Build a solid foundation in virtual networking technologies for OpenStack-based clouds and have James Denton on-line!
See this thread for details.
Win a copy of Learning OpenStack Networking: Build a solid foundation in virtual networking technologies for OpenStack-based clouds this week in the Cloud/Virtualization forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Knute Snortum
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Ganesh Patekar
  • Stephan van Hulst
  • Pete Letkeman
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Ron McLeod
  • Vijitha Kumara

How much is too much ?  RSS feed

 
Ranch Hand
Posts: 407
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi guys :

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.






 
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

jay vas wrote:...
So the question is .... When is a big static Utility class "too big" ?
...



When your boss says so, and you can't convince him or her otherwise.
 
author and iconoclast
Sheriff
Posts: 24220
40
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
author & internet detective
Sheriff
Posts: 38564
654
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

jay vas wrote: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.


Can the existing methods delegate to where the new code will live? That way you don't have to change it all at once.
 
jay vas
Ranch Hand
Posts: 407
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
jay vas
Ranch Hand
Posts: 407
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24220
40
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

jay vas wrote: 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.



JV_XmlUtils, then!
 
Ranch Hand
Posts: 2458
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!