Analyse de principe du modèle de visite
Présentation de la série de modèles de conception
| Modèles de conception | Billet d'avion |
|---|---|
| Trois modèles d'usine | Entrée d'embarquement |
| Mode stratégie | Entrée d'embarquement |
| Mode de délégation | Entrée d'embarquement |
| Modèle de méthode de modèle | Entrée d'embarquement |
| Mode observateur | Entrée d'embarquement |
| Mode singleton | Entrée d'embarquement |
| Mode prototype | Entrée d'embarquement |
| Modèle d'agence | Entrée d'embarquement |
| Mode décorateur | Entrée d'embarquement |
| Mode adaptateur | Entrée d'embarquement |
| Mode constructeur | Entrée d'embarquement |
| Modèle de chaîne de responsabilité | Entrée d'embarquement |
| Modèle poids mouche | Entrée d'embarquement |
| Mode combiné | Entrée d'embarquement |
| Motif de façade | Entrée d'embarquement |
| Mode pont | Entrée d'embarquement |
| Modèle intermédiaire | Entrée d'embarquement |
| Mode itérateur | Entrée d'embarquement |
| Mode état | Entrée d'embarquement |
| Mode interprète | Entrée d'embarquement |
| Mode mémo | Entrée d'embarquement |
| Mode de commande | Entrée d'embarquement |
| Mode visiteur | Entrée d'embarquement |
| Résumé de 7 principes et modèles de conception de la conception de logiciels | Entrée d'embarquement |
Préface
La série de modèles de conception ici est le dernier modèle de conception de 23 modèles de conception. Le modèle de visiteur peut également être considéré comme le modèle de conception le plus difficile parmi tous les modèles de conception. Bien sûr, nous l'utilisons rarement. L'auteur du modèle de conception évalue le modèle de visiteur comme ceci: dans la plupart des cas, vous n'avez pas besoin d'utiliser le modèle de visiteur, mais une fois que vous avez besoin de l'utiliser, vous devez vraiment l'utiliser.
Quel est le modèle de visiteur
Le modèle de visiteur (Vistor Pattern) est un modèle de conception qui sépare la structure de données et le fonctionnement des données. Il fait référence à l'encapsulation de certaines opérations qui agissent sur divers éléments dans une certaine structure de données. Il peut définir de nouvelles opérations qui agissent sur ces éléments sans changer la structure des données. Le mode visiteur est un mode comportemental.
L'idée de base du modèle de visiteur est de fournir une méthode accept () pour accepter l'objet du visiteur pour certains types fixes de structures d'objets (éléments) dans le système. Différents visiteurs ont un contenu d'accès différent au même élément, de sorte que le même ensemble d'éléments peut produire des résultats d'élément différents. La méthode accept () peut accepter différents objets visiteur, puis se transmet en interne à la méthode visit () de l'objet visiteur.
L'idée centrale du modèle de visiteur est de découpler la structure des données et le fonctionnement des données, afin que le fonctionnement de l'élément ait une excellente évolutivité. Nous pouvons implémenter différentes opérations sur le même élément en étendant différents types d'opérations de données (visiteurs).
Après avoir lu ce grand nombre de concepts théoriques, vous sentez-vous un peu étourdi? Cela semble un peu abstrait, ne vous inquiétez pas, continuez à regarder en bas:
Le moment de faire semblant est de retour: parler est bon marché, vous montrer le code , prenons un exemple pour voir comment le modèle de visiteur est écrit
Exemple de modèle de visiteur
Nous prenons comme exemple le fait que lors de la commande dans un restaurant, le client a besoin de visualiser la commande à travers le menu. Dans cet exemple, le client est le visiteur et les plats sont les informations auxquelles le visiteur doit accéder.
1. Commencez par établir une interface de plat (recette), et définissez uniquement une méthode qui accepte les visiteurs de visiter:
package com.zwx.design.pattern.visitor;
public interface IRecipe {
void accept(ICustomer customer);
}
Ensuite, nous ne listons que deux types de vidéos, un type de porc braisé et un type de légumes de saison. Donc deux classes sont nécessaires:
package com.zwx.design.pattern.visitor;
public class Meat implements IRecipe {
@Override
public void accept(ICustomer customer) {
customer.visit(this);
}
public String getPrice(){
return "88元/份";
}
}
package com.zwx.design.pattern.visitor;
public class Cabbage implements IRecipe {
@Override
public void accept(ICustomer customer) {
customer.visit(this);
}
public String getPrice(){
return "44元/份";
}
}
En plus d'implémenter la méthode accept dans ces deux classes, ils fournissent également une méthode pour vérifier le prix.
3. À ce stade, nous devons créer un visiteur abstrait:
package com.zwx.design.pattern.visitor;
public interface ICustomer {
void visit(Meat meat);
void visit(Cabbage cabbage);
}
Deux méthodes avec le même nom de méthode sont définies à l'intérieur, mais les paramètres sont différents et les paramètres correspondent aux éléments. En théorie, il y a plusieurs plats ci-dessus. Nous devons définir plusieurs méthodes, c'est-à-dire que le nombre de méthodes et le nombre d'éléments à accéder doivent être égaux.
4. Ensuite, créez un rôle visiteur spécifique pour le client A afin d'implémenter des visiteurs abstraits:
package com.zwx.design.pattern.visitor;
public class CustomerA implements ICustomer{
@Override
public void visit(Meat meat) {
System.out.println("肉类：" + meat.getPrice());
}
@Override
public void visit(Cabbage cabbage) {
System.out.println("时蔬：" + cabbage.getPrice());
}
}
Maintenant qu'il y a des visiteurs et des plats, il y a un menu de moins, car les clients doivent afficher les informations sur les plats via le menu, puis commander, nous avons donc également besoin d'une catégorie de menu pour gérer tous les plats.
5. Créez une nouvelle classe de menu:
package com.zwx.design.pattern.visitor;
import java.util.ArrayList;
import java.util.List;
public class RestaurantMenu {
private List<IRecipe> recipeList = new ArrayList<>();
public RestaurantMenu(IRecipe recipe) {
recipeList.add(recipe);
}
public void addRecipe(IRecipe recipe){
recipeList.add(recipe);
}
public void display(ICustomer customer){
for (IRecipe recipe : recipeList){
recipe.accept(customer);
}
}
}
La classe de menu conserve tous les plats dans une liste, puis affiche toutes les informations sur les plats via la méthode d'affichage.
6. Ensuite, nous créons une classe de test à tester:
package com.zwx.design.pattern.visitor;
public class TestVistor {
public static void main(String[] args) {
IRecipe recipe = new Meat();
RestaurantMenu menu = new RestaurantMenu(recipe);
menu.addRecipe(new Cabbage());
menu.display(new CustomerA());
}
}
Sortez les informations suivantes:
肉类：88元/份
时蔬：44元/份
Il s'agit d'un modèle de visiteur. Ce qui précède est dû au fait que les visiteurs doivent changer fréquemment, mais il suffit d'ajouter plus de classes de clients, ce qui est très pratique.
Si c'est la première fois que vous entrez en contact avec le modèle de visiteur, vous pouvez avoir le sentiment que l'exemple est encore un peu abstrait, alors je vous suggère d'écrire plusieurs fois contre l'exemple vous-même, et vous retrouverez progressivement le sentiment.
Rôle du visiteur
À partir de l'exemple ci-dessus, nous pouvons conclure que le modèle de visiteur a principalement 5 rôles:
- Visiteur abstrait (Vistor): interface ou classe abstraite (comme ICustomer dans l'exemple). Ce rôle est principalement de définir la méthode de visite pour des éléments spécifiques.Les paramètres sont des éléments spécifiques.En théorie, le nombre de méthodes est égal au nombre d'éléments. Par conséquent, si l'élément est instable et change souvent, le visiteur doit toujours le modifier, et il n'est pas approprié d'utiliser le mode visiteur, donc le mode visiteur convient aux scénarios où la structure de l'élément est relativement stable.
- Concrete Visitor (ConcreteVistor): pour accéder à des éléments spécifiques (comme CustomerA dans l'exemple).
- Élément abstrait (élément): interface ou classe abstraite. Définit une méthode accept (comme IRecipe dans l'exemple) pour accepter l'accès des visiteurs.
- Élément concret (ConcreteElement): Fournit une implémentation concrète pour accepter l'accès des visiteurs, généralement par visiteur.visit () (comme Chou et Viande dans l'exemple).
- Objet Structure (ObjectStruture): utilisé pour maintenir des éléments, et fournir une méthode pour accepter les visiteurs d'accéder à tous les éléments (comme le RestaurantMenu dans l'exemple).
Scénarios d'application pour le mode visiteur
Le mode visiteur convient aux scénarios suivants:
- 1. La structure de données doit être stable, mais les opérations qui agissent sur la structure de données changent souvent (par exemple, si la recette change fréquemment dans l'exemple ci-dessus, l'objet visiteur doit être modifié à chaque fois qu'il change).
- 2. Il est nécessaire d'opérer sur différents types de données (éléments) sans utiliser de branches pour déterminer des types spécifiques de scènes.
Avantages et inconvénients du mode visiteur
avantage:
- 1. La structure de données et l'opération de données sont découplées, de sorte que l'ensemble d'opérations peut être modifié indépendamment.
- 2. Le rôle de visiteur est très facile à développer.
- 3. Chaque rôle remplit ses propres fonctions et se conforme au principe de la responsabilité unique.
Désavantage - 1. Il est difficile d'augmenter le type d'élément Si le type d'élément change, le code source du visiteur doit être modifié, ce qui viole le principe d'ouverture et de fermeture et n'est pas propice à la maintenance.
- 2. Violant le principe d'inversion de dépendance, comme l'interface visiteur dans notre exemple, la méthode définie repose sur des éléments concrets plutôt que sur des éléments abstraits.
Pour résumer
Cet article présente principalement le dernier modèle de conception parmi les 23 modèles de conception du GoF, qui est également le modèle de conception le plus difficile. Il peut être appelé le BOSS ultime des modèles de conception. Un exemple est utilisé pour illustrer la manière d'écrire le modèle de visiteur, et enfin le résumé Le rôle du modèle de visiteur et ses avantages et inconvénients.
S'il vous plaît faites attention à moi et apprenez et progressez avec le loup solitaire .