La prise en compte du patron Décorateur lors de la conception d’un logiciel est payante pour plusieurs raisons. Tout d’abord, il y a le haut degré de flexibilité qui vient avec une telle structure de décorateur : tant au moment de la compilation qu’à l’exécution, les classes peuvent être étendues avec de nouveaux comportements sans héritage. Cette approche de programmation n’entraîne pas de hiérarchies d’héritage floues, ce qui améliore également la lisibilité du code du programme.
Le fait que la fonctionnalité soit répartie entre plusieurs classes de décorateurs augmente également la performance du logiciel. Ainsi, vous pouvez appeler et lancer les fonctions dont vous avez besoin pour le moment. Avec une classe de base complexe, qui fournit toutes les fonctions en permanence, cette option optimisée en termes de ressources n’est pas disponible.
Cependant, le développement selon le patron Decorator n’a pas que des avantages : avec l’introduction du modèle, la complexité du logicielaugmente automatiquement. L’interface de Decorator en particulier est généralement très verbeuse et associée à de nombreux nouveaux termes, et donc tout sauf facile d’accès pour les débutants. Un autre inconvénient est le grand nombre d’objets Decorator, pour lesquels une systématisation séparée est recommandée afin d’éviter d’être confronté à des problèmes de vue d’ensemble, similaires à ceux rencontrés lors du travail avec des sous-classes. Les chaînes d’appel souvent très longues des objets décorés (c’est-à-dire les composants logiciels étendus) rendent également plus difficile la recherche d’erreurs et donc le processus de débogage en général.