|
| Re: EMF Design: Why subclass instead of decorator? [message #421168 is a reply to message #421161] |
Tue, 29 July 2008 16:03   |
 David Steinberg
Messages: 489
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
The intent of EObject is to provide a base set of behaviors provided by
all modeled objects that allow them to participate in the framework.
It's analogous to (though obviously richer than) java.lang.Object.
Most of these concepts are all wrapped up in the identity of the object
(container, notification, etc.), so it just seems logical to me, anyway,
to have the object itself provide them. If we took the decorator
approach, would eObject().getContainer() return the container object
itself (as eContainer() does) or would it return the EObject being
decorated? Would notifications sent by the wrapped EObject say that the
decorator or the EObject was the notifier?
These are just my thoughts, and I wasn't a part of this design decision,
but I can't really imagine it working well any other way.
Cheers,
Dave
Christian wrote:
> I know this is going to be hard to answer in summary form, but I am
> wondering (long story...design thinking related to EMF concepts) about
> what went into the decision to have generated EMF classes extend their
> loosely typed parents (EObjects) as opposed to decorating them.
> In other words, instead of having MyThing extend EObject, an instance of
> MyThing could have decorated an instance of EObject.
> Maybe this was just to keep the generated code clear of a bunch of
> delegating methods. But I would assume there was more to this. Can
> someone just brain dump out a couple of reasons so I can settle my mind
> about this?
>
|
|
|
|
Powered by
FUDForum. Page generated in 0.03776 seconds
] 
Search
Help
Register
Login
Home
