23 modos de design, capítulo 17: modo de comando java
Definição: encapsular uma solicitação em um objeto, permitindo que você parametrize o cliente usando diferentes solicitações, solicitações de fila ou logs de solicitação de registro e forneça funções de revogação e recuperação de comando.
Tipo: padrão comportamental
Diagrama de classe:
A estrutura do modo de comando
Como o nome sugere, o modo de comando é o encapsulamento de comandos. Primeiro, vamos dar uma olhada na estrutura básica no diagrama da classe de modo de comando:
Classe de comando: é uma classe abstrata que declara os comandos que precisam ser executados. De um modo geral, um método de execução deve ser publicado ao público para executar o comando.
Classe concretEcommand: A classe de implementação da classe de comando, implementa os métodos declarados na classe abstrata.
Classe do cliente: a classe de chamada final do cliente.
As funções das três classes acima devem ser mais fáceis de entender. Vamos nos concentrar na classe Invocador e na classe de recebedor.
Classe do Invocador: O chamador é responsável por invocar comandos.
Classe do receptor: o receptor é responsável por receber e executar comandos.
Para ser franco, o chamado encapsulamento dos comandos nada mais é do que escrever uma série de operações em um método e depois ser chamado pelo cliente. É refletido no diagrama de classe. É preciso apenas uma classe concreta e classe para concluir o encapsulamento de comandos. Mesmo se for além, a fim de aumentar a flexibilidade, uma classe de comando pode ser adicionada para abstração apropriada. Qual é a função deste chamador e receptor?
De fato, você pode pensar de outra perspectiva: se você simplesmente encapsular algumas operações como um comando para que outras pessoas chamem, como isso pode ser chamado de padrão? Como modelo comportamental, o modo de comando deve primeiro alcançar o baixo acoplamento. Somente quando o grau de acoplamento é baixo pode ser melhorado a flexibilidade. O objetivo de adicionar as funções de chamador e receptor é precisamente para isso. O código geral para o modo de comando é o seguinte:
classe Invocador {Comando Private Command; public void setCommand (comando comando) {this.Command = Command; } public void Action () {this.Command.execute (); }} Comando de classe abstrata {public abstrate void Execute (); } classe concreteCommand estende o comando {receptor de receptor privado; Public concreteCommand (receptor receptor) {this.receiver = receptor; } public void Execute () {this.receiver.dosomething (); }} classe receptor {public void Dosomething () {System.out.println ("Processamento da lógica do receptor-Business"); }} public class cliente {public static void main (string [] args) {receptor receptor = new receiver (); Comando comando = new concreteCommand (receptor); // O cliente executa diretamente o método de comando específico (este método é consistente com o diagrama de classe) command.execute (); // O cliente executa o comando através do chamador Invocador Invocador = new Invoker (); Invoker.setCommand (comando); invoker.action (); }}Através do código, podemos ver que, quando chamamos, o tempo de execução é a primeira classe de chamadas, depois a classe de comando e, finalmente, a classe receptor. Em outras palavras, a execução de um comando é dividida em três etapas e seu grau de acoplamento é muito menor do que encapsular todas as operações em uma classe. Essa é a essência do padrão de comando: separe o chamador do comando e do executor, para que ambas as partes não precisem se preocupar com a maneira como a outra parte opera.
Vantagens e desvantagens do modo de comando
Antes de tudo, o modo de comando é muito encapsulado: cada comando é encapsulado e, para o cliente, o comando correspondente é chamado tanto quanto a função é necessária sem saber como o comando é executado. Por exemplo, há um conjunto de comandos de operação de arquivo: Crie um novo arquivo, copie um arquivo e exclua um arquivo. Se essas três operações forem encapsuladas em uma classe de comando, o cliente precisará saber apenas que existem essas três classes de comando. Quanto à lógica encapsulada na classe de comando, o cliente não precisa saber.
Em segundo lugar, o modo de comando tem uma boa escalabilidade. No modo de comando, o encapsulamento mais básico das operações na classe receptor e o encapsulamento secundário da classe de comando dessas operações básicas. Ao adicionar novos comandos, a redação da classe de comando geralmente não é do zero. Há um grande número de classes de receptor para chamada e também há um grande número de classes de comando para chamada, e o código é muito reutilizável. Por exemplo, na operação de um arquivo, precisamos adicionar um comando para cortar um arquivo e precisamos apenas combinar os dois comandos de copiar um arquivo e excluir um arquivo, o que é muito conveniente.
Por fim, vamos falar sobre as desvantagens do modo de comando, ou seja, se houver muitos comandos, será uma dor de cabeça para se desenvolver. Especialmente muitos comandos simples são apenas algumas linhas de código para implementar. Se você usar o modo de comando, não precisa se preocupar com o quão simples é o comando, precisará escrever uma classe de comando para encapsulá -lo.
Cenários aplicáveis para o modo de comando
Para a maioria das funções de modo de solicitação-resposta, é mais adequado usar o modo de comando. Como diz a definição do modo de comando, o modo de comando é mais conveniente para a implementação de funções, como operações de registro e desfazer.
Resumir
Usar o modo em uma ocasião é uma pergunta muito emaranhada para todos os desenvolvedores. Às vezes, devido à previsão de algumas mudanças nos requisitos, um determinado padrão de design é usado para a flexibilidade e escalabilidade do sistema, mas esse requisito previsível não. Pelo contrário, muitos requisitos imprevisíveis chegaram, resultando no padrão de design usado desempenhando o papel oposto ao modificar o código, para que toda a equipe do projeto tenha reclamado. Eu acredito que todo programador encontrou esse exemplo. Portanto, com base no princípio do desenvolvimento ágil, quando projetamos programas, se pudermos resolvê -los bem sem usar um determinado padrão de acordo com as necessidades atuais, não devemos apresentá -lo, porque não é difícil introduzir um padrão de design. Podemos fazê -lo no sistema quando realmente precisamos usá -lo e introduzir esse padrão de design.
Tome o modo de comando como exemplo. Em nosso desenvolvimento, a função do modo de solicitação-resposta é muito comum. De um modo geral, encapsularemos a operação de resposta à solicitação em um método. Esse método encapsulado pode ser chamado de comando, mas não um modo de comando. Se esse projeto deve ser elevado à altura do padrão precisa ser considerado separadamente, porque se o modo de comando for usado, os dois papéis do chamador e do receptor devem ser introduzidos. A lógica originalmente colocada em um lugar é dispersa em três categorias. Ao projetar, é necessário considerar se esse custo vale a pena.
O exposto acima é todo o conteúdo deste artigo. Espero que seja útil para o aprendizado de todos e espero que todos apoiem mais o wulin.com.