On Tue, Sep 29, 2009 at 5:48 AM, Michael Hunger <[email protected]> wrote:
> how to separate state enough from consumers so that they get real types (not
> just primitives, see stephans blog post and dans power of values).
Rickard's ValueComposite approach can solve the problem of "no discrete types".
> interface ReadOnlyProperty<T> {
> T get();
> }
> interface Property<T> extends ReadOnlyProperty<T> {
> void set(T value);
> }
We have been down that road in the past and it doesn't work. It might
be worth to have a "Property<T> toImmutable()" method on the Property
interface, but forget the subtyping.
> Another thing I noticed while looking at the streamline codebase is that at
> different places the internals of the entities (state) is exposed completely
> and business logic/infrastructure works on the raw properties. This doesn't
> seem to be better that the getter/setter approach in Java Beans ?
That is a choice of balance that Rickard & Co has made. In my
"industrial automation" application (still an infant), I don't expose
any state. Example;
@Mixins( ComponentModelService.Mixin.class )
public interface ComponentModelService extends ComponentModel, ServiceComposite
{
interface State
{
Name name();
Description description();
RuntimeType runtimeType();
}
abstract class Mixin
implements ComponentModel
{
@This private State state;
@Override public String name()
{
return state.name().get();
}
@Override public String description()
{
return state.description().get();
}
@Override public Class<? extends FlowComponent> runtimeType()
{
return state.runtimeType().get();
}
}
}
In this case, I have chosen to work with "discrete types" in the
'context interfaces' to get going, but likely that "Name" will become
"NameProperty" and a pure "Name" type will be a refactoring waiting to
happen... but that's my "compromise" for the time being.
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
