On 2009-11-18 00.37, Jacek Sokulski wrote:
It was contrived example and, sure, you can model it with VOs or other means, but it is not the point. State is public per composite so in implementation/reusability unit (role mixin) I do not have control of it, in other words the state is a kind of global data. The state carries a very definite semantics and if two roles uses the same state assuming different semantics it can lead to vicious bugs. It is especially true if one is composing entity from existing roles without knowledge of the implementation.
That is true. At the same time, being able to share state is one of the key enablers of implementing the DCI pattern: roles are supposed to modify the internal state, and many roles can work with the same state. If you have rules for how to work with the state, then put those methods in the state interface as well.
Maybe it is just bad practice to share inner state directly between roles (although I think this way it is done in some examples), and each role should have its private state or share it only with a strongly coupled (semantically) roles.
I think the word "role" is overloaded in this context. When talking about "role" in the DCI sense, then the state *should* be shared. When talking about roles in the sense you describe, then you have to choose whether to have the state directly in the entity, or whether you need a valueobject per role-instance.
/Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
