commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack, Paul" <>
Subject [pattern] issues!
Date Sun, 11 Aug 2002 20:01:03 GMT
I really don't think [pattern] is the right name for [pattern].
The interfaces in [pattern] don't define design patterns, and,
strictly speaking, never could.  A design pattern isn't a 
concrete API.  A design pattern is a definition of terms that
allow you to apply a general principle to invent a concrete
API, not the API itself.

BCEL, for instance, uses the Visitor design pattern, in two 
separate packages.  There are two separate Visitor interfaces,
two separate EmptyVisitor implementations, and two separate
DescendingVisitor implementations.  My point is just that the
two Visitor interfaces don't, and in fact never could, have a
common superinterface; we couldn't ever give the world a 
o.a.c.pattern.visitor package for them to extend.  That's just
not the nature of design patterns.

All of the [pattern] interfaces, plus the proposed ThrowableHandler,
are all callbacks that let a component defer processing to some
other object.  Functors.

It's true that there is a design pattern named Command and a
design pattern named Factory, but these are more detailed than our
interfaces.  The Command pattern, for instance, usually stipulates
a Receiver for the command, if I recall correctly.  Again, the 
*patterns* are principles that you apply to generate an API, not
an API itself.

So, methinks [pattern] is a bad name.  Issue #1:  Can we please
rename [pattern]?

Issue #1 evaporates if we all agree on issue #2:  Merge [pattern]
into [lang].  The distinction is a little ambiguous to me, and 
there's all kinds of ways they can depend on each other.  For 
instance, I'd really like to see these methods make it into

    public static boolean isCloneable(Object o);
    public static Object clone(Object o);

clone(Object) would use reflection to invoke the given object's 
public clone() method, or raise IllegalArgument if there's no such
method.  isCloneable(Object) could be used to check if clone(Object)
would actually work.  Useful if you want to preserve a type of a
collection without knowing the type:

    public List splitList(List list) {
        List list2 = (List)ObjectUtils.clone(list);
        return list2;

Okay, fine.  HOWEVER, I would also like to see the following added
to FactoryUtils:

    public static Factory cloneFactory(Object prototype) {
        return new Factory() {
            public Object createObject() {
                return ObjectUtils.clone(prototype);

See?  Recursive dependency.  And I think there's gonna be more like this.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message