Decorator Design Pattern

Classiquement, le design pattern decorator offert la possibilité d'ajouter un comportement aux classes existantes de manière dynamique. Il est utilisé pour envelopper une classe existante. Il peut être utilisé pour modifier fortement le code sous-jacent d'une classe. Une raison commune pour laquelle les développeurs l'utilise réside dans le fait que certaines applications peuvent contenir des fonctionnalités nécessitant une grande quantité de types distincts d'objets. Imaginez avoir à définir des centaines de constructeurs d'objets différents on prend l'exemple d'un jeu JavaScript.

Les constructeurs d'objets pourraient représenter des types de joueurs distincts, chacun avec des capacités différentes. Un jeu Lord of the Rings pourrait nécessiter des constructeurs pour Hobbit, Elf, Orc, Wizard, Mountain Giant, Stone Giant et ainsi de suite, mais il pourrait y en avoir facilement des centaines.

Le design decorator n'est pas fortement lié à la façon dont les objets sont créés, mais se concentre plutôt sur le problème de l'extension de leurs fonctionnalités. Plutôt que de compter sur l'héritage prototypique, nous travaillons avec un seul objet de base et ajoutons progressivement des objets décoratifs qui fournissent les capacités supplémentaires. L'idée est que plutôt d'utiliser les sous-classe, nous ajoutons (décorer) des propriétés ou des méthodes à un objet de base, ce qui est un peu plus simplifié.

Pour ceux qui sont familier avec le framework AngularJS, la notion de decorator existe, ainsi nous pouvons décorer un service, factory, provider et même une value, ainsi nous pouvons étendre le fonctionnement d'une méthode ou bien variable, voici un exemple qui explique comment :

Les développeurs utilisent ce modèle car il est flexible et peut être utilisé de manière transparente, comme nous l'avons vu, ce qui permet à nos objets d'être "emballés" ou "décorés" avec de nouveaux comportements et ensuite continuer à être utilisés sans avoir à se soucier de l'objet de base en cours de modification. Dans un contexte plus large, le modèle nous évite également de compter sur un grand nombre de sous-classes pour obtenir les mêmes avantages.
Néanmoins ce pattern possède également des inconvénients dont nous devrions être conscients lors de la mise en œuvre du modèle. Si il est mal géré, il peut compliquer considérablement notre architecture d'application car il introduit beaucoup d'objets petits, mais similaires dans notre espace de noms. En plus de devenir difficile à gérer, d'autres développeurs qui ne connaissent pas le modèle peuvent avoir de la difficulté à comprendre pourquoi il est utilisé.

Pages

La joie du code