23 Modes de conception, chapitre 17: Mode de commande Java
Définition: encapsuler une demande dans un objet, vous permettant de paramétrer le client à l'aide de différentes demandes, de requêtes de file d'attente ou d'enregistrement des journaux de demande, et de fournir des fonctions de révocation et de récupération de commande.
Type: modèle de comportement
Diagramme de classe:
La structure du mode de commande
Comme son nom l'indique, le mode de commande est l'encapsulation des commandes. Tout d'abord, jetons un coup d'œil à la structure de base dans le diagramme de classe de mode de commande:
Classe de commande: est une classe abstraite qui déclare les commandes qui doivent être exécutées. D'une manière générale, une méthode d'exécution doit être publiée au public pour exécuter la commande.
Classe ConcreteCommand: la classe d'implémentation de la classe de commande, implémente les méthodes déclarées dans la classe abstraite.
Classe du client: la classe d'appels du client final.
Les fonctions des trois classes ci-dessus devraient être plus faciles à comprendre. Concentrons-nous sur la classe Invoker et la classe Recevier.
Classe d'invocateur: L'appelant est responsable de l'appel des commandes.
Classe du récepteur: Le récepteur est responsable de la réception et de l'exécution des commandes.
Pour le dire franchement, la soi-disant encapsulation des commandes n'est rien de plus que d'écrire une série d'opérations dans une méthode, puis d'être appelée par le client. Il se reflète sur le diagramme de classe. Il ne faut qu'une classe ConcreteCommand et une classe client pour terminer l'encapsulation des commandes. Même si cela va plus loin, afin d'augmenter la flexibilité, une classe de commande peut être ajoutée pour une abstraction appropriée. Quelle est la fonction de cet appelant et de cet récepteur?
En fait, vous pouvez penser sous un autre point de vue: si vous encapsulez simplement certaines opérations comme une commande pour que d'autres l'appellent, comment peut-elle être appelée un modèle? En tant que modèle comportemental, le mode de commande doit d'abord atteindre un faible couplage. Ce n'est que lorsque le degré de couplage est faible que la flexibilité peut être amélioré. Le but d'ajouter les rôles de l'appelant et du récepteur est précisément pour cela. Le code général du mode de commande est le suivant:
Class Invoker {Commande privée; public void setCommand (Command Command) {this.command = Command; } public void action () {this.command.execute (); }} Résumé CLASS COMMAND {public abstract void execute (); } classe ConcreteCommand étend la commande {récepteur privé récepteur; public ConcreteCommand (récepteur récepteur) {this.receiver = récepteur; } public void execute () {this.receiver.dosomething (); }} Class Receiver {public void DoSomething () {System.out.println ("Traitement de logique du bénéficiaire-business"); }} public class Client {public static void main (String [] args) {receiver receiver = new récepteur (); Command Command = new ConcreteCommand (récepteur); // Le client exécute directement la méthode de commande spécifique (cette méthode est cohérente avec le diagramme de classe) Command.ExECUTE (); // Le client exécute la commande via l'appelant invoker invoker = new invoker (); invoker.setCommand (commande); invoker.action (); }}Grâce au code, nous pouvons voir que lorsque nous appelons, le synchronisation d'exécution est d'abord la classe de l'appelant, puis la classe de commande et enfin la classe du 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 en classe. C'est l'essence du modèle de commande: séparez l'appelant de la commande et de l'exécuteur pour que les deux parties n'aient pas à se soucier du fonctionnement de l'autre partie.
Avantages et inconvénients du mode de commande
Tout d'abord, le mode de commande est une encapsulation très: chaque commande est encapsulée, et pour le client, la commande correspondante est appelée autant que la fonction est nécessaire sans savoir comment la commande est exécutée. Par exemple, il existe un ensemble de commandes de fonctionnement du fichier: créer un nouveau fichier, copier un fichier et supprimer un fichier. Si ces trois opérations sont encapsulées dans une classe de commande, le client doit seulement savoir qu'il existe ces trois classes de commande. Quant à la logique encapsulée dans la classe de commande, le client n'a pas besoin de savoir.
Deuxièmement, le mode de commande a une bonne évolutivité. En mode commande, l'encapsulation la plus élémentaire des opérations dans la classe du récepteur et l'encapsulation secondaire de la classe de commande de ces opérations de base. Lors de l'ajout de nouvelles commandes, l'écriture de la classe de commande n'est généralement pas à partir de zéro. Il existe un grand nombre de classes de récepteurs pour l'appel, et il existe également un grand nombre de classes de commande pour l'appel, et le code est très réutilisable. Par exemple, dans le fonctionnement d'un fichier, nous devons ajouter une commande pour couper un fichier, et nous n'avons qu'à combiner les deux commandes de copie d'un fichier et de supprimer un fichier, ce qui est très pratique.
Enfin, parlons des inconvénients du mode de commande, c'est-à-dire s'il y a beaucoup de commandes, ce sera un mal de tête à développer. En particulier, de nombreuses commandes simples ne sont que quelques lignes de code à implémenter. Si vous utilisez le mode de commande, vous n'avez pas à vous soucier de la simplicité de la commande, vous devez écrire une classe de commande pour le résumer.
Scénarios applicables pour le mode de commande
Pour la plupart des fonctions de mode de demande de réponse, il est plus approprié d'utiliser le mode de commande. Comme le dit la définition du mode de commande, le mode de commande est plus pratique pour implémenter des fonctions telles que la journalisation et les opérations de secours.
Résumer
Le fait d'utiliser le mode dans une occasion est une question très emmêlée pour tous les développeurs. Parfois, en raison de la prévision de certains changements dans les exigences, un certain modèle de conception est utilisé pour la flexibilité et l'évolutivité du système, mais cette exigence prévisible ne le fait pas. Au contraire, de nombreuses exigences imprévisibles sont venues, ce qui a entraîné le modèle de conception utilisé en jouant le rôle opposé lors de la modification du code, de sorte que toute l'équipe du projet se plaint. Je crois que chaque programmeur a eu un tel exemple. Par conséquent, sur la base du principe du développement agile, lorsque nous concevons des programmes, si nous pouvons les résoudre bien sans utiliser un certain modèle en fonction des besoins actuels, nous ne devons pas l'introduire, car il n'est pas difficile d'introduire un modèle de conception. Nous pouvons le faire sur le système lorsque nous en avons vraiment besoin pour l'utiliser et introduire ce modèle de conception.
Prenez le mode de commande comme exemple. Dans notre développement, la fonction de mode de demande-réponse est très courante. D'une manière générale, nous résumerons l'opération de réponse à la demande dans une méthode. Cette méthode encapsulée peut être appelée une commande, mais pas un mode de commande. La question de savoir si cette conception doit être augmentée à la hauteur du motif doit être considérée séparément, car si le mode de commande est utilisé, les deux rôles de l'appelant et du récepteur doivent être introduits. La logique placée à l'origine en un seul endroit est dispersée en trois catégories. Lors de la conception, il est nécessaire de déterminer si ce coût en vaut la peine.
Ce qui précède est tout le contenu de cet article. J'espère que cela sera utile à l'apprentissage de tous et j'espère que tout le monde soutiendra davantage Wulin.com.