On 2009-11-18 20.19, Pawel Niemiec wrote:
My point is that with leaving polymorphism we lose a useful tool of
abstracting object in a way that is really needed when we don't care
how object are behaving. For example, assume we have a theatre. In
this theatre there is a guy that works with a sound. He has to adjust
sounds for all actors that are playing, so he needs to bring them on
a stage and listen to what they are playing. With polymorphism he
could do so:
Actor[] actor = factory.getAllActors();
Int voicePower0 = actor[0].play() Int voicePower1 = actor[1].play()
... and so on.
In this case we don't really have to worry about what role an actor
is playing. We lose that possibility without polymorphism. I'm not so
familiar with Qi4j yet, so maybe there is some kind of mechanism that
can be used in such ?
There is no problem at all to do this. Just declare Actor as the
interface of your composite and then provide different mixin
implementations:
@Mixins(ActorType1Mixin.class)
interface ActorType1Composite
extends Actor,EntityComposite
{}
@Mixins(ActorType2Mixin.class)
interface ActorType1Composite
extends Actor,EntityComposite
{}
According to your next considerations I personally think that the DCI
Architecture could be solution to that. Due to it objects are just
actors, that interact in some way with data. I personally think that
objects exists only in reality. Then we build an object model,
abstract it, implement this abstraction with some of class (abstract)
oriented languages and then try to rebuild "objects" again even if we
don't really need to. What we really need is behavior (role in DCI)
and data (including states, entities, etc.).
.. and then the interactions between the objects playing the roles. The
"script".
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
