On Wed, Nov 18, 2009 at 12:37 AM, Jacek Sokulski <[email protected]> wrote:
> 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. As Rickard mentioned, it is a feature, not a problem. I think you are looking for the weaknesses in Qi4j, and that is good. So we should try to document the way you can blow your head off (barrel pointing at your head when you pull the trigger), and how to avoid it (make sure barrel points towards target). > 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 typically true for very simple properties, like name(), description() and I think that by being more explicit, the problem in reality becomes very small. > 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. It is a balance, just like private/public methods and members in Java classes, but I think you are right in that "share it only with strongly coupled roles", which also leads to weaker coupling in general and to more supple codebases. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
