I work for a company in software research department. We use algorithms from our real software and wrap them so that we can use them for prototyping. Every time an algorithm interface changes, we need to adapt our wrappers respectively.

Recently all algorithms have been refactored in such a manner that instead of accepting many different inputs and returning outputs via referenced parameters, they now accept one input data container and one output data container (the latter is passed by reference). Algorithm interface is limited to a static function call like that:

class MyAlgorithm{
static bool calculate(MyAlgorithmInput input, MyAlgorithmOutput &output);

This is actually a very powerful design, though I have never seen it in a C++ programming environment before. Changes in the number of parameters and their data types are now encapsulated and they don't change the algorithm callback.

In the latest algorithm which I have developed I used the same scheme. Now I want to know if this is a popular design pattern and what it is called.

  • 5
    Are you sure that's not an anti-pattern? It protects you from changing your wrapper layer, but it removes a huge amount of protection from using the wrapped things normally! Effectively you have no checks on the type and number of method arguments, unless you program it in explicitly. That is roughly the state of the art of C in 1970 or so. Commented Nov 5, 2013 at 15:26
  • @KilianFoth I see it more like lisp, where parameters are passed in as lists and everything can go in as long as the algorithm expects that input. Using classes provides me with some basic parameter-checking. E.g. I can set all values to default in the constructor and force an explicit constructor to be called with the minimum required number of arguments to make sure that all values are initialized. I sort of take out the parameter checks from the algorithm itself into the parameter containers. Commented Nov 5, 2013 at 15:30
  • Makes it kind of hard to do any method overloading, doesn't it?
    – TMN
    Commented Nov 5, 2013 at 15:48
  • Why is the method static? You might have different algorithm variants that use the same parameters and compute the same thing slightly differently; by making the method static, you cannot just keep them in a container and eg. test them against each other. Encapsulating input and output params into object when there are many is a common pattern, as you can keep the interface stable, and can provide defaults more easily, as it removes the ordering problem.
    – Wilbert
    Commented Nov 5, 2013 at 15:52
  • Wasn't this a common practice in Fortran-77? Commented Nov 5, 2013 at 16:29

1 Answer 1


This is actually a very powerful design, though I have never seen it in a C++ programming environment

I think the word powerful is open to interpretation, and really depends on perspective, agreeing with Kilian Foth comment, in what he calls an anti-pattern.

Most C++ projects you will see are likely open sourced, or open in one way or another, thus licencing modules and code obfuscation techniques will be hard to come by.

After all, with the technique you described you will sacrifice to some degree meaningful IDE code assistance, which is used by a gross section of programmers.

This kind of wrapping makes things more obfuscated, and I am guessing part of the motivation to do so may actually be protection of Intellectual property, notwithstanding the slight performance impact due to the extra stack operations.

On the other hand it depends on the programming language and its idiosyncrasies: In JavaScript for instance I use such a 'pattern' for instance to pass strings by reference.

In C++ it would make sense for additional parameter, type, sanity, pointer and memory bounds testing. As such it takes a page from managed code minus the application virtual machine. Please, correct me if I am wrong.

I could see this type of wrapping being employed frequently in game engine development. Is your company by any means involved in that field?

  • Thanks for an extensive explanation! No, my company is not involved in game programming, we work in healthcare. Code obfuscation is not a reason here, because the wrapper is written by our colleagues and is not designed for hiding interface or implementation. Is there perhaps a name for this anti-pattern? Commented Nov 6, 2013 at 7:27
  • I asked because game extension / game engine developers are under high pressure, in a very competitive, very outspoken market, with program crashes not taken lightly. Isn't there much greater leniency with healthcare clients? Given your description, I would surmise obfuscation. Such wrappers you described are also used as a plugin interface, but you didn't make any mention of plugins. MyAlgorithmInput,... would then of course implement at least a common interface. Commented Nov 6, 2013 at 11:14
  • There isn't any common interface. MyAlgorithmInput is simply a container. There is no other intent behind it, but to encapsulate input/output data. Commented Nov 6, 2013 at 13:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.