How can you effectively implement the Strategy pattern in C++?

Strategy is one of the most practical design patterns that puts worth mostly on separation of concerns. Shortly, it injects the implementation details from outside into the context. These details might be another abstraction hierarchy or be in the form of series of overloaded free function wrapped in an object. This flexibility gets completed when it is combined with the static polymorphism and reduces the runtime overhead caused by runtime indirections.

To implement the Strategy pattern in C++, define an interface representing the strategy with a virtual method. Create concrete classes implementing this interface, each encapsulating a specific behavior. In the client code, instantiate a strategy object and invoke its method through a pointer/reference, allowing dynamic behavior changes at runtime without altering client code

The big advantage of the Strategy is that it decouples a verb (method) in an inheritance tree from the nouns (objects themselves). After the algorithm has been abstracted away, then it can be used in other classes as well. Similarly, we can dynamically assign a behavior to an object at run-time rather than at compile time.

Le C++ est un langage de programmation qui implémente tous les principes de la Programmation Orientée Objet (POO). Dérivé du C, il est performant et proche du matériel. Par contre, légèrement plus complexe à maitriser, notamment du fait de la gestion de la mémoire et des ressources. Car le développeur doit l'implémenter. Alors que pour d'autres, c'est censé être automatique. Sans forcément de garantie de fonctionnement et de fiabilité.

There are two ways to implement the strategy pattern: (1) Where strategies are classes derived from a base interface-like class. (2) Where strategies are defined using the Curiously Recurring Template Pattern (CRTP). The first is great for being able to specify configurable behavior at run-time. The latter is great if you are providing configurable behavior at compile-time and want to avoid virtual call overhead.

Consider a video game that has many elements on the screen which the user will attempt to shoot. Each element moves in a different way: some float like a balloon, some sink due to gravity, some slow due to wind resistance, and some move erratically. The simple design is to have a move() virtual method in the Target base class which each element overwrites. We can decouple the movement code from the Target by creating a Move class (abstract strategy) representing how a target moves. This will have several derived classes (concrete strategy) such as Inertia, Gravity, Buoyancy, and Chaos. Now the Target has a member variable which points to one of the Move objects.

/********************************************* * Move * The logic for how to move the target *********************************************/ class Move { public: virtual void advance(Target & target) = 0; }; /********************************************* * INERTIA * How to advance with only inertia *********************************************/ class Inertia: public Move { public: void advance(Target& target); }; <snip> Floater::Floater() : Target() { // set the advance logic a = new Inertia; }

On pense que le C++ est difficile à ma?triser. En fait ce n'est pas forcément vrai. De surcroit, il y a quelques outils de type RAD dont C++ Builder d'Embarcadero qui permettent une conception d'interface riche et de se concentrer sur le code fonctionnel. En exploitant toutes les capacités que propose le C++.