Bonjour à tous, membres du Forum !
J’ai parfaitement (il me semble) compris le schéma
Command
et je veux essayer d’en parler « avec mes propres mots ».
Sur la base de Wikipédia, nous pouvons découvrir que son objectif est
de créer une structure dans laquelle la classe émettrice et la classe réceptrice ne dépendent pas directement l'une de l'autre. Organiser un rappel vers une classe qui inclut la classe expéditeur . En principe, c'est écrit clairement et correctement, mais c'est en théorie. Comment faire cela ? C'est là que les problèmes commencent, parce que... la description n'est plus aussi claire et évidente. Par conséquent, je l'ai compris, j'ai décidé de vous dire comment je l'ai compris, peut-être que cela sera utile à quelqu'un : sur la base de la description du but de ce modèle, je vais combiner la description avec le code pour le rendre plus clair, parce que dans le même Wikipédia, ils l'ont généralisé pour de nombreuses langues et donc la description est séparée de l'exemple. Il y a quatre termes dans ce modèle, prenons-les pour acquis pour l'instant : commandes(
command
), récepteur de commandes(
receiver
), appelant de commande(
invoker
) et client(
client
). Je vais prendre un exemple sur le même Wikipédia, c'est tout à fait tolérable.
La tâche est une classe
Light
qui peut faire deux choses : allumer la lumière et l'éteindre. En termes de modèle, ce sera « récepteur de commandes (
receiver
) »
public class Light{
public Light(){ }
public void turnOn(){
System.out.println("The light is on");
}
public void turnOff(){
System.out.println("The light is off");
}
}
Créons une interface avec une méthode
execute()
qui s'exécutera et qui est appelée en termes de modèle "command (
command
)"
public interface Command{
void execute();
}
Il est nécessaire d'encapsuler l'exécution des compétences en classe
Light
. Pour ce faire, nous allons créer des classes
TurnOnLightCommand
qui
TurnOffLightCommand
implémentent l'interface
Command
et qui accepteront un objet classe dans le constructeur
Light
. Et chacun d’eux n’effectuera qu’une seule action. L'un appellera la méthode
turnOn()
et l'autre appellera
turnOff()
.
public class TurnOnLightCommand implements Command{
private Light theLight;
public TurnOnLightCommand(Light light){
this.theLight=light;
}
public void execute(){
theLight.turnOn();
}
}
public class TurnOffLightCommand implements Command{
private Light theLight;
public TurnOffLightCommand(Light light){
this.theLight=light;
}
public void execute(){
theLight.turnOff();
}
}
Il est maintenant temps de créer un objet qui accepte ces méthodes d'objet encapsulées
Light
. En termes de modèle, on l'appelle l'appelant de commande (invoker). Appelons-le
Switch
et laissons-le accepter les variables dans le constructeur
Command
qui seront utilisées dans les méthodes créées
flipUp()
et
flipDown()
.
public class Switch {
private Command flipUpCommand;
private Command flipDownCommand;
public Switch(Command flipUpCommand,Command flipDownCommand){
this.flipUpCommand=flipUpCommand;
this.flipDownCommand=flipDownCommand;
}
public void flipUp(){
flipUpCommand.execute();
}
public void flipDown(){
flipDownCommand.execute();
}
}
Et bien sûr, nous créerons une classe qui les utilisera pour comprendre ce qui se passe en général. On l'appellera la méthode principale, dans laquelle toute l'action se déroulera :
public class TestCommand{
public static void main(String[] args){
Light l=new Light();
Command switchUp=new TurnOnLightCommand(l);
Command switchDown=new TurnOffLightCommand(l);
Switch s=new Switch(switchUp,switchDown);
s.flipUp();
s.flipDown();
}
}
Le résultat sera le suivant :
"The light is on"
"The light is off"
Où est-ce appliqué ?
Le but est clair : quoi et pourquoi cela est nécessaire, à savoir : dans une situation où vous devez séparer une exécution spécifique, c'est très pratique. De sorte que l'utilisation de certaines fonctions ne dépend pas d'une implémentation spécifique et peut être modifiée sans endommager le système. quelque chose comme ça...) Écrivez vos commentaires, discutons-en, peut-être que quelque chose peut être rendu plus simple et mieux raconté, nous modifierons tout si nécessaire) Pour que pour ceux qui liront pour la première fois, ce soit le plus clair possible. Eh bien, celui qui aime l'article met un «+» dessus :) C'est important pour moi) Au fil du temps, je veux écrire davantage sur
Builder
,
Singleton
et d'autres.
Voir aussi mes autres articles :
GO TO FULL VERSION