commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [pattern] issues!
Date Sun, 11 Aug 2002 23:44:03 GMT
A good post. (inline)

From: "Jack, Paul" <pjack@sfaf.org>
> 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.

Yes, Predicate, Transformer, Command, Factory and ThrowableHandler do not
fit comfortably with [pattern]. They are callbacks.


> 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.

Yes.Yes.Yes.Yes.Yes.Yes.Yes.Yes!!!
(but only the callbacks - Predicate, Transformer, Command, Factory and
ThrowableHandler)
[pattern] should remain for Identifiable at present.



> For
> instance, I'd really like to see these methods make it into
> ObjectUtils:
>
>     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);
>         list2.removeAll(...something...);
>         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.

Actually, [pattern] already supports this factory, its called
prototypeFactory. There is also a cloneTransformer. These currently have cut
and paste code that is waiting for a new home. ObjectUtils is one
possibility.

Stephen



--
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