commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: Core architecture [was: Commons architecture]
Date Tue, 25 Jun 2002 06:41:31 GMT

Stephen Colebourne wrote:
> From: "Nicola Ken Barozzi" <>
>>- I see that there is a need for some more generic interfacts-facades
>>for common things like transforming stuff.
>>So I'm +1 on a transformation package. Is morphos ok for you? Just give
>>it a name and I'll move all my attention to it.
> My concern at the moment is that Transformer in [Collections], [Morphos] and
> Convertor in [BeanUtils] all do the same task (essentially). I shall have to
> look at Morphos again soon.

Well, Morphos is simply not there yet ;-)

I haven't committed anything because of the stuff I found in Collections 
and Beanutils...

Morphos should really be a facade-interface for all these packages in 
terms of transformation:

[Collections] Transformer
[BeanUtils] Convertor
[Cocoon] Transformer-Serializer
[POI] XXXTransformer-XXXSerializer
[Betwixt] itself
[Batik] Transcoder

Basically Morphos incluses also files in the picture, while current 
transformation things in [Collections] and [BeanUtils] do not AFAIK.

I think that it makes sense that Morphos is first implemented as a 
wrapper to all these, and can be used in the future maybe also as a 
common API.

Look in the mailing list archives for the status of the discussion.

>>- I see that there is also a need for interfaces that define *patterns*.
>>Facade, Factory, Command, etc...
>>So I'm +1 for a org.apache.commons.patterns package.
> This seems to be gaining ground as a place for these interfaces. Bear in
> mind each will have an assistant Utils class.

You mean a "reference implementations"?
Sure, it's cool :-)

>>As for the interfaces that act as markers or general behaviours, I'm -1,
>>since their behaviour can be enforced only by a container, ie framework,
>>in which they live, such as Avalon.
>>Rule of the thumb: if the interface is a noun, ok. If it comes from a
>>verb, no, since it requires actions from a container, and that is not
>>enforcible here.
>>In fact Avalon core interfaces are basically all "XXXable", because the
>>container acts on them.
> Following this rule would rule out Identifiable (one method
> getIdentifier()). Now I can sort of see why you are arguing this, but if you
> go that route then what do you do with IdentifiableUtils? IdentifiableUtils
> defines methods for getting a unique identifier. Sample implementations are
> incrementing number, random number, tomcat session id type number. ID
> generation can and should be shared. It just makes sense to me to keep the
> interface with the utility class. Note also that the Identifier generators
> are of course instances of Factory. Things start to connect.

Hmmm, then maybe my rule of the thumb is not so good ;-)

Ok, you correctly tell me that XXXable is also used for things that that 
can be reused in different programs without problems, and Identifiable 
is a good example.

> I think that we actually don't know what would happen if the Xxxable
> interfaces were in core. My belief is that they would probably be used in
> ways that we wouldn't dream of. Just because its called from a framework at
> the moment doesn't mean it has to be called only from that one framework.

Yes, but the point is consistency.

If you make a generic interface, it's for consistency.
If it's used in ways not forseen, there can be a problem.

Maybe a better rule is: is it a lifecycle interface does it affect the 
state of the Component?
In this case Identifiable is ok, since it gets info from a component.

I understand your points, and they make sense.
I also see that you value my concerns, and see that there is a 
possibility of doing all this without too many problems.

What you propose then are generic patterns, and I would assume that 
Identifiable is part of them, since it's a common concern that crosses 

I think that there is much more value in these than possible problems, 
really *much* more, so you have my +1 for them.

Which means I will help :-)

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

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

View raw message