2009/11/16 Niclas Hedhman <[email protected]> > On Mon, Nov 16, 2009 at 5:48 PM, Jacek Sokulski <[email protected]> > wrote: > > > Have you tried to implement basic patterns in COP? It should be a good > test > > for COP expressiveness, as patterns are usually compensation for language > > shortcomings. > > 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. > . > > > > There are two possible reservations: > > 1. The logic of an entity is scattered in many places. From an > interaction > > point of view it is can be an advantage, since the entity participates in > > interaction through one of its roles, but understanding the whole > behaviour > > of an entity can be difficult (even in the case of one role, the role > can > > require other roles that require still other roles...) > > Potentially true, but also a good way to measure decoupling/cohesion > balance... > > > 2. State composition - doesn't it introduce all the problems of multiple > > inheritance, moreover in a hidden form? > > Nope. Since methods are resolved one-by-one, there is always an easily > predictable resolution of a method's constituents. In > multiple-inheritance languages, such as C++, the resolution must be at > class level, and no easily understood resolution algorithm. > > > I mean dynamic control, i.e. one Person entity may play Manger role other > > not (although it has potentially this ability). > > There are several ways to implement this. > > 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)) > > >Another point is dynamic > > roles composition: a person can play possible hundreds of roles, but from > > the application point of view only several are interesting, > > "hundreds of roles" is probably not feasible in any real application. > Show me with an example of what you are trying to say... > never mind, the point was just adding a new role > > > > How can I add a new role to > > person entity without changing the existing code? > > I think you see this as a problem because of OOP conditioning. Types > are not related to the serialized state. > > I see, but how do you decide which role implementation and state to use? > You don't need to "add a role" to an entity, since the roles are not > stored. Instead, you effectively do; "Ok, here is a Role (an > interface) and load up Entity 1234 into that role." > > There are some nastiness hidden in the fine details, for instance that > potentially the different roles could be stored in different entity > stores, and therefor the retrieval of the old state would fail, and > entity stores that needs type mapping can't be used and possibly > others. But in general, this is fairly straight-forward. > > > 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 >
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
