2009/11/18 Niclas Hedhman <[email protected]> > On Wed, Nov 18, 2009 at 4:53 PM, Jacek Sokulski <[email protected]> > wrote: > > Maybe it is part of the "initial confusion" :-). What is confusing here > is > > that on the one hand state injection in a mixin looks like implementation > > detail on the other hand it is kind of public interface. > > I like to see it as a "Module Implementation Detail", since I try to > make what you call state injection (builder pattern) module private > concern. > OOP's single level of private/public aspect is kind of going away, as > we have more granularity to play with. >
Still a bit confused, but I think I see now your points why this is a feature and a way for DCI implementation. What bothered me was that mixins interactions is mainly through row state, somehow I have missed other possibilities. If I correctly understand, the general rules for using mixin interactions can be: 1. If roles are closely connected (e.g HasName and CanChangeName) they can share common raw state (NameState). 2. Otherwise for state access use role interface (HasName, CanChangeName, or some intermediate interface controlling access to the state) instead of the raw state (NameState). ( From implementation point of view NameState can be for example package protected interface). Another possible view on the state could be that it is OK to use the row state directly but the state is more closely connected with the domain, more like entity in JPA than just a bunch of data use internally by implementation. In such case EmployeeState has definite domain semantics and when I manipulate it I know the context. So there would be two levels of static modelling: roles modelling and states modelling. Anyway, in correct use of Qi4j the main issue seems to be the change of the mindset from OOP/Java to COP/Qi4j/DCI not technical details... Jacek
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
