commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arun Thomas" <Arun.Tho...@solidusnetworks.com>
Subject RE: [io][vote] FileUtils: decision on style
Date Tue, 29 Jul 2003 18:55:07 GMT
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?  

Cheers, 
-AMT

-----Original Message-----
From: David Graham [mailto:grahamdavid1980@yahoo.com] 
Sent: Tuesday, July 29, 2003 11:44 AM
To: Jakarta Commons Developers List
Subject: RE: [io][vote] FileUtils: decision on style


--- Arun Thomas <Arun.Thomas@solidusnetworks.com> wrote:
> Can someone expound on this "lesson"?  The Developers Guide mentions 
> neither the rule that "final" should be avoided, nor the rule that a 
> public constructor is required.  I'd love to know the reasoning - is 
> there some reason that actually derives from the constraints of lang, 
> or is it due to constraints on how other systems use lang?  I'm 
> particularly confounded by why the use of final would be a problem.

Marking a class as final prevents subclassing which is an extraordinarily bad idea in generally
available framework classes.  This also goes for methods.  Classes without default constructors
are not JavaBeans and thus cannot be dynamically created and used in certain environments.

David

> 
> Cheers,
> -AMT
> 
> -----Original Message-----
> From: Henri Yandell [mailto:bayard@generationjava.com]
> Sent: Tuesday, July 29, 2003 5:55 AM
> To: Jakarta Commons Developers List
> Subject: Re: [io][vote] FileUtils: decision on style
> 
> 
> 
> 
> On Tue, 29 Jul 2003 Christoph.Reck@dlr.de wrote:
> 
> > Hey thanks for the heads up!
> >
> > being one of the original authors/contributor of this class, I do 
> > have
> 
> > some comments (mostly in favour of your proposal)...
> >
> > 1rst: you seem to have added a private constructor to prevent
> > instantiation, which hurts usage as in velocity, where you need an 
> > instance of a class to allow the introspection to work. I'm -1 for 
> > that change in CVS.
> 
> Yep. This is a Lang-lesson. Have an empty constructor in every 'Utils' 
> class which mentions in a javadoc that this is not intended to be 
> used:
> 
>     /**
>      * <p><code>ObjectUtils</code> instances should NOT be constructed

> in
>      * standard programming. Instead, the class should be used as
>      * <code>ObjectUtils.defaultIfNull("a","b");</code>.</p>
>      *
>      * <p>This constructor is public to permit tools that require a 
> JavaBean instance
>      * to operate.</p>
>      */
> 
> Also worth looking at and maybe adopting the relatively simple: 
> DEVELOPERS-GUIDE.html in Lang. Mainly it just outlines the XxxUtils 
> philosophy.
> 
> Also don't make XxxUtils a final class.
> 
> 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
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

---------------------------------------------------------------------
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