commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arun Thomas" <>
Subject RE: [io][vote] FileUtils: decision on style
Date Tue, 29 Jul 2003 23:13:40 GMT
So I think I'd agree completely with you here....  I've run into this far too often myself
to really make lots of use of static implementations of functionality.  (I do use static methods
to delegate to singletons that provide the actual functionality, and which can be replaced
with subclasses or alternate implementations as needed, and I do occasionaly capture small
pieces of functionality in static methods.)  However, when you do have the "XxxUtils" type
files which are explicitly (and the Developer's Guide does state this) containing only static
methods, it seems to really promote good design to prevent extension of such classes - they're
only classes at all because Java doesn't really provide a paradigm for capturing disparate
domain functionality without a class.  


-----Original Message-----
From: David Graham [] 
Sent: Tuesday, July 29, 2003 12:30 PM
To: Jakarta Commons Developers List
Subject: RE: [io][vote] FileUtils: decision on style

--- Arun Thomas <> wrote:
> Hmmm....  From the last three notes - I think I understand clearly the 
> motivation for requiring the public no-arg constructor, but I still 
> don't understand the reasoning behind the need for avoiding final.  
> The only reason I can see (with possibly poor vision) is to allow 
> access to the methods of the utility class plus additional specific 
> methods with a handle on only one class object or utility instance (of 
> the subclass utility).  This seems to me to be very poor design if 
> such a constraint exists.  Can anyone see any other value to extending 
> utility classes with entirely static methods?

Because static methods can't be overridden you may as well declare them final.  However, static
methods are truly evil.  As soon as you think no one will ever need to override the behavior,
some user will come along with a need to do so.  This happened in Struts and now we're replacing
all the static methods with Singleton classes with instance methods.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message