On Tue, Sep 16, 2008 at 9:24 AM, Niklas Uhrberg
<[EMAIL PROTECTED]> wrote:
> 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.
Yeah, sounds reasonable.
> 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.
Ok, it becomes very blur quickly.
Since the Association has Properties, and we generally agree that
direct access to the properties for someone else to set them is not as
good as having the owner of the properties expose methods for what can
be done on them. That statement would indicate that Associations
indeed have behavior.
>> 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?
No. I was just trying to find a case where an external party is to
evaluate the Association between two parties and provide for instance
a judgement ("Mortgage denied.") from the Association itself. But the
Association only contains the "destination" and not information of its
"owner", hence lacking half the parties involved.
>> 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.
Well, half my question is exactly that... If we require the
Association in the 1:1 relationship, why is that not required for the
1:* case? Or the other way around, whichever suits your fancy. My
point is (I think), if Association is indeed a first class, required
citizen, then ManyAssociation should require Associations as the only
acceptable type in its collection (additional convenience methods can
of course exist to make it easier to use). ATM, *I* have lost track of
what we finally settled with on these issues and want it clarified.
Cheers
Niclas
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
