Bryce L Nordgren a écrit :
> The GeoAPI uses Collections interfaces to implement aggregations in the UML
> from 19107. The way in which it uses them forces implementations to
> provide the actual data structure to clients because this is the only way
> to add component pieces (e.g. add points to a polygon, etc.) Providing
> such access to external objects leads directly to a synchronization issue.
>
> The implementation we inherited from Sys technologies has a beginning of a
> solution to this problem. But it is basically a List implementation. I
> need Collection and Set as well, and I'd like them to be decorators instead
> of a full up implementation.
>
> Apache has some dead code (in the commons-dormant "events" project) which
> does this: ObservableSet|List|Collection. To top it off, these are
> decorators. I'd really like to use it.
Which needs are we trying to solve? If the only thing we need is a listener to
be used by our
implementation only, I would prefers to avoid the Apache common collections for
the following reasons:
- It is an other >500 kb dependency. It is worth it if we are going to use a
fair amount
of Jakarata classes. But if we are going to use only a collection with
listener, which
can be implemented by about ~5 kb in Geotools (with more control on our
side), I would
rather do it in Geotools...
- Jakarta duplicates many J2SE classes. They have their own implementation
of HashMap, etc.
- The decorator pattern is a nice design, very useful when the amount of
classes is not
very large. For a large amount of collection (as I would expect in
geometries), it is
going to put a significant burden on the garbage collector and consume
more memory.
In the particular case of HashMap and HashSet from J2SE, there is only one
method to
override in order to get our listener behavior.
Martin.
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
