Chuck, I would be pretty keen on figuring out a better approach to utility classes as well (RBD's suggestion deferring the decision between singleton and booch utility to the user seems interesting.) I think, however, that the 3rd option will still not be a possibility. Look back at thread "[lang]DEVELOPERS-GUIDE" for the usecase regarding UString.... In this case, the request/requirement for "not final" is due not to a technical constraint, but to a real usability issue.
While I was nominally correct in stating that making a booch utility class final only costs an extra import, I've since reconsidered - there's also the cost associated with retraining an entire user base to use a new call format for String functions. If the class is made final, everyone previously familiar with calling UString.xxx() for string utility methods will now have to call UString.xxx() for some functions and StringUtils.xxx() for others. Leaving the class "non-final" ensures a familiar USE interface (UString) through extension. (I've just made up the name "USE interface" to constrast it with a functional interface - is there a standard name for this concept?) That said, the choice to make these classes "not-final" then ensures less possibility of error for existing users at the expense of more potential errors for newbies - probably a sensible exchange. Cheers, -AMT -----Original Message----- From: Chuck Daniels [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2003 5:37 PM To: Jakarta Commons Developers List Subject: RE: [lang] DEVELOPERS-GUIDE.html Thanks for your kind reply, Stephen. 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:[EMAIL PROTECTED] > 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" <[EMAIL PROTECTED]> > > 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:[EMAIL PROTECTED] > > > 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: [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] --------------------------------------------------------------------- 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]
