On 2009-12-03 20.04, Stanislav Muhametsin wrote:
About theory - I'm not 100% familiar with UML post-conditions. Most
definitions I know and the ones available on Internet, seem to include
the internal state to both pre- and post-conditions. Because we are
talking about Qi4j Constraints, and they don't have access to internal
state, we can leave out the internal state when talking about pre- and
post-conditions. I think the internal state conditions can be expressed
in Concerns, since Concerns have access to internal state, and the
composite implementator is aware of all Concern implementations his/her
composite has.
Yes, that seems to make more sense. pre-conditions/post-conditions, to
me, are more about asserting internal state, whereas constraints relate
to validating the ingoing(/outgoing) state of methods. Two different
perspectives. Using Concerns for pre-conditions/post-conditions sounds
like a good idea.
I should add that in my own code I have two layers to my domain code:
the top layer is the interactions, and the bottom layer is the data.
When I call interaction methods they will take domain objects as input,
and then I can use Constraints to verify that that their internal state
is in a valid state before continuing with the interaction.
For example, in my model I have Tasks as domain objects which can be in
ACTIVE or COMPLETED state. Then I have an Inbox interaction which can do
inbox.complete(task). For the complete() method to be valid the task has
to be in the ACTIVE state, which I can check for using this:
void completeTask(@HasStatus(ACTIVE) Task task, Assignee assignee);
(this is my actual code)
So pre-conditions on a lower level can be transformed into constraints
on an upper level. I *could* implement the above as a concern on the
underlying task.complete() method as well though. And in fact, that
might actually be a better way of expressing this rule.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
