Exemple d'explication du modèle de commande dans les modèles de conception Java

Le modèle de commande est l'encapsulation des commandes. La structure de base du diagramme de classes de modèle de commande est présentée ci-dessous. Les amis qui sont intéressés par les connaissances liées aux modèles de conception Java devraient y jeter un œil. >Définition : Encapsule une requête dans un objet, vous permettant de paramétrer le client avec différentes requêtes, de mettre en file d'attente des requêtes ou d'enregistrer des journaux de requêtes, et de fournir des fonctions d'annulation et de récupération de commandes.

Type : Modèle de classe comportementale

Diagramme de classes :

Structure du modèle de commande Comme son nom l'indique, le modèle de commande est une encapsulation de commandes. Tout d'abord, jetons un coup d'œil à la structure de base du diagramme de classes de modèle de commande :

 Classe de commande : C'est une classe abstraite, la classe déclare la commande qui doit être exécutée. De manière générale, une méthode d'exécution doit être publiée pour exécuter la commande.
Classe ConcreteCommand : La classe d'implémentation de la classe Command, qui implémente les méthodes déclarées dans la classe abstraite.
 Classe client : La classe d'appel du client final.
Les fonctions des trois classes ci-dessus devraient être relativement faciles à comprendre. Concentrons-nous sur la classe Invoker et la classe Recevier.

Classe Invoker : appelant, responsable de l'appel des commandes.
Classe Récepteur : Récepteur, responsable de la réception des commandes et de leur exécution.
La soi-disant encapsulation des commandes, pour parler franchement, n'est rien de plus que d'écrire une série d'opérations dans une méthode puis de l'appeler par le client pour la refléter sur le. diagramme de classes, seules une classe ConcreteCommand et une classe Client peuvent compléter l'encapsulation des commandes. Encore plus loin, afin d'augmenter la flexibilité, vous pouvez ajouter une classe Command pour une abstraction appropriée. Quelles sont les fonctions de cet appelant et de ce récepteur ?

En fait, vous pouvez y penser sous un autre angle : si vous encapsulez simplement certaines opérations sous forme de commande que d'autres peuvent appeler, comment peut-on l'appeler un modèle ? En tant que modèle comportemental, le modèle de commande doit d'abord atteindre un faible couplage peut améliorer la flexibilité, et le but de l'ajout des deux rôles d'appelant et de récepteur est précisément dans ce but. Le

code général pour le mode commande est le suivant :

On peut voir à travers le code que lorsque l'on appelle, la séquence d'exécution est d'abord la classe appelante , puis la classe de commande et enfin la classe de récepteur. En d'autres termes, l'exécution d'une commande est divisée en trois étapes, et son degré de couplage est bien inférieur à l'encapsulation de toutes les opérations dans une classe. C'est l'essence du modèle de commande : l'appelant de la commande est séparé de l'exécuteur. les deux parties n’ont pas à se soucier de la façon dont l’autre partie fonctionne.

class Invoker { 
 private Command command; 
 public void setCommand(Command command) { 
  this.command = command; 
 } 
 public void action(){ 
  this.command.execute(); 
 } 
} 
abstract class Command { 
 public abstract void execute(); 
} 
class ConcreteCommand extends Command { 
 private Receiver receiver; 
 public ConcreteCommand(Receiver receiver){ 
  this.receiver = receiver; 
 } 
 public void execute() { 
  this.receiver.doSomething(); 
 } 
} 
class Receiver { 
 public void doSomething(){ 
  System.out.println("接受者-业务逻辑处理"); 
 } 
} 
public class Client { 
 public static void main(String[] args){ 
  Receiver receiver = new Receiver(); 
  Command command = new ConcreteCommand(receiver); 
  //客户端直接执行具体命令方式（此方式与类图相符） 
  command.execute(); 
 
  //客户端通过调用者来执行命令 
  Invoker invoker = new Invoker(); 
  invoker.setCommand(command); 
  invoker.action(); 
 } 
}

Avantages et inconvénients du mode commande Tout d'abord, le mode commande a une bonne encapsulation : chaque commande est encapsulée pour. le client, il peut appeler la commande correspondante s'il a besoin d'une fonction sans savoir comment la commande est exécutée. Par exemple, il existe un ensemble de commandes d'opération sur les fichiers : créer de nouveaux fichiers, copier des fichiers et supprimer des fichiers. Si ces trois opérations sont encapsulées dans une classe de commandes, le client a seulement besoin de savoir qu'il existe ces trois classes de commandes. Quant à la logique encapsulée dans la classe de commandes, le client n'a pas besoin de le savoir.

Deuxièmement, l'évolutivité du mode commande est très bonne. Dans le mode commande, les opérations les plus basiques sont généralement encapsulées dans la classe récepteur, et la classe commande effectue une encapsulation secondaire de ces opérations de base lors de l'ajout d'un. nouvelle commande, l'écriture de la classe de commande ne part généralement pas de zéro. Il existe un grand nombre de classes de récepteurs à appeler et un grand nombre de classes de commandes à appeler. La réutilisabilité du code est très bonne. Par exemple, si nous devons ajouter une commande pour couper des fichiers lors des opérations sur les fichiers, il suffit de combiner les deux commandes de copie de fichiers et de suppression de fichiers, ce qui est très pratique.

Enfin, parlons des défauts du mode commande, c'est-à-dire que s'il y a beaucoup de commandes, le développement sera un casse-tête. En particulier, de nombreuses commandes simples peuvent être implémentées avec seulement quelques lignes de code. Si vous utilisez le mode commande, quelle que soit la simplicité de la commande, vous devez écrire une classe de commande pour l'encapsuler.

Scénarios applicables du mode commande Pour la plupart des fonctions du mode demande-réponse, il est plus approprié d'utiliser le mode commande, il suffit like command Comme le dit la définition du mode, le mode commande est plus pratique pour implémenter des fonctions telles que la journalisation et l'annulation d'opérations.

Résumé

En fin de compte, c'est une question très complexe pour tous les développeurs. Parfois, parce que certains changements dans la demande sont prévus, un certain modèle de conception est utilisé pour la flexibilité et l'évolutivité du système, mais la demande prévue ne se produit pas. Au contraire, la demande imprévue survient assez souvent lors de la modification du code. les modèles de conception utilisés ont eu l’effet inverse, provoquant des plaintes de toute l’équipe du projet. Je crois que tous les programmeurs ont rencontré un tel exemple. Par conséquent, sur la base des principes du développement agile, lorsque nous concevons un programme, s'il peut être bien résolu sans utiliser un certain modèle en fonction des besoins actuels, alors nous ne devrions pas l'introduire, car il n'est pas difficile d'introduire un modèle de conception. , nous pouvons réorganiser le système et introduire ce modèle de conception lorsque nous en avons vraiment besoin.

Prenons l'exemple du mode commande. Dans notre développement, la fonction du mode requête-réponse est très courante. De manière générale, nous encapsulerons l'opération de réponse à la requête dans une méthode d'encapsulation. peuvent être appelés commandes, mais ce ne sont pas des modèles de commandes. La question de savoir si cette conception doit ou non être élevée au niveau d'un modèle doit être considérée séparément, car si le modèle de commande est utilisé, les deux rôles d'appelant et de destinataire seront introduits et la logique initialement placée au même endroit sera dispersée. en trois classes, lors de la conception, il faut se demander si le coût en vaut la peine.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!