On Fri, Sep 19, 2008 at 7:41 PM, Rickard Öberg <[EMAIL PROTECTED]> wrote:
> I've just realized that with the way we do state declaration as methods > in interfaces we are usually promoting the idea that Entity state is > exposed outwardly. Instead of having domain methods we have properties > which anyone can read and write. That doesn't feel right at all!! Agree. It pops its ugly head in quite a few places, for instance; * Indexing * Query * Visualization > Instead, my current thinking is > that the best pattern is to use private mixin types for it. Yes, that works. Question is if we should enforce it? Or perhaps have a global option to enforce that properties are not exposed in Composites. (Q; Why doesn't fields work? Is it about inter-Mixin access? ) > Another side-effect of this, which I can't see how to deal with, is how > to promote domain method access to an Entity, and still be able to bind > it into a UI. Visitor pattern is IMHO a good choice. And with COP/Qi4j, one can add the implementation "after-the-fact" with another MixinType (@MIxins and @Concerns). One small con is that "sub systems" are never really "untouchable" but will become much more like Lego where someone provides a lot of nice bits and pieces, but you typically need to assemble them yourself. In general, I think you hit on a weak spot, and frankly I have not spent any cycles over it before. I also have a GutFeeling that if this is enforced, we will get a lot of initial flak. People are so used to the "query and navigate" object structures, that it is hard to change... Cheers Niclas _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
