would it be sensible to add something like a manyassoc concern for
valuecomposites?
So that handling of those collection like members would be a no brainer ?
Another issue I have thought about in the last days is:
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).
The problem is:
if you have something like:
interface Describable extends Property<String> {} and you push this type to a consumer it always gets the mutable value
( describable.set(String) ).
What I try to avoid is just passing properties to a client but instead would
like to have a
interface ReadOnlyProperty<T> {
T get();
}
interface Property<T> extends ReadOnlyProperty<T> {
void set(T value);
}
and then be able to push the ReadOnly-Version to clients.
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 ?
Perhaps using something like Holub's importer/exporter pattern, that declares interfaces for getting information from an
object or pushing state information to it in a controlled fashion would be more useful?
http://www.holub.com/publications/notes_and_slides/Everything.You.Know.is.Wrong.pdf
Then implementing the exporter interface in an information sink (like a statistics service) and getting the (immutable)
information pushed to myself is more safe, coherent and maintainable than working on the objects/entities internal state
(which is always subject to change).
WDYT ?
Michael
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
