Avoiding Inheritence Madness

Question

So, I have an API that I need to implement in to an existing framework. This API manages interactions with an external server. I've been charged with coming up with a way to create an easily repeatable "pattern," so that if people are working on new projects in the given framework they have a simple solution for integrating the API.

My first idea was to create a class for your "main" class of the framework to extend that, would provide all the virtual functions necessary to interact with the API. However, my boss vetoed this, since the existing framework is "inheritence heavy" and he wants to avoid adding to the madness. I obviously can't incapsulate my API, because that is what the API itself is supposed to be doing, and doing so might hide functionality.

Short of asking futures developers to copy and paste my example, what do I do?

Answer 1

If your boss is hostile to inheritance, try aggregation. (Has-a relationships rather than inheritance's is-a relationship.) Assuming you interface with the API in question via an object, maybe you can just keep that object in a property of your framework 'main' class, so you'd interact with it like main->whateverapi->doWhatever(). If the API isn't object-implemented or you need to load a lot of functionality specific to your environment onto it, that points toward making your own class that goes into that role and relates to the third party API however it needs to. Yeah, this basically means you're building an API to the API. Aggregation allows you to avoid the masking-functionality problem, though; even if you do have to do an intermediary layer, you can expose the original API as main->yourobject->originalapi and not have to worry about inheritance mucking things up.

Answer 2

Sounds to me like what your boss is having a problem with is the Framework part of this. There is an important distiction between Framework and API, in order to code to a framework you must have a good understanding of it and how it fits within your overall development, much more of a wholeistic view, adding to frameworks should never be taken lightly.

API's on the other hand are just an interface to your application / Framework and usually just a library of utility calls, I can't see that he would have a problem with inheritance or aggregation in a library, seems to me that the issue would be creating additional complexity in the framework itself, i.e. requiring developers to extend the main class of the framework is much more onerous than creating a stand alone API library that people can just call into (if they choose) I would be willing to bet that your boss would not care (in fact probably support) if the library itself contained inheritance.

Answer 3

Like the answer from chaos above, I was going to suggest aggregation as an alternative to inheritance. You can wrap the API and make it configurable either via properties or via dependency injection.

Also for a related topic see my answer to "How do the Proxy, Decorator, Adaptor, and Bridge Patterns differ?" for a run-down on other "wrapper" design patterns.