> 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 <[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 > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
