Modèle de stratégie V/S modèle de décorateur
Je viens de tomber sur deux modèles.
Modèle de stratégie
Décorateur
Modèle de stratégie: -
Modèle de stratégie donne plusieurs algorithmes qui peuvent être utilisés pour effectuer opération ou tâche particulière.
Motif Décorateur: -
Le motif Decorator ajoute des fonctionnalités au composant.
En fait, j’ai trouvé que Strategy Pattern et Decorator Pattern peuvent également être utilisés de manière interchangeable.
Voici le lien: - Quand et comment appliquer un motif de stratégie au lieu d’un motif de décorateur?
Quelle est la différence entre le modèle de stratégie et le modèle de décorateur?
quand faut-il utiliser le motif stratégique et quand faut-il utiliser le motif décorateur?
Expliquez la différence entre les deux avec le même exemple.
Le modèle de stratégie vous permet de changer la mise en œuvre de quelque chose utilisé au moment de l'exécution.
Le modèle de décorateur vous permet d’augmenter (ou d’ajouter) des fonctionnalités existantes avec des fonctionnalités supplémentaires au moment de l’exécution.
La principale différence réside dans le changement devs augment
Dans l'une des questions que vous avez liées, vous indiquez également qu'avec le modèle de stratégie, le consommateur est conscient que les différentes options existent, alors qu'avec le modèle de décorateur, le consommateur ne serait pas au courant des fonctionnalités supplémentaires.
Par exemple, imaginez que vous écrivez quelque chose pour trier une collection d'éléments. Ainsi, si vous écrivez une interface ISortingStrategy, vous pouvez ensuite mettre en œuvre plusieurs stratégies de tri différentes BubbleSortStrategy, QuickSortStrategy, RadixSortStrategy, puis votre application, en fonction de certains critères de la liste existante, choisit la stratégie la plus appropriée pour trier la liste. Ainsi, par exemple, si la liste contient moins de 10 éléments, nous utiliserons RadixSortStrategy, si moins de 10 éléments ont été ajoutés à la liste depuis le dernier tri, nous utiliserons BubbleSortStrategy, sinon nous utiliserons QuickSortStrategy.
Nous sommes en train de changer le type de tri au moment de l'exécution (pour être plus efficace en fonction d'informations supplémentaires), il s'agit du modèle de stratégie.
Imaginons maintenant que quelqu'un nous demande de fournir un journal indiquant la fréquence à laquelle chaque algorithme de tri est utilisé pour effectuer un tri réel et pour limiter le tri aux utilisateurs administrateurs. Nous pouvons ajouter ces deux fonctionnalités en créant un décorateur qui améliore any ISortingStrategy. Nous pourrions créer un décorateur qui consignera qu’il a été utilisé pour trier quelque chose et le type de stratégie de tri décoré. Et nous pourrions ajouter un autre décorateur qui a vérifié si l'utilisateur actuel était un administrateur avant d'appeler la stratégie de tri décoré.
Ici, nous ajoutons de nouvelles fonctionnalités à toute stratégie de tri en utilisant le décorateur, mais n'échangeons pas la fonctionnalité de tri principale (nous avons utilisé les différentes stratégies pour changer cela).
Voici un exemple de l'apparence des décorateurs:
public interface ISortingStrategy
{
void Sort(IList<int> listToSort);
}
public class LoggingDecorator : ISortingStrategy
{
private ISortingStrategy decorated;
public LoggingDecorator(ISortingStrategy decorated)
{
this.decorated=decorated;
}
void Sort(IList<int> listToSort)
{
Log("sorting using the strategy: " + decorated.ToString();
decorated.Sort(listToSort);
}
}
public class AuthorisingDecorator : ISortingStrategy
{
private ISortingStrategy decorated;
public AuthorisingDecorator(ISortingStrategy decorated)
{
this.decorated=decorated;
}
void Sort(IList<int> listToSort)
{
if (CurrentUserIsAdministrator())
{
decorated.Sort(listToSort);
}
else
{
throw new UserNotAuthorizedException("Only administrators are allowed to sort");
}
}
}
- Définit une famille d'algorithmes,
- Encapsule chaque algorithme, et
- Rend les algorithmes interchangeables au sein de cette famille.
Utilisez un modèle de stratégie lorsque vous devez modifier dynamiquement l'algorithme au moment de l'exécution.
Le motif Decorator modifie de manière dynamique la fonctionnalité d'un objet au moment de l'exécution sans affecter la fonctionnalité existante de ces objets.
Quand utiliser:
- Ajouter dynamiquement des fonctionnalités/responsabilités supplémentaires
- Supprimer les fonctionnalités/responsabilités de manière dynamique
- Évitez trop de sous-classes pour ajouter des responsabilités supplémentaires.
Désavantages:
- Utilisation abusive du principe Open Closed (Ouvert pour extension et Fermé pour modification). Utilisez cette fonctionnalité avec parcimonie là où le code est le moins susceptible d’être modifié.
- Trop de petites classes et va ajouter des frais de maintenance.
Différence clé:
Stratégie vous permet de modifier les entrailles d'un objet. Decorator vous permet de changer la peau.
Quelques messages plus utiles:
Quand utiliser le motif de décorateur?
Exemple concret du modèle de stratégie
stratégie par sourcemaking
La stratégie est que le modèle est utilisé pour "encapsuler ce qui change". Il vous permet de définir des algorithmes pouvant être interchangés lors de l'exécution. Par exemple (exemple tiré de Head First Design Patterns):
Disons que vous avez un simulateur de canard. Vous voulez faire voler vos objets de canard. Vous pouvez utiliser l'héritage pour cela, mais cela devient vite compliqué. Certains canards ne peuvent pas voler (par exemple, les canards en caoutchouc). Pour ce faire, il faut encapsuler ce qui change, par exemple le comportement de la mouche, dans sa propre classe qui implémente IFlybehaviour, par exemple. Vous pouvez ensuite utiliser la composition au lieu de l'héritage et injecter le comportement IFly dans vos objets canard. Vous pouvez également avoir une méthode qui définit ce comportement de volée afin que le comportement de volée puisse être modifié au moment de l'exécution. C'est essentiellement le modèle de stratégie.
Le motif de décorateur est utilisé pour ajouter des fonctionnalités à un objet lors de l'exécution. Il vous permet d’envelopper des objets dans des objets. Les décorateurs doivent avoir le même super-type que les objets qu’ils décorent. Cela vous permet d'appeler une méthode sur "l'emballage le plus à l'extérieur" et vous pouvez ensuite appeler en chaîne cette même méthode à travers les couches de décorateurs. C'est fondamentalement une approche plus flexible que le sous-classement.
Quant à ceux que vous choisissez dépend du problème que vous souhaitez résoudre. Voulez-vous avoir une famille d'algorthims interchangeables au moment de l'exécution ou souhaitez-vous ajouter de manière dynamique plus de fonctionnalités à un objet au moment de l'exécution?
Le livre "Head first design patterns" explique cela très bien (probablement bien mieux que moi) à l’OMI, cela vaut donc la peine d’être lu, si vous avez la chance.
Bonne chance.
Cela se résume à ceci: utilisez Stratégie pour choisir un élément de fonctionnalité de base. Utilisez Decorator pour ajouter des fonctionnalités supplémentaires. La stratégie est le gâteau que nous préparons et Decorator est toute la jolie décoration que nous y ajoutons.
La stratégie consiste à choisir un algorithme.
Collections.sort(list, comparator); // comparator is the strategy
Le décorateur enveloppe un objet tout en conservant le même type.
in = new BufferedInputStream(in);
Decorator consiste à ajouter des fonctionnalités supplémentaires à une instance d'une classe afin qu'elle soit implémentée de manière dynamique au moment de l'exécution. Il s'agit d'un modèle d'extensions de comportement. En raison des conditions pratiques dans lesquelles le sous-classement est en train de casser. Strategy est un modèle dans lequel différents objets de stratégie partagent la même fonction abstraite. L'objet de contexte concret peut être configuré au moment de l'exécution avec l'objet de stratégie concret d'un ensemble de familles. , la vue restreint la structure des données de sortie, tandis que les contrôleurs seront différents au moment de l’exécution, ce qui modifiera dynamiquement les données de sortie de la vue.