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 23:25:08 GMT
Well, the non-instantiatable doesn't necessarily hold in this case - the other point which
was clarified was that utility classes should have public no arg constructors documented as
for use only by tools (apparently many of the currently extant frameworks require bean semantics
and so require an instance of the utility class in order to access it's methods).  

I agree though with the comment regarding shadowing static utility methods.  If you needed
a secondary utility method which provided additional functionality, implement it in a separate
class with, potentially, delegation to the original method where appropriate.  

Cheers, 
-AMT

-----Original Message-----
From: Neil O'Toole [mailto:neilotoole@yahoo.com] 
Sent: Tuesday, July 29, 2003 3:16 PM
To: Jakarta Commons Developers List
Subject: RE: [io][vote] FileUtils: decision on style


> At first glance I don't really see the `need to override behavior'
> argument -- if a user doesn't like the way a static method is
> implemented, can't they just implement their own in a separate class?
> 

Absolutely. I don't see any reason why utility methods should be overridden. If a method doesn't
do what it says it does, it's broken and should be fixed in the next release. If you need
the utility method to do something else, then it should have a different name to distinguish
the funtional difference.

Also, why would you ever need to extend non-instantiable classes?

- Neil


--- Michael Heuer <heuermh@acm.org> wrote:
> On Tue, 29 Jul 2003, David Graham wrote:
> 
> > --- Arun Thomas <Arun.Thomas@solidusnetworks.com> 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.
> 
> Is the struts mailing list the best place to go archive-digging on 
> this topic?  At first glance I don't really see the `need to override
> behavior'
> argument -- if a user doesn't like the way a static method is
> implemented, can't they just implement their own in a separate class?
> 
>    michael
> 
> 
> >
> > David
> >
> > >
> > > 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
> > >
> >
> >
> > __________________________________
> > 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
> 


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