Hey,
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!!
My first thought was to get rid of the idea that properties and
associations are declared in interfaces, and instead do them as fields,
but that doesn't really help either. Instead, my current thinking is
that the best pattern is to use private mixin types for it. For example:
interface Foo
{
// Domain methods
}
interface FooState
{
// State methods
}
public class FooMixin
implements Foo
{
@This FooState state;
// Implement Foo and use FooState
}
Something like that. It's yet another interface to be done per Entity,
but I can't see any other way to do it, in order to hide the internal
state properly.
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. That is the typical reason why we put public properties on
our Entities (to use it in a UI), and the common complaint is "state is
not encapsulated!" and yet I have not seen a good solution to it. Any
ideas? The only thing I can come up with is to have the UI call the
Entity using the Visitor pattern, something like "show(UI)" and then the
Entity itself gets to do the population of the UI.
How should we do this? Any thoughts?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
