Skip to main content



      Home
Home » Modeling » EMF » Separating API from Implementation in Model
Separating API from Implementation in Model [message #663403] Mon, 04 April 2011 16:53 Go to next message
Eclipse UserFriend
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] Mon, 04 April 2011 20:42 Go to previous messageGo to next message
Eclipse UserFriend
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] Mon, 04 April 2011 23:18 Go to previous messageGo to next message
Eclipse UserFriend
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 12:44 Go to previous message
Eclipse UserFriend
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: Fri Jul 04 19:23:52 EDT 2025

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

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

Back to the top