commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From scolebou...@btopenworld.com
Subject Re: [lang][collections] Utils having a public constructor
Date Tue, 13 Aug 2002 10:23:25 GMT
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>


Mime
View raw message