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.