Si vous avez besoin d'écrire un code facile à maintenir et si vous avez besoin de modifier dynamiquement le comportement de vos objets, appliquer le Design Pattern Stratégie, c'est employer la bonne tactique.

Avez-vous eu l'occasion de feuilleter des ouvrages d'initiation à la programmation objet ? Si oui, sans doute avez vous lu qu'une des forces de la programmation objet est quelle permet la réutilisation de code, grâce à l'héritage et au polymorphisme. Et sans doute l'auteur appuie-t-il sa démonstration avec le fameux exemple de la hiérarchie de classes encapsulant diverses formes géométriques. Au sommet de la hiérarchie, une classe plus ou moins abstraite, "Forme", d'où dérivent les sempiternelles classes carré, triangle, cercle, etc. Il est indéniable qu'héritage et polymorphisme sont une grande force de la programmation orientée objet (POO) en effet. Mais c'est une faute de penser la programmation objet uniquement en ces termes. L'expérience acquise par les développeurs spécialistes en POO montre qu'au contraire, de grosses hiérarchies deviennent pénalisantes. Elles permettent une réutilisation du code très médiocre, et sont difficiles à maintenir et surtout à modifier en raison du couplage fort qu'elles engendrent. Pour pallier à ces inconvénients sans perdre les avantages de la POO les développeurs ont défini le pattern Stratégie. Nous allons en examiner le bien fondé en reprenant l'exemple du Wargame dernier cri qui nous a servi de point de départ pour discuter du pattern Observateur le mois dernier. Nous employons à nouveau Java, langage académique bien adapté à l'illustration de notre propos, mais tout langage orienté objet permet d'appliquer le pattern Stratégie.