--- Neil O'Toole <[EMAIL PROTECTED]> wrote:
> > 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. 

But other people *will* see a need, guaranteed.  It's a rather limited
view to think that no one could ever possibly want to extend your classes.
 This lesson has been learned the hard way in BeanUtils and in Struts so I
encourage you to rethink this strategy.

David

> 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 <[EMAIL PROTECTED]> wrote:
> > On Tue, 29 Jul 2003, David Graham wrote:
> > 
> > > --- Arun Thomas <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
> > > > Sent: Tuesday, July 29, 2003 11:44 AM
> > > > To: Jakarta Commons Developers List
> > > > Subject: RE: [io][vote] FileUtils: decision on style
> > > >
> > > >
> > > > --- Arun Thomas <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
> > > > > 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 [EMAIL PROTECTED] 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:
> > [EMAIL PROTECTED]
> > > > > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> > > > >
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> > [EMAIL PROTECTED]
> > > > > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> > > > >
> > > >
> > > >
> > > > __________________________________
> > > > Do you Yahoo!?
> > > > Yahoo! SiteBuilder - Free, easy-to-use web site design software
> > > > http://sitebuilder.yahoo.com
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > [EMAIL PROTECTED]
> > > > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > [EMAIL PROTECTED]
> > > > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> > > >
> > >
> > >
> > > __________________________________
> > > Do you Yahoo!?
> > > Yahoo! SiteBuilder - Free, easy-to-use web site design software
> 
=== message truncated ===


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

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to