commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack, Paul" <>
Subject RE: [Collections] Naming conventions
Date Thu, 13 Jun 2002 17:16:01 GMT
Here's an idea.  We can make the source more manageable
and effectively limit the number of public classes by
breaking my One Decorator Class To Rule Them All into
smaller ones based on subinterface:

   Bags (for SortedBags too)
   Maps (for SortedMaps and MultiMaps too)

It avoids the naming collision, keeps the source in 
distinct places, and prevents us from having another
public class every time somebody comes up with 
another great decorator idea...

Though I guess we would need another public class
every time somebody comes up with another great 
Collection subinterface.  But that doesn't seem like
it would happen as often as new decorators (we already
have 5 new decorator ideas on the table, no 
outstanding Collection subinterfaces...)

Also, the more I think about it, it seems that organizing
the source code according to return type makes a lot of
sense, as a rule of thumb.  For instance, where do we put
this method?

  // Returns a predicate that returns true for objects
  // that are greater than o, according to the sort 
  // order specified by c.
  public Predicate greaterThan(Object o, Comparator c);

It uses a comparator, but produces a predicate.  Does it
go in Comparators or Predicates?  With the 
organize-by-return-type approach, it's obvious that we 
put it in PredicateUtils; and it's hopefully obvious to
a user of the library where to find such a beast.


> -----Original Message-----
> From: Stephen Colebourne []
> Sent: Wednesday, June 12, 2002 2:18 PM
> To: Jakarta Commons Developers List
> Subject: Re: [Collections] Naming conventions [was 
> ComparableComparator
> - nulls OK]
> Good argument, and logical. However the 'Collections' class 
> could have 6 or
> more groups of decorators if the dreams become reality. Maybe 
> this isn't a
> problem, but I wouldn't want that class to contain all the 
> static nested
> classes (for maintainability)
> There is another factor - the classes don't just contain decorators.
> FactoryUtils/PredicateUtils (current names) create 
> Factory/Predicate objects
> not decorate them.
> Some possibilities:
> - CollectionUtils
> ie. add to existing class, probably should merge in ListUtils 
> too - this
> seems quite a big change. And MapUtils doesn't fit well (its rather a
> strange group of methods)
> - Decorators
> - CollectionDecorators
> - DecoratedCollections
> - DecoratorUtils
> these emphasise the role of the resultant classes, but how is 
> the source
> laid out
> - SynchronizedCollections, PredicatedCollections, ... as I originally
> proposed
> these emphasise the particular decorator, and fit well with 
> managable source
> units
> Deciding where the source will go is another factor in this. 
> Nice can of
> worms!
> Stephen

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

View raw message