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)
predicatedBag
predicatedSortedBag
synchronizedBag
synchronizedSortedBag
unmodifiableBag
unmodifiableSortedBag
eventBag
eventSortedBag
filterBag
filterSortedBag
Lists
predicatedList
eventList
filterList
Maps (for SortedMaps and MultiMaps too)
Sets
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.
-Paul
> -----Original Message-----
> From: Stephen Colebourne [mailto:[EMAIL PROTECTED]]
> 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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
