...and sometimes I just walk the path of least resistance :)
I've taken all the relevant options and made the changes.
- now managed from the single factory class, all the wrappers are inner
classes. Just as java.util.Collections and
org.apache.commons.collections.PredicateUtils.
- the internal object creation (the wrapper logic itself) works off a
factory mechanism defined by an interface (I called it
"SimpleObjectFactory"). Has an internal StandardFactory for the simple
use of class definitions to create objects. Naturally, other logic can
provide custom version.
- there's only three wrappers off three collections. Only those which
call on specific objects are relevant. The others are generalised calls
on the entire collection, and not useable for this purpose.
- the result of calling subList(int a, int b) on the wrapped
implementation is in turn wrapped again, so it mimics the ability of the
wrappers.
If you want to look at code...
http://www.keyboardmonkey.com/next/lazy-list/LazyCollections.java
http://www.keyboardmonkey.com/next/lazy-list/SimpleObjectFactory.java
Arron.
Stephen Colebourne wrote:
>>>The decision to code PredicateUtils as one class is because:
>>>1) This is how java collections do it ( Collections.unmodifiableList() /
>>>Collections.synchronizedList() )
>>>2) Having 8 new classes in the public commons collections API was deemed
>>>undesirable. (In fact there are 18 static nested classes in
>>>
>PredicateUtils!)
>
>>>The decision to use factory methods is because:
>>>1) This is how java collections do it ( Collections.unmodifiableList() /
>>>Collections.synchronizedList() )
>>>2) It allows the implementation classes to be completely hidden leading
>>>
>to a
>
>>>compact API.
>>>
>>The single entry point of the factory is fine, but I just don't like the
>>composition of that source file. Including java.util.Collections. It's
>>horrible. I'd rather have the other classes there but confined to the
>>package. Done widely in other api's. Same thing without the nasty
>>
>monolith.
>
>For OSS work I could be tempted to agree with you (a time implementation I'm
>looking after uses the package scoped classes approach). But collections
>(java/apache) seem to like one class. C'est la vie.
>
>Stephen
>
--
To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
|