Niclas Hedhman wrote:
> I had a very fruitful albeit wet discussion with Andreas Oberhack over
> Associations on Friday evening.
>
> There were essentially one point of contention;
>
> * Can an Association have behavior??
>
> My stance is "No, but show me a use-case and I'll reconsider". OTOH,
> if associations are complex enough, I could imagine that they are in
> their own right an Entity instead, with two other associations
> involved. "Employee" could be consider an Association complex to be
> its own Entity.
>
>
I too think that Associations should not have behaviour.
It's important to define what behaviour we are talking about here, I
think about behaviour that changes state as the central concept.
Another thing is side-effect free functions ( calculateXXX ) which can
also be called behaviour, but this is easier to allow.
Compare with value objects: They are typically immutable but can contain
convenience methods ( side-effect free functions )
What do we think about the following:
An Association subclass has startDate and endDate properties, a very
common requirement.
A possible convenience method getAssociationTimePeriod would return
(endDate.time - startDate.time)
This is permissible i think.
But there are some side-effect free functions that I would rather not
want to have in the Associations themselves:
Functions operating on other entities, it's much more intuitive to have
those in entities (or services).
Root entities implement functions that operate on entities reachable
from the root.
> One use-case that was discussed led to "A third-party will evaluate
> the relationship...." (for instance a MortagageManager will evaluate
> (among other things) the bank customer's relationship with the bank),
> but the Association itself doesn't really carry enough information,
> i.e. it doesn't have a field for the "source", which I think we should
> enforce in Qi4j Runtime.
>
>
I don't quite follow you here, please explain.
Is the behaviour of the MortagageManager a candidate for behaviour to
be moved into an Association?
> Now, another thing that struck me...
>
> Does ManyAssociations require and/or allow the type to be Association?
> Initially, I remember, we required it to be an Association, but I
> think we removed it for convenience reasons. Is that really smart? And
> like-wise, what happens if I ignore the Association requirement;
>
> public interface Person extends EntityComposite
> {
> Person spouse();
> }
>
>
Sorry for my ignorance, but does this mean that in the
ManyAssociation case we have a choice to use Association or not, but
there is no choice in the single association case?
It depends of course on the rationale for using the Association
construct in the first place, one observation is that the association is
made explicit by ManyAssociation even though Association is not used "in
it". I.e. it signals clearly that there is an association of cardinalty
X between two entities.
/Niklas
> Cheers
> Niclas
>
> _______________________________________________
> 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
