commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: [pattern] Pattern charter, whats in, whats out
Date Sat, 10 Aug 2002 16:01:45 GMT
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
> far:
> 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.

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


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

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

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

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

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.


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

View raw message