Of all the proposed solutions, Pauls is the best.
Static utility classes should not be instantiated, period. Various posts have said why (Craig,
Steven Caswell)
However, there is a valid, practicality based, use case for being able to subclass these classes
to add your own utilities. But the class needs to remain non-instantiable.
Thus protected with an exception gets my vote.
The Util class outlined below is the appropriate solution for Velocity's limitation. (And
should thus be coded in Velocity, not commons)
Stephen
> from: "Michael A. Smith"
> Jack, Paul wrote:
> > Actually, I've been thinking for a while now that I'd like to see
> > the utility constructors in [collections] be, at least, protected.
> > That way people could extend our libraries to add their own static
> > utility methods and inherit all of ours. For instance, we can't
> > use the JDK's naming convention (making an interface name plural)
> > because they made java.util.Collections's constructor private. If
> > they had made it protected, we'd have been able to extend it to add
> > our own utility methods; people could get all of our new utilit
> > methods just by changing the import...
>
> I'd be ok with that...
>
> > So, I'm not against visible constructors. However, in my ideal
> > universe, the constructors are (1) protected to make it clear what
> > they're for and (2) exceptional; any attempt to actually instantiate
> > a CollectionUtils would raise a runtime (um, UnsupportedOperation?)
>
> so the implementation of the protected constructor would just throw an
> exception? sounds ok to me, although it doesn't help velocity people
> that need an instance of an object.
>
> > Would the Velocity folks mind including something like this in
> > Velocity:
> >
> > public class Util extends Object {
> >
> > final public StringUtils string = null;
> > final public ObjectUtils object = null;
> > final public CollectionUtils collection = null;
> >
> > public Util() {
> > }
> >
> > }
> >
> > Then they'd use the Util class instead of the individual libraries;
> > and could invoke the methods by saying Util.string.method() instead
> > of StringUtils.method().
>
> hmmm.. on first read of that, I thought, "Does that actually work?"
> But then I thought about it some more, and realized that it probably
> would... too bad I'm too exhausted right now to actually try it out.
> Theoretically, this would solve the velocity "problem" without requiring
> exposure of a constructor for an object that never should be constructed.
>
> michael
>
>
> --
> To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
|