Design approach for extending class functionality - Embedded C++

Question

For my company i am refactoring our embedded C/C++ code base to increase re-usability for commonly used functionality. Currently i am refactoring our command line interface but i ran into a design issue.

Our core command line interface is good and stable as is but in some project there is a need or wish to add additional functionality to it. For example to provide a command history or privilege levels for specific commands.

My design issue comes from the fact that some projects require only one of the extensions and others use multiple or even all.

My question: What would be appropriate approach to allow such extensibility as described above.

Currently i have looked into simple inheritance and the decorator pattern but haven't been able to make a proper design out of it. With inheritance i ran into the diamond of death and with the decorator i failed because of lack of knowledge. Maybe i am looking to much for a one fits all design where multiple different approaches maybe better.

Answer 1

The problem that you have, is that you try to find a single tool to solve all your problems:

"It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail."
- Abraham Maslow

The question is way to general for a practical answer. But your narrative shows that you try to address very different kind of extensions.

Typically, you could use a decorator to add a new responsibility, like managing the command history. The main benefit is that it uses composition to allow dynamic extension at run-time, whereas inheritance requires a compile-time decision.

But you should be very prudent when considering a decorator for altering behavior of the base class, since it might lead to break the LSP as explained here. For example, if you need to use different privileges for commands, you'd better use a strategy pattern: this takes the same responsibilities of a class, but alters the behavior. You could then have different strategy to say whether or not do access control. Now, if you're working on embedded stuff, you could be interested in policy-based design: it uses a compile-time strategy rather than a run-time strategy.

Finally, you could refactor your command-line interface to separate the parsing of the commands, from their execution. For the latter, you could be inspired to use the command pattern if it's about a command-line user interface. You coul dthen have a very extensible core, since any new user interaction could be handled by some parsing map (i.e. a list of commands that is constructed at startup), and a new derived class for every new command.

Be aware that these are only examples, to show that there are different kind of extensions tha need different tools. FInally, as you're in the embedded world, you'd better consider compile-time choices rather than runtime whenever it's possible.