On Mon, Jun 9, 2008 at 6:05 PM, Rickard Öberg <[EMAIL PROTECTED]> wrote:
> While refactoring the model I am sort of struggling with the different
> composite types (regular, entity and service for now). I have already
> separated services out from the other, so that internally there's a
> ServiceModel with an *optional* CompositeModel backing it, since it
> might be implemented without composites at all (e.g. importing a service
> through Jini).
Well, I was thinking that even Jini Services are backed by a
ServiceComposite, otherwise we have too much messy code. In reality, I
think it can work very well;
public interface SomeJiniServiceComposite
extends SomeJiniService, JiniServiceComposite
{}
@Mixins( JiniMixin.class )
public interface JiniServiceComposite extends JiniService, ServiceComposite
{}
I have some of this code already on my computer back in the office,
but got bugged down in the testing...
> Similarly, there are some significant differences between regular
> composites and entities. Only entities have associations, and the way
> these two handle state is radically different (regular composites always
> have the state in memory, whereas entities may have them lazy-loaded).
As for "only entities have associations" --> I think we might need to
reconsider this, one way or the other.
public interface Car
{
SetAssociation<Wheel> wheels();
}
In this case we now have a hard dependency that both Wheel and Car are
entities. And this is in the domain model, and we can not use this in
any other way.
I think that is a "unnecessary restriction" at domain modeling that we
should avoid.
> My general thinking right now is that
> inheritance in general is a code smell, and it has worked so far. But I
> honestly don't know how to do with these two.
Well, I am of the opinion that "Composite" should not be
instantiatable at all. And that we have an explicit ValueComposite for
it. That combined with no baseclass is what I would like to see. I am
even willing to drop "Composite" as a super-interface as well, to make
it even clearer.
Cheers
Niclas
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
