Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Separating API from Implementation in Model
Separating API from Implementation in Model [message #663403] Mon, 04 April 2011 20:53 Go to next message
Alain Picard is currently offline Alain PicardFriend
Messages: 233
Registered: July 2009
Senior Member
I'd like to get some feedback on some of the patterns discussed here:
http://www.ibm.com/developerworks/websphere/techjournal/1007 _charters/1007_charters.html#sec5

and how we could achieve the proposed bundle separation in EMF and even
add the service flavor part.

Thanks for the insights,

Alain
Re: Separating API from Implementation in Model [message #663424 is a reply to message #663403] Tue, 05 April 2011 00:42 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30554
Registered: July 2009
Senior Member
Alain,

EMF has not been so much focused on the ability to provide different
implementations of the same model but rather of hiding the
implementation behind an API so that the implementation can be
arbitrarily changed. Things like XyzPackage.eINSTANCE require the
package instance to be available and I doubt many folks would want
different implementations of that. The XyzFactory.eINSTANCE is a
similar issue. There does exist the ability to specify an
implementation of the factory that overrides the default one, and of
course that allows one to provide different implementation classes for
the rest of the API as well. In any case, I wouldn't worry in general
about conforming to "rules" just for the sake of conforming to rules but
rather I'd focus on what problem needs to be solved and why. Factory
overrides seem adequate if not perfect for what's needed...


Alain Picard wrote:
> I'd like to get some feedback on some of the patterns discussed here:
> http://www.ibm.com/developerworks/websphere/techjournal/1007 _charters/1007_charters.html#sec5
>
>
> and how we could achieve the proposed bundle separation in EMF and
> even add the service flavor part.
>
> Thanks for the insights,
>
> Alain
Re: Separating API from Implementation in Model [message #663432 is a reply to message #663424] Tue, 05 April 2011 03:18 Go to previous messageGo to next message
Alain Picard is currently offline Alain PicardFriend
Messages: 233
Registered: July 2009
Senior Member
I agree with your general statement here. It's just that I'm seeing some
cases where certain projects have dependencies on model classes more
like from a POJO perspective and these dependencies are making the whole
plugin management more complex than I wish.

Alain

On 4/4/2011 8:42 PM, Ed Merks wrote:
> Alain,
>
> EMF has not been so much focused on the ability to provide different
> implementations of the same model but rather of hiding the
> implementation behind an API so that the implementation can be
> arbitrarily changed. Things like XyzPackage.eINSTANCE require the
> package instance to be available and I doubt many folks would want
> different implementations of that. The XyzFactory.eINSTANCE is a similar
> issue. There does exist the ability to specify an implementation of the
> factory that overrides the default one, and of course that allows one to
> provide different implementation classes for the rest of the API as
> well. In any case, I wouldn't worry in general about conforming to
> "rules" just for the sake of conforming to rules but rather I'd focus on
> what problem needs to be solved and why. Factory overrides seem adequate
> if not perfect for what's needed...
>
>
> Alain Picard wrote:
>> I'd like to get some feedback on some of the patterns discussed here:
>> http://www.ibm.com/developerworks/websphere/techjournal/1007 _charters/1007_charters.html#sec5
>>
>>
>> and how we could achieve the proposed bundle separation in EMF and
>> even add the service flavor part.
>>
>> Thanks for the insights,
>>
>> Alain
Re: Separating API from Implementation in Model [message #663578 is a reply to message #663432] Tue, 05 April 2011 16:44 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 30554
Registered: July 2009
Senior Member
Alain,

It should generally be possible not to export any of the model Impl
classes; they're exported by default so that folks can extend a model's
implementation by default, but it's not necessary to allow that. It's a
little disturbing how often folks end up using implementation classes
for no apparent good reason, i.e., where only the methods on the
interfaces are needed ; no one has ever explained why they're doing
that, though I have a theory...


Alain Picard wrote:
> I agree with your general statement here. It's just that I'm seeing
> some cases where certain projects have dependencies on model classes
> more like from a POJO perspective and these dependencies are making
> the whole plugin management more complex than I wish.
>
> Alain
>
> On 4/4/2011 8:42 PM, Ed Merks wrote:
>> Alain,
>>
>> EMF has not been so much focused on the ability to provide different
>> implementations of the same model but rather of hiding the
>> implementation behind an API so that the implementation can be
>> arbitrarily changed. Things like XyzPackage.eINSTANCE require the
>> package instance to be available and I doubt many folks would want
>> different implementations of that. The XyzFactory.eINSTANCE is a similar
>> issue. There does exist the ability to specify an implementation of the
>> factory that overrides the default one, and of course that allows one to
>> provide different implementation classes for the rest of the API as
>> well. In any case, I wouldn't worry in general about conforming to
>> "rules" just for the sake of conforming to rules but rather I'd focus on
>> what problem needs to be solved and why. Factory overrides seem adequate
>> if not perfect for what's needed...
>>
>>
>> Alain Picard wrote:
>>> I'd like to get some feedback on some of the patterns discussed here:
>>> http://www.ibm.com/developerworks/websphere/techjournal/1007 _charters/1007_charters.html#sec5
>>>
>>>
>>>
>>> and how we could achieve the proposed bundle separation in EMF and
>>> even add the service flavor part.
>>>
>>> Thanks for the insights,
>>>
>>> Alain
>
Previous Topic:New Ecore container-reference validation rule in Helios: Bug?
Next Topic:Generic EMF Forms Editor?
Goto Forum:
  


Current Time: Tue Oct 22 05:42:18 GMT 2019

Powered by FUDForum. Page generated in 0.03157 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top