When to use "is abstract" and when "is interface" [message #431647] |
Mon, 20 July 2009 15:53 |
Eclipse User |
|
|
|
Originally posted by: formatzeh.gmx.de
A simple question. When modeling an ecore model I have several classes
from which other classes inherit. Now I'm asking myself when to use
which option. Maybe it is better to use both? As I'm a beginner with EMF
I don't know what makes the difference, for example in the generated
editor. I mean for every class an interface will be generated. So what
makes the difference?
best regards
Gilbert
|
|
|
|
|
|
Re: When to use "is abstract" and when "is interface" [message #431672 is a reply to message #431651] |
Tue, 21 July 2009 12:55 |
Eclipse User |
|
|
|
Originally posted by: formatzeh.gmx.de
Ed Merks wrote:
> No AbcImpl is generated for something that's marked as an interface,
> which implies you can't create instance, hence it must be abstract as
> well, and it implies that if you extend it, you have to implement the
> interface completely rather than extend a class with a shared/existing
> implementation.
that also means that it is efficient to define those classes, not
containing any attributes, as interfaces and those, containing
attributes, only as abstract? The reason is that the
attributeGetters/-Setters only are defined in the abstract class and not
in every interface-implementing subclass?
|
|
|
Re: When to use "is abstract" and when "is interface" [message #431673 is a reply to message #431672] |
Tue, 21 July 2009 13:01 |
Thomas Schindl Messages: 6651 Registered: July 2009 |
Senior Member |
|
|
Hi,
Well inheritance is not really fast in java so having a too deep class
hierarchy is not always the best and further not really easy to understand.
Tom
Gilbert Mirenque schrieb:
> Ed Merks wrote:
>> No AbcImpl is generated for something that's marked as an interface,
>> which implies you can't create instance, hence it must be abstract as
>> well, and it implies that if you extend it, you have to implement the
>> interface completely rather than extend a class with a shared/existing
>> implementation.
>
> that also means that it is efficient to define those classes, not
> containing any attributes, as interfaces and those, containing
> attributes, only as abstract? The reason is that the
> attributeGetters/-Setters only are defined in the abstract class and not
> in every interface-implementing subclass?
|
|
|
Powered by
FUDForum. Page generated in 0.03281 seconds