commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [pattern] Pattern charter, whats in, whats out
Date Sat, 10 Aug 2002 16:31:59 GMT
Costin Manolache wrote:
> Stephen Colebourne wrote:
>>Ola asked on what criteria I would accept or reject patterns. Other
>>discussions have focussed on merging with [lang] or whether patterns are
>>appropriate for commons. So I thought I'd look into what has been coded so
>>There are already groups appearing in [pattern]:
>>Group 1 - Utility patterns, like java.util.Comparator:
>>- Predicate, Command, Transformer, Factory, (ThrowableHandler)
>>They are intended to be implemented by an inner class, not a bean (what I
>>mean is that the implementing class will only implement this one method).
>>Thus they represent utility bits of code. These are already in commons
>>(collections) and Predicate will probably be used by IO
> As long as they are clearly needed and used in the context of an
> specific utility - it's fine. If Collections define a Predicate
> that will be used to operate on the collection data - it's a perfect
> use of an interface, and people using collections can use that
> interface when they need to.
> +1 on this - as long as the collection package actually needs them.

Exactly :-)  +1

>>Group 2 - Marker interface patterns:
>>- Immutable, (also Null, Mutable, Bean ...)
>>These marker interfaces rely on something (ie. a framework) knowing about
>>them. For Immutable, I included ImmutableUtils to try to be a basic
>>framework. But it doesn't really work. The problem is that there is no
>>clear use case.
> I would sugest moving those to avalon. They also have a number of marker
> interfaces, and there is little use of checking if Immutable is implemented
> if some components don't use the interface. In other words they make
> sense inside a framework ( like avalon ) when all components are expected
> to use them, they don't make sense on commons.

I agree. +1 (if-when Avalon accepts them)
In fact we have decided out of experience that marker interfaces "are 
bad (TM)", and so we have also decided to deprecate the marker Component 

This is meta-information, and is now specified in descriptors about the 
lifestyle of a Component/Service.

>>Group 3 -Bean style patterns:
>>- Identifiable, (also Resetable, Destroyable, Initializable,
>>StateChangeable, EmptyQueryable, Saveable, Loadable, ... the list could be
>>long, and you'll have to guess what some of these are about)
>>Unlike group 1, these are intended to be implemented by a bean, not an
>>inner class (what I mean is a proper class - one with a number of methods
>>other than those of the pattern interface). They allow that bean to
>>perform certain common behaviours in a standardised way.
> That seems avalon-like to me.
> They have components implementing specific interfaces - Identifiable
> would be a perfect fit ( if they don't already have it ) :-)
> Destroyable/Initializable is lifecycle ( you'll probably need to fight
> some wars to get them to change their lifecycle ).

All these are 100% Avalon, and you would get a lightning fast -1000 from 
me. We already have many of these interfaces, and they were discussed 
more than 99% of programmers could tollerate ;-) .

I would suggest you to join us over at Avalon, you seem to like it :-)

>>My preference is thus as follows:
>>Group 1 becomes part of [lang]
> I think collections may be a better place, if they need it. 
> [lang] is great as long as it defines utils - if it gets into marker 
> interface business, then we have a problem. 

Gee, wierd.
Lang is about Utils... and util?

I would keep them in pattern, since they are to use Patterns.
Or are you two mixing 3 with 1?

>>Group 2 dies, unless Avalon is interested
> I'm not an expert in avalon (:-), but they seem to fit - I know they
> have quite a few similar interfaces.

We already do in fact.
Propose them over there.

>>Group 3 becomes [pattern], in the sandbox, not depended on, not in the
>>upcoming core.jar

AAAAgghhhhhh >:-O


You want to put Avalon in commons!

> My criteria for getting it into commons-proper: if it's a tool/utility
> that can be _used_ by a project, and if there is a chance that jakarta
> projects will adopt it - it's fine.

I'd say let's keep pattern a package for interfaces-classes that help 
implement design patterns.

Marker interfaces, forget them.

Lifecycle, don't you dare >;-P

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