On Mon, Nov 16, 2009 at 7:05 PM, Jacek Sokulski <[email protected]> wrote:
>> You give me the pattern, and I will take a shot at a replacement > > Some, like observer, are straightforward, but I wander about inheritance > based patterns, like Bridge, Template Method or Strategy. In reality, inheritence based patterns are constructs of OOP, and not easily discussable in a COP context. But, I think these 3 (well the first two) are actually variants of exactly the same thing, namely interface hiding across multiple classes and implementation selection. So, for the first (hiding), Qi4j provides "Private Mixins" where the mixins within a composite can call each other on methods not available to the "outside world". This addresses a lot of concerns in the OOP world, both behavioral hiding (above patterns) and state hiding. As for implementation selection, the central concept in Qi4j is "Visibility Rules", which more often than not is capable of selecting the right implementation without further configuration. And this mechanism is inherent to all composite meta types. In reality, these OOP patterns has emerged from particular needs, and some patterns may survive into the COP world with the same name but different way of abstraction, and others will just disappear and yet others will emerge (for instance how to do the Command-Query-Separation). >> For instance, an entity that is created as a Employee can be retrieved >> later as a Manager. > > The question was the other way, i.e. the above scenario should raise an > exceptions for some Emploeeys (that are potentially managers but not > *actually* (like in real life)) That is a domain concern and outside the scope of Qi4j. > I see, but how do you decide which role implementation and state to use? Again, it is a domain concern to track that. Well, state is determined via an Identity, and if you don't have one, nothing can be "used"... ;-) Rickard's conclusion is pretty much that a lot less "services" are to used compared to the OOP/POJO world, where behavior-free containers are tossed at services to be manipulated, and instead things are handled at each object. So, for instance, Manager may have 'promoteEmployee( Employee employee ) in which case it will list that employee in "ManyAssociation<Employee> managedResources()", perhaps communicate this to some HR Manager and so forth. Think real life! :-) It is not the object that decide what Role it current has, it is the context the object is in that dictates it, even in this example. HTH 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 -- 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
