search

gridgain / gridgain-old

267 stars 85 forks source link

Eleminate GG API Interfaces and Classes Leaking into Libraries not Using GG #53

Open sirinath opened 10 years ago

sirinath commented 10 years ago

Current GG API is such that there are times where GG API leaks into packages which has nothing to do with GG is you are to make them usable from GG. I think you have to revisit the API and try minimise the coupling of GG from the code that calls GG and also eliminate all possibilities for it leaking into packages which does not deal with GG computing. This leads to bad coding and design on the APIs the user is writing.

You might have to have existing API for backward compatibility but provide more loosely coupled alternatives also.

I am closing this https://github.com/gridgain/gridgain/issues/34 in favour for this issue. This is something I can across but there could be other instances where this might be happening.Market interfaces can be used internally but having use marker interfaces in non dependent libraries so it can also be used with GG in certain cases is a bad design choice.

dsetrakyan commented 10 years ago

I don't understand what you mean by "GG API leaks into packages".

sirinath commented 10 years ago

You have some market interfaces which you need to implement. If a library is to be used with GG sometimes you cannot implement any marker interfaces since the library will end up having GG as a dependency. So there should be a way to separate this, which means you have to give a way to implement an alternative way to do the same without the marker interface.

sirinath commented 10 years ago

Use cases are you are using a 3rd party library you do not have the code and also you want to create a more general purpose library.