On Wed, Nov 18, 2009 at 10:03 PM, Jacek Sokulski <[email protected]> wrote:
> Still a bit confused, but I think I see now your points why this is a
> feature and a way for DCI implementation. What bothered me was that mixins
> interactions is mainly through row state, somehow I have missed other
> possibilities.
Uhhh? No, you don't have to (and perhaps shouldn't) share raw state
between mixins, and instead use the regular Qi4j features.
public class TheaterMixin
{
@This ScriptManagement sm;
:
}
@Mixins( ScriptManagementMixin.class )
public interface ScriptManagement
{
Script findMostAppropriateScript( Conditions cond );
void addAvailableScript( Script script );
void removeAvailableScript( Script script );
interface State
{
ManyAssociation<Script> scriptsAvailable();
}
}
@Mixins( TheaterMixin.class )
public interface TheaterEntity extends Theater, EntityComposite
{}
In the above "sample", the ScriptManagement is a private mixin (role
if you like) that doesn't intend to "publish" its internal state, but
the ScriptManagement.State is part of the Entity's state and will be
saved with the rest of the state of that entity.
> If I correctly understand, the general rules for using mixin interactions
> can be:
> 1. If roles are closely connected (e.g HasName and CanChangeName) they can
> share common raw state (NameState).
But then, why is it not a single role? I am sure there are border
cases, but generally speaking, I think state is fairly role related.
That said, there was talks about a feature called "Abilities" a long
time ago, and it is still listed as a potential feature in future
version. Basically, Abilities are the "requirements" of a Role. So for
instance, the ActorRole requires that the composite has an
ActingAbility, and the implementation of that maps/glues the role
implementation to the composite that is going to get the ActorRole.
This allows even greater flexibility in how the Role-to-Object mapping
happens, and kind of mimics the real world.
> 2. Otherwise for state access use role interface (HasName, CanChangeName, or
> some intermediate interface controlling access to the state) instead of the
> raw state (NameState). ( From implementation point of view NameState can be
> for example package protected interface).
It doesn't have to be package protected. Visibility rules and
Composite construction will effectively hide the private mixins
anyway.
> Another possible view on the state could be that it is OK to use the row
> state directly but the state is more closely connected with the domain, more
> like entity in JPA than just a bunch of data use internally by
> implementation. In such case EmployeeState has definite domain semantics and
> when I manipulate it I know the context. So there would be two levels of
> static modelling: roles modelling and states modelling.
Yes, I think you mean the same thing as I outlined above.
> Anyway, in correct use of Qi4j the main issue seems to be the change of the
> mindset from OOP/Java to COP/Qi4j/DCI not technical details...
Very much so... Rickard's experience from Sitevision is invaluable,
and now being complemented with the StreamFlow project using Qi4j,
giving new insights in what works and not (well, for him at least).
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
