Dans le modèle Decorator, vous êtes censé envelopper les décorateurs autour d'un ConcreteComponent central. Mais d'après ce que je peux voir en regardant le diagramme de classes ( de Wikipedia ), c'est que rien m'empêche d'utiliser un ConcreteDecorator comme élément central. Et ce n'est évidemment pas génial, car son implémentation de operation () contient très probablement component.operation () . Est-ce que je rate quelque chose ici? Y a-t-il un garde que je ne vois pas qui s'assure que l'élément central qui est décoré est un ConcreteComponent?
3 Réponses :
Vous n'avez pas besoin d'un tel chèque. De plus, non seulement vous n'en avez pas besoin, mais vous ne devriez vraiment pas en avoir. En avoir un brisera l'abstraction.
Au lieu de cela, vous pouvez avoir des restrictions plus simples - un décorateur ne peut pas être créé sans quelque chose à décorer. C'est-à-dire qu'il n'a pas de constructeur sans argument, et vous vérifiez en quelque sorte que le composant sa décoration n'est pas nul. De cette façon, un décorateur doit décorer quelque chose, que ce soit un composant en béton ou un autre décorateur. Ce décorateur, à son tour, doit également décorer quelque chose, et ainsi de suite, jusqu'à ce que vous atteigniez un composant qui peut être créé à partir de rien, sans aucun autre composant nécessaire.
Il y a probablement plusieurs façons, mais je m'attendrais à ce que le Decorator ait un code comme celui-ci
abstract class Decorator implements Component {
protected final Component decorated;
protected Decorator(Component comp) {
if (comp == null) {
throw new IllegalArgumentException("must have decoration target");
}
decorated = comp;
}
}
Alternativement, si par exemple. le Decorator est une interface , vous pouvez simplement affirmer que le fait d'avoir un décorateur valide est une condition préalable pour que operation () fonctionne.
Vous pouvez utiliser votre ConcreteDecorator comme élément central. L'idée n'est pas de vous empêcher d'utiliser cela, mais de vous donner la flexibilité d'avoir plusieurs décorateurs et votre client peut les traiter de manière uniforme.
Fondamentalement, le type de votre variable doit être le décorateur (l'abstraction) et votre dépendance d'exécution peut être n'importe quelle sous-classe de cette abstraction que vous aimez. Le concept est de découpler le détail de l'implémentation de l'abstraction. Vous pouvez donc attacher différents décorateurs au moment de l'exécution et modifier le comportement ou ajouter un état. Le pouvoir d'utiliser l'abstraction et non la concrétion est que vous pouvez changer la concrétion au moment de l'exécution tant que votre type de variable est le décorateur (l'abstraction)