commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [lang] DEVELOPERS-GUIDE.html
Date Sat, 02 Aug 2003 18:32:36 GMT
This is a question that we will come back to after the 2.0 release (not
wishing to duck the reply....)

There may well be alternatives to static utility classes, but I would never
expect us to make the ones we have final or private constructor.

Stephen

----- Original Message -----
From: "Chuck Daniels" <cjd4@yahoo.com>
> 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
>
>
> ---------------------------------------------------------------------
> 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