Hello Niclas!
Thanks for reply. I'm still gonna reply to this one, even tho Rickard started
two other topics from the original mail - just to close this one down at least.
> > This solution leads to a problem: anyone can cast the WorldZone or
> > WorldObject -interfaces (which they acquired from Factories) to
> > WorldZoneEntity and WorldObjectEntity -interfaces, respectively. And this
> > gives anyone the possibility of manipulating the associatons the way they
> > want - exactly what I try to prohibit!
>
> No. If th WorldZone doesn't expose the WorldZoneEntity, but you still have a
>
> @This private WorldZoneEntity entity;
>
> in your mixin/concern, you would have created a so called "private
> mixin" and it will be unreachable (unless some extreme reflection is
> done) from the outside world.
Ah, I think my solution exposed the WorldZoneEntity (since WorldZoneEntity
inherits from WorldZone), so anyone could do this:
WorldZone myZone = someFactory.createNewZone();
((WorldZoneEntity)myZone).worldObjects().add(someObject);
And if "someObject" would at that moment belong to some other zone, we would
have a singe WorldObject belonging to two WorldZones. Hence my desire to
strictly control this two-way association between WorldZones and WorldObjects.
I think I might have misunderstood things a little, based on a javadoc
description of @This. I will need to look more carefully into that.
> Our recommendation; If the WorldZone is an Aggregate of the
> WorldObjects, then you should use @Aggregated and only expose the
> WorldZone interface to the outside world (i.e. module public). Qi4j
> will then guarantee that the WorldObjects are only reachable and
> handled by the Aggregate i.e. the WorldZone. So, you would introduce
> for instance, removeWorld() on WorldZone, which deassociate the
> WorldObject (i.e. make it NOT part of an aggregate) and returns that
> entity to be added to a new WorldZone;
>
> WorldObject moved = zone1.removeWorld( localIdentifier );
> zone2.addWorld( moved );
This is an interesting solution. In fact, WorldZone is an Aggregate of the
WorldObjects, I seemed to miss out that one.
I assume "localIdentitifer" would have to be identity() of the WorldObject.
However, finding out which WorldZone WorldObject belongs to, is going to be a
little problematic and possibly slow. I am not sure which is going to be more
intense - the searching for WorldObject's WorldZone, or the searching for
WorldZone's all WorldObjects. I will need to look into that too.
> Yes, unfortunately there has been a lot of changes in the whole Entity
> management system, and docs are lagging more than half a year behind.
Oh, that is VERY familiar situation to me, hehe. :)
> There will always be more than one way to do something, and your
> milage may vary a lot depending on how you approach a problem space.
>
> Generally speaking, two-way associations are not recommended, although
> we do recognize that there are needs for it sometimes. If you move
> your public interfaces up to the aggregate, the need drops to near
> zero. Perhaps your WorldZone is not an aggregate of WorldObjects, in
> which case things get even more 'loose' and harder to manage.
>
>
> Finally, there are now toSet() and toList() on ManyAssociation,
> instead of ListAssociations and SetAssociations which have both
> disappeared in 0.8. This allows for a stricter contract and that Qi4j
> will ensure the immutability of the returned Set/List. ManyAssociation
> therefor has semantics of both Set and List.
>
> Cheers
Yeah, two-way associations seem to be problematic. I think the problem is that
expressing one two-way association requires you to do so in two different
places, and that just seems to explode all things.
Thanks for letting know about those ListAssociations and SetAssociations. I
will modify my code to use ManyAssociations everywhere.
_________________________________________________________________
Show them the way! Add maps and directions to your party invites.
http://www.microsoft.com/windows/windowslive/products/events.aspx
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
