Le pattern Stratégie nous a enseigné les bienfaits de la composition en programmation objet. Lorsqu'il s'agit d'étendre les fonctionnalités d'une classe dont on ne possède pas le code, ou à l'exécution, une autre forme de composition peut entrer en jeu : le pattern Décorateur.

Reprenons la conception de notre Wargame fictif en Java et résumons la situation. Nous programmons avec le paradigme objet. Tout le monde s'accorde pour dire que la programmation objet est souple, et permet la réutilisation de code. Cependant le mois dernier, nous avons constaté qu'une importante hiérarchie de classes non seulement ne permet qu'une réutilisation de code médiocre voire nulle, mais conduit à de véritables cauchemars lorsqu'il s'agit de faire évoluer le code. Bien que l'héritage soit au centre de la programmation objet, son emploi excessif apparaît pénalisant, paradoxalement. Nous avons constaté grâce au Design Pattern Stratégie que la composition est une alternative beaucoup plus souple. Aujourd'hui nous étudions une autre façon de composer les objets: le Design Pattern Décorateur