Niclas Hedhman wrote:
> 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.
>
>
So what? That doesn't add anything to the discussion about what kinds of
behviour you would like to see in Associations.
But it does answer the original question "Do they have behaviour" in a
way...
So, to be clear: The original question "Do they have behaviour" needs
clarification as to what kind of behaviour is meant, hence the discussion...
I start from the "non-technical" side and discuss what behaviour, would
be relevant/appropriate in Associations since some of it would be less
than desirable IMO.
>>> 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.
>
>
Ok, fine.
I suspect that I envision a different kind of usage of Associations then.
The typical use case is to invoke methods on an entity and it would use
the data belonging to the Association(s) only internally.
Another use case is that a client (MortgageManager) indeed gets data
belonging to Association(s) directly from the Association but this will
start
by obtaining the Association from the originating Entity in the first
place. Therefore the need for an "owner" property doesn't arise.
/Niklas
>>> 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
>
>
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
