commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chuck Daniels" <c...@yahoo.com>
Subject RE: [lang] DEVELOPERS-GUIDE.html
Date Sat, 02 Aug 2003 00:36:49 GMT
Thanks for your kind reply, Stephen.

After reading the thread on [io][vote] FileUtils: decision on style, I can
see where the reasoning comes from for making the "utility" classes
non-final.

My question then is, is there a better approach to implementing a "utility"
class than by creating a class containing only static methods?  That is, can
we implement a "utility" class in such a way that:

(1) it can be "properly" subclassed if necessary
(2) it can be used with tools such as velocity, and
(3) we don't have to break "good" design rules (such as the arguably "good"
rule that says a "static" class should be made final)?

I am a purist at heart, as I imagine many others may be, so I wonder if
there is a fundamentally "better" approach that can be taken.  Or are we
stuck with a less than elegant compromise due to inherent limitations of the
Java language?

Thanks again,
Chuck

> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Saturday, August 02, 2003 10:07 AM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] DEVELOPERS-GUIDE.html
>
>
> Your post is welcomed even though I disagree ;-)
>
> The choice and decision making process is based on long term watching of
> [lang] and commons in general. A rule has come about at commons that we
> should generally allow people to shoot themselves in the foot, rather than
> restrict them via programmatic means.
>
> This is expressed in
> - public constructors on utility classes (seems stupid/bad at first, until
> you realise they are essential for some tools like velocity)
> - non-final (seems bad too, but is less bad than preventing a user from
> subclassing)
>
> So did we jump the gun? No we merely documented experience and de facto
> standard.
>
> Stephen
>
> ----- Original Message -----
> From: "Chuck Daniels" <cjd4@yahoo.com>
> > Forgive me if I'm out of line, as this is my first time posting after
> > following a few threads on this list for some time.
> >
> > It seems to me that you have jumped the gun on adding "the
> class will not
> be
> > final" to the document.  It doesn't appear to me that any type of
> consensus
> > has been reached on the topic of making XxxUtil classes final or not.
> >
> > For what it's worth, I vote for making such classes final, as it really
> > seems to make no sense to subclass classes that contain only static
> methods.
> > If you really want to subclass a class, then it should not be a
> "utility"
> > class, but perhaps a singleton as Craig suggested earlier in
> this thread.
> >
> > Further, if someone feels that a "utility" class appears to be
> lacking in
> > some way, shouldn't they contribute to improving the class rather than
> > attempting to subclass it without sharing the improvements?
> >
> > I also agree with Arun that making a "utility" class non-final
> does little
> > more than save you an import statement.
> >
> > Cheers,
> > Chuck
> >
> > > -----Original Message-----
> > > From: Henri Yandell [mailto:bayard@generationjava.com]
> > > Sent: Thursday, July 31, 2003 9:58 AM
> > > To: Jakarta Commons Developers List
> > > Subject: RE: [lang] DEVELOPERS-GUIDE.html
> > >
> > >
> > >
> > > I've added:
> > >
> > > <li>the class will not be final</li>
> > > <li>methods should generally be 'nice' and 'quiet'.  That is, they
> should
> > > suppress Exceptions when sensible. </li>
> > >
> > > as rules for XxxUtils and also:
> > >
> > > <h4>Exception throwing</h4>
> > > <p>When throwing an exception to indicate a bad argument, always throw
> > > IllegalArgumentException, even if the argument was null. Do not throw
> > > NullPointerException. </p>
> > >
> > >
> > > Is the 'nice' and 'quiet' one okay? Or should I ignore it
> because there
> > > are times when XxxUtils might want to throw Exceptions. ie) JdbcUtils
> > > would throw SQLException from everything and IOUtils should throw
> > > IOException from everything.
> > >
> > > Hen
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message