If both Developer and Alumni extends the same class, then you are back in 'class oriented programming' world, where the class instances are the first class citizens and from which you derive an object, yet having a discussion that the Alumni object and the Developer object is different roles of the same object, which class-oriented programming doesn't define. And in that lies a general problem of class-oriented programming, basically that the object is abstracted away to a class.
When we started Qi4j, I (can't fully speak for Rickard) had concluded that programming was totally backwards. Objects are inherent to the world, classes are not. Class comes from the word classification, which is our ability to ascribe a common set of attributes and/or behaviors to a set of objects (typically more than one). And the classification of an object changes over time, a tree becomes a log becomes timber, a crashed car is a modification of the normal car, and so on. So, in the first prototype instance of Qi4j, the class was 'assigned to' an object like a property in runtime, which I still think is the fully appropriate way to do it, BUT I agree with Rickard's objection that it becomes too difficult to manage and troubleshoot. Last night before falling asleep I had another thought; Are all data really objects? My sleepy conclusion was "No", and that it may even be better to treat raw data as exactly that, raw data. Which would then beg the question; Isn't it really so that all "objects" are always present in the program, and "objects" don't have an hibernated state? I am not totally sure of that answer, but if so, then what are all these objects that we create and call "entities"? Data or "object representations"... Perhaps the distinction between "objects" (with behavior) and "object representations" (without behavior) is too subtle for most to observe it, since all objects are a kind of representation in the computer language anyway... Perhaps certain things are really best treated as records in a table, and if so, how do draw the line? Once you identify that "Hey, maybe data are not really objects...", then one can continue and challenge everything else. Again, I think this is a symptom of Computer Science trying to abstract away all differences, giving us a Mouseter Tool (someone watch Mickey Mouse Club House?) suitable for everything and nothing. 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 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 ? 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.). Polymorphism from the other hand was present from a very long time and it was very useful. Just take C hooks for example. I think that polymorphism is this kind of abstraction that is present in a real life and we all use it. Is it wrong to have it in abstract models and in implementation, I'm not sure. For sure it's useful for some aspects, especially when we don't want to take care of objects behavior or tracking a program's flow. Br Pawel Niemiec _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
