Unlocking flexibility and reusability in C++ with policy-based design

In C++ library development, there are instances where problems require manipulating and combining many unique behaviors.

For example, in discrete space simulations, developers often need to consider performance. They must manage both the details of the matrix representation (e.g., dense, sparse) that affect space complexity and the algorithms that affect runtime performance.

Additionally, if the developer needs to implement simulator activity logging (what information to log, when, and how), this adds a new set of behaviors that may or may not interact with the matrix behaviors.

A naïve implementation could look like:

You can test the code on Compiler Explorer: https://godbolt.org/z/6MKa7vdKr

One code: numerous challenges

The most important one is that it does not respect the Open-Closed Principle. If a new type of matrix representation is needed, the developer would have to modify the existing code to accommodate it. This is undesirable: code should be open to extension but closed to modification.

A second problem is that choice resolution happens at runtime, even if the decisions about which matrix and logging methods to use are made before compiling the program. This is suboptimal because the compiler cannot optimize the code as effectively without this information.

A third problem is the scalability of this approach: long switch statements with several levels of indentation reduce readability. This is just the tip of the iceberg: if multiple sets of behaviors must interact, it leads to combinatorial explosion. For instance, with 3 different sets of behaviors (matrix representation, logging, and the type of data in the matrix), each with just 2 options, there are already 2^3=8 cases to manage, and it jumps to 27 if a third option is added. This complexity is undesirable.

That’s where Policy-Based Design shines, offering a lifeline.

It allows us to create adaptable software components by separating orthogonal behaviors or strategies into distinct policy classes, adhering to the Single Responsibility Principle. Clients can mix and match these policies to inject customized behaviors without altering the core implementation, aligning perfectly with the Open-Closed Principle:

Test the code on compiler explorer : https://godbolt.org/z/3PTb4bf7T

As we can see, Policy-Based Design essentially acts as a compile-time version of the Strategy Pattern, offering advantages such as leveraging type information for safety checks and optimizations, and overcoming limitations like covariant return types.

Although design choices often depend on personal style, project specifications, and time constraints, I personally enjoy using this design or one of its many flavors in my C++ projects. I appreciate its type safety and the simplicity and testability of each component.

So think about it, and maybe in your next project, give yourself permission to embrace Policy-Based Design and unlock a world of compile-time flexibility and adaptability!

Happy coding!