You have to copy the contents. Otherwise you would expose the list to all the operations on List and Set and would have
to care for vetoing, notification all of the changes.
I'd rather go for a copied unmodifiable variant for toList() toSet().
I also did the extends Iterable<T>
Michael
Am 03.04.2009 4:46 Uhr, schrieb Stuart McCulloch:
2009/4/3 Rickard Öberg<[email protected]>
Hey,
While doing the refactoring for the new persistence I want to include
Michaels suggestion to not let ManyAssociation extend the JDK Collection
classes.
The question then is what semantics to have. I would suggest that a
ManyAssociation is:
* Ordered like a List
* Contains no duplicates like a Set
* Has minimal convenience methods
Which would result in the following:
public interface ManyAssociation<T>
extends AbstractAssociation
{
int count();
boolean add(int i, T entity);
boolean remove(T entity);
T get(int i);
Iterable<T> toIterable();
List<T> toList();
Set<T> toSet();
}
Points:
* I want to specifically keep down the number of helper methods (isEmpty,
remove(i), add(T) etc.) so that it is easy to add Concerns to it and not
have to implement a whole bunch of various methods.
* Add has index, which makes it possible to use it as a list.
* If you need to use the ManyAssociation with JDK-friendly libraries, use
the "to" methods to create wrappers. The List will have Set semantics
though, as that is how ManyAssociation work, and Set will have List
semantics, as that is how ManyAssociations work.
Does this make sense? Any missing methods?
couple of thoughts, you could make it:
extends AbstractAssociation, Iterable<T>
because Iterable<T> only has one method "iterator()" and you'd then
get the benefit of being able to use the many association in a foreach
without having to do "toIterable()", which looks a bit clunky
also, the wrapper methods should really be called "asList", "asSet", etc.
because they return views onto the original object (see "Arrays.asList")
rather than copying the contents, while "to..." usually suggests copying
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
------------------------------------------------------------------------
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
--
Michael Hunger
Independent Consultant
Web: http://www.jexp.de
Email: [email protected]
Enthusiastic Evangelist for Better Software Development
Don't stop where you are: http://creating.passionate-developers.org
We support Software Engineering Radio (www.se-radio.net)
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
