Geek Answers Handbook

Avoiding the Madness of Inheritance

So, I have an API that I need to implement in an existing structure. This API controls the interaction with an external server. I have been charged that you can create an easily repeatable “template” so that if people work on new projects in this structure, they have a simple solution for integrating the API.

My first idea was to create a class for your "main" frame class, to extend it, provide all the virtual functions needed to interact with the API. However, my boss vetoed this because the existing structure is "inheritance heavy" and he wants to not add to the frenzy. I obviously cannot encapsulate my API, because this is what the API itself should do, and this may hide functionality.

In short, futures developers copy and paste my example, what should I do?

+3
source share
3 answers

, . ( Has-a, - .) , API , , , main->whateverapi->doWhatever(). API , , , API, . , , API API. ; , API main->yourobject->originalapi , .

+3

, Framework. Framework API, , , , .

API, , /Framework , , , , , , API, ( ), ( , , ), .

0

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

Also for a related topic, see my answer to “ How do the proxy, decorator, adapter and bridge settings differ? ” For running on another “wrapper”.

0
source

More articles:


All Articles