Hi Toni, Thanks for your quick advice. And indeed that's what I do :
- I am using package imports, not bundle dependencies - Composition is the default approach, but just doesn't cut it in all situations - In general I do try to follow all kinds of rules for "good modular and OO design" - But in some concrete design situations I am trying to match it to minimal module/bundle dependencies, which is also a rule I have - And the sketched situation bothers me in that respect As an extra, I also encounter following situation, as a slight variation on the previously described one : - ClassA now inherits from ClassB (again in 2 separate bundles). In fact there are many different subclass implementations of ClassB, all in different implementation bundles. - ClassB depends on a ClassC in a bundle C, in one of its method signatures (i.e. ClassC is used as an argument or return type) - I get an error in the PDE compilation : "The type ClassC cannot be resolved. It is indirectly referenced from required .class files" - As a consequence it seems I also need to add an explicit dependency (done via import package) of all implementation bundles (like bundle A) to the bundle C. Whereas I would hope/expect that this dependency is already clearly defined in bundle B... With some more concrete explanation : - We're building a modular processing engine, that can be extended with specific "backend adapters" to perform data collection to/from other systems - Most complexity of the adapter is implemented once and reusable, in an adapter base class e.g. "BaseBackendAdapter". - The adapters are used by a common "BackendService" implementation that has a reference to its adapter (i.e. composition). The reference is typed to the "BaseBackendAdapter". BackendService and BaseBackendAdapter are provided in a common "base" bundle. - Each concrete adapter bundle registers a BackendService instance, with its dedicated concrete adapter, as an "OSGi" service etc. Implementation code in the concrete adapter bundles depends really on actual communication APIs etc. - So I would prefer to have just 2 main dependencies : on the base bundle and on the concrete communication API. - Problem is now, that I need to replicate some dependencies of the "base" bundle in each concrete adapter bundle, which I don't like... cheers erwin On Tue, Jan 29, 2013 at 1:01 PM, Toni Menzel <[email protected]> wrote: > Quick answer to parts of your question: > > - Prefer composition over inheritance. Just don't build on inheritance > and your developer life, not just the OSGi one, will be better ;) > - Avoid Bundle dependencies. If you encounter a situation where you > have the abstract class and the final one in same package you should carry > it around in one bundle. Otherwise just make the abstract one explicit by > giving it a separate package. (avoid split package) > > You learn this quickly by avoiding PDE. > Toni > > > *Toni Menzel | Founder Rebaze GmbH* > [email protected] | +49 171 65 202 84 > http:// <https://mail.google.com/mail/u/0/goog_1770677242>www.rebaze.com > | twitter @rebazeio <https://twitter.com/rebazeio> | LinkedIn > Profile<http://www.linkedin.com/company/2553599> > > *Rebaze Pilot: *The free one day onsite consulting opportunity. We will > capture your potential. > *Rebaze Pass: *A unique subscription service for key technologies: OSGi, > Maven, Chef, Jenkins. > *Rebaze Onsite: *Our way to improving your development team on site. > > > On Tue, Jan 29, 2013 at 12:41 PM, erwin dl <[email protected]> wrote: > >> I often encounter situations where a certain class ClassA in a bundle A >> depends on a class ClassB in a bundle B, and where ClassB is a subclass of >> ClassC in a bundle C. >> >> So it is logical that bundle B has a dependency on bundle C. >> >> But to get the things compiled and working, I am forced in such a >> situation to also add an explicit dependency of bundle A on bundle C. >> Even when not directly referring to the base-class in my ClassA... >> >> At least this is true in eclipse's PDE. >> But in internal discussions here, it seems to be perceived as an >> inevitable fact, independent of eclipse or equinox implementation choices... >> >> I would prefer that the implementation decision of ClassB, to inherit >> part of its stuff from ClassC, i.o. implementing it directly itself, would >> be hidden for ClassA and bundle A. >> >> I.e. it is not a situation where a kind of API is provided in bundle C, >> and where bundle A would better use the API, and where bundle B provides >> implementations as services etc. >> It's a simple class-hierarchy set-up that exposes implementation >> decisions and forces dependents to add a-priori "unnecessary" extra >> dependencies... >> >> If someone has advice or ideas on this, I would be very interested to >> hear/learn from them! >> >> Many thanks, >> erwin >> >> >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
