C# 设计模式系列教程-命令模式_C#教程

1. 概述

  将一个请求封装为一个对象(即我们创建的Command对象),从而使你可用不同的请求对客户进行参数化; 对请求排队或记录请求日志,以及支持可撤销的操作。

2. 解决的问题

  在软件系统中,行为请求者与行为实现者通常是一种紧耦合的关系,但某些场合,比如需要对行为进行记录、撤销或重做、事务等处理时,这种无法抵御变化的紧耦合的设计就不太合适。

3. 模式中角色

  3.1 抽象命令(Command):定义命令的接口,声明执行的方法。

  3.2 具体命令(ConcreteCommand):具体命令,实现要执行的方法,它通常是“虚”的实现;通常会有接收者,并调用接收者的功能来完成命令要执行的操作。

  3.3 接收者(Receiver):真正执行命令的对象。任何类都可能成为一个接收者,只要能实现命令要求实现的相应功能。

  3.4 调用者(Invoker):要求命令对象执行请求,通常会持有命令对象,可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方,也就是说相当于使用命令对象的入口。

  3.5 客户端(Client):命令由客户端来创建,并设置命令的接收者。

4. 模式解读

  4.1 命令模式的类图

  4.2 命令模式的实现代码

 /// <summary>
 /// 接收者类,知道如何实施与执行一个请求相关的操作,任何类都可能作为一个接收者。
 /// </summary>
 public class Receiver
 {
  /// <summary>
  /// 真正的命令实现
  /// </summary>
  public void Action()
  {
   Console.WriteLine("Execute request!");
  }
 }

 /// <summary>
 /// 抽象命令类,用来声明执行操作的接口
 /// </summary>
 public interface ICommand
 {
  void Execute();
 }

 /// <summary>
 /// 具体命令类,实现具体命令。
 /// </summary>
 public class ConcereteCommand : ICommand
 {
  // 具体命令类包含有一个接收者,将这个接收者对象绑定于一个动作
  private Receiver receiver;

  public ConcereteCommand(Receiver receiver)
  {
   this.receiver = receiver;
  }

  /// <summary>
  /// 说这个实现是“虚”的,因为它是通过调用接收者相应的操作来实现Execute的
  /// </summary>
  public void Execute()
  {
   receiver.Action();
  }
 }

 /// <summary>
 /// 调度类,要求该命令执行这个请求
 /// </summary>
 public class Invoker
 {
  private ICommand command;

  /// <summary>
  /// 设置命令
  /// </summary>
  /// <param name="command"></param>
  public void SetCommand(ICommand command)
  {
   this.command = command;
  }

  /// <summary>
  /// 执行命令
  /// </summary>
  public void ExecuteCommand()
  {
   command.Execute();
  }
 }

  4.3 客户端代码

 class Program
 {
  static void Main(string[] args)
  {
   Receiver receiver = new Receiver();
   ICommand command = new ConcereteCommand(receiver);
   Invoker invoker = new Invoker();

   invoker.SetCommand(command);
   invoker.ExecuteCommand();

   Console.Read();
  }
 }

  执行结果

  4.4 模式分析

    4.4.1 本质:对命令进行封装,将发出命令与执行命令的责任分开。

    4.4.2 每一个命令都是一个操作:请求的一方发出请求,要求执行一个操作;接收的一方收到请求,并执行操作。

    4.4.3 请求方和接收方独立开来,使得请求的一方不必知道接收请求的一方的接口,更不必知道请求是怎么被接收,以及操作是否被执行、何时被执行,以及是怎么被执行的。

    4.4.4 使请求本身成为一个对象,这个对象和其它对象一样可以被存储和传递。

    4.4.5 命令模式的关键在于引入了抽象命令接口,且发送者针对抽象命令接口编程,只有实现了抽象命令接口的具体命令才能与接收者相关联。 

5. 模式总结

  5.1 优点

    5.1.1 解除了请求者与实现者之间的耦合,降低了系统的耦合度。

    5.1.2 对请求排队或记录请求日志,支持撤销操作。

    5.1.3 可以容易地设计一个组合命令。

    5.1.4 新命令可以容易地加入到系统中。

  5.2 缺点

    5.2.1 因为针对每一个命令都需要设计一个具体命令类,使用命令模式可能会导致系统有过多的具体命令类。

  5.3 适用场景

    5.3.1 当需要对行为进行“记录、撤销/重做”等处理时。

    5.3.2 系统需要将请求者和接收者解耦,使得调用者和接收者不直接交互。

    5.3.3 系统需要在不同时间指定请求、请求排队和执行请求。

    5.3.4 系统需要将一组操作组合在一起,即支持宏命令。

6. 应用举例:银行帐号的存款、提款

  6.1 类图

  6.2 代码实现

 /// <summary>
 /// 银行帐号
 /// </summary>
 public class Account
 {
  /// <summary>
  /// 帐号总金额
  /// </summary>
  private decimal totalAmount { get; set; }

  /// <summary>
  /// 存钱
  /// </summary>
  /// <param name="amount"></param>
  public void MoneyIn(decimal amount)
  {
   this.totalAmount += amount;
  }

  /// <summary>
  /// 取钱
  /// </summary>
  /// <param name="amount"></param>
  public void MoneyOut(decimal amount)
  {
   this.totalAmount -= amount;
  }

  public decimal GetTotalAmout()
  {
   return totalAmount;
  }
 }

 public abstract class Command
 {
  protected Account account;

  public Command(Account account)
  {
   this.account = account;
  }

  public abstract void Execute();
 }

 /// <summary>
 /// 存款命令
 /// </summary>
 public class MoneyInCommand : Command
 {
  private decimal amount;

  public MoneyInCommand(Account account, decimal amount)
   : base(account)
  {
   this.amount = amount;
  }

  /// <summary>
  /// 实现存钱命令
  /// </summary>
  public override void Execute()
  {
   account.MoneyIn(amount);
  }
 }

 /// <summary>
 /// 取款命令类
 /// </summary>
 public class MoneyOutCommand : Command
 {
  private decimal amount;
  public MoneyOutCommand(Account account, decimal amount)
   : base(account)
  {
   this.amount = amount;
  }

  /// <summary>
  /// 实现取钱命令
  /// </summary>
  public override void Execute()
  {
   account.MoneyOut(amount);
  }
 }

 public class Invoker
 {
  private Command command;

  public void SetCommand(Command command)
  {
   this.command = command;
  }

  public void ExecuteCommand()
  {
   command.Execute();
  }
 }

  6.3 客户端代码

 class Program
 {
  static void Main(string[] args)
  {
   // 创建银行帐号
   Account account = new Account();
   // 创建一个存入500元的命令
   Command commandIn = new MoneyInCommand(account,500);
   // 创建一个调度者
   BankAccount.Invoker invoker = new BankAccount.Invoker();

   // 设置存钱命令
   invoker.SetCommand(commandIn);
   // 执行
   invoker.ExecuteCommand();
   Console.WriteLine("The current amount is " + account.GetTotalAmout().ToString("N2"));

   // 再次存入500
   Command commandIn2 = new MoneyInCommand(account, 500);
   invoker.SetCommand(commandIn2);
   invoker.ExecuteCommand();
   Console.WriteLine("The current amount is " + account.GetTotalAmout().ToString("N2"));

   // 取出300
   Command commandOut = new MoneyOutCommand(account, 300);
   invoker.SetCommand(commandOut);
   invoker.ExecuteCommand();
   Console.WriteLine("The current amount is " + account.GetTotalAmout().ToString("N2"));

   Console.Read();
  }
 }

  执行结果

以上就是本文的全部内容,希望能给大家一个参考,也希望大家多多支持。

以上是小编为您精心准备的的内容,在的博客、问答、公众号、人物、课程等栏目也有的相关内容,欢迎继续使用右上角搜索按钮进行搜索c#
, 客户端
, 接口
, 设计模式
命令模式
c站、c语言、cf、ch、c罗,以便于您获取更多的相关知识。

时间: 2024-09-01 03:23:32

C# 设计模式系列教程-命令模式_C#教程的相关文章

C# 设计模式系列教程-状态模式_C#教程

1. 概述 当一个对象的内在状态改变时允许改变其行为,这个对象看起来像是改变了其类. 2. 解决的问题 主要解决的是当控制一个对象状态转换的条件表达式过于复杂时的情况.把状态的判断逻辑转移到表示不同的一系列类当中,可以把复杂的逻辑判断简单化. 3. 模式中的角色 3.1 上下文环境(Context):它定义了客户程序需要的接口并维护一个具体状态角色的实例,将与状态相关的操作委托给当前的Concrete State对象来处理. 3.2 抽象状态(State):定义一个接口以封装使用上下文环境的的一

C# 设计模式系列教程-桥接模式_C#教程

1. 概述 将抽象部分(Abstraction)与实现部分(Implementor)分离,使它们可以独立地变化. 2. 解决的问题 在软件系统中,有些类型由于自身的逻辑,它具有两个或多个维度的变化.为了解决这种多维度变化,又不引入复杂度,这就要使用Bridge模式. 3. 模式中的角色 2.1 抽象(Abstraction):定义抽象接口,该接口中包含实现具体行为.具体特征的Implementor接口. 2.2 提炼的抽象(RefinedAbstraction):继承自Abstraction的子

C# 设计模式系列教程-原型模式_C#教程

1. 概述 通过复制一个已经存在的实例来创建一个新的实例.被复制的实例被称为原型,这个原型是可定制的. 2. 模式中的角色 2.1 抽象原型类(Abstract Prototype):提供一个克隆接口 2.2 具体原型类(Concrete Prototype): 及实现了克隆接口的具体原型类 3. 实例:求职网站上现在都支持多份简历,如果每创建一份简历都要从头至尾地填写一遍,那也是非常让人沮丧的事.其实针对我们的求职岗位的不同,不同的简历可能只要修改局部内容就可以了,而不用全部重新构建一份新的简

C# 设计模式系列教程-策略模式_C#教程

在讲策略模式之前,我先给大家举个日常生活中的例子,从首都国际机场到XXX酒店,怎么过去?1)酒店接机服务,直接开车来接.2)打车过去.3)机场快轨+地铁 4)机场巴士 5)公交车 6)走路过去(不跑累死的话) 等等.使用方法,我们都可以达到从机场到XXX酒店的目的,对吧.那么我所列出的从机场到XXX酒店的的方法,就是我们可以选择的策略. 再举个例子,就是我们使用WCF时,往往避免不了对它进行扩展,例如授权,我们可以通过自定义授权来扩展WCF.这里我们可以通过自定义AuthorizationPol

C# 设计模式系列教程-代理模式_C#教程

1. 概述 为其它对象提供一种代理以控制对这个对象的访问. 解决的问题:如果直接访问对象比较困难,或直接访问会给使用者或系统带来一系列问题.这样对于客户端(调用者)来说,就不需要直接与真实对象进行交互,解除了调用者与真实对象的耦合. 2. 模式中的角色 2.1 抽象实体(Subject):定义了真实实体(RealSubject)和代理(Proxy)的公共接口,这样就在任何时候使用真实实体(RealSubject)的地方使用代理(Proxy). 2.2 代理(Proxy):保存一个引用使得代理可以

C# 设计模式系列教程-组合模式_C#教程

1. 概述 将对象组合成树形结构以表示"部分-整体"的层次结构.组合模式使得用户对单个对象和组合对象的使用具有一致性. 2. 解决的问题 当希望忽略单个对象和组合对象的区别,统一使用组合结构中的所有对象(将这种"统一"性封装起来). 3. 组合模式中的角色 3.1 组合部件(Component):它是一个抽象角色,为要组合的对象提供统一的接口. 3.2 叶子(Leaf):在组合中表示子节点对象,叶子节点不能有子节点. 3.3 合成部件(Composite):定义有枝

C# 设计模式系列教程-模板方法模式_C#教程

1. 概述 定义一个操作中的算法的骨架,而将步骤延迟到子类中.模板方法使得子类可以不改变一个算法的结构即可重定义算法的某些特定步骤. 2. 模式中的角色 2.1 抽象类(AbstractClass):实现了模板方法,定义了算法的骨架. 2.2 具体类(ConcreteClass):实现抽象类中的抽象方法,已完成完整的算法. 3. 模式解读 3.1 模板方法类图 3.2 模板方法模式代码实现 /// <summary> /// 抽象类 /// </summary> public ab

C# 设计模式系列教程-外观模式_C#教程

1. 概述 为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口使得这一子系统更加容易使用. 2. 模式中的角色 2.1 外观类(Facade):外观类知道哪些子系统类负责处理请求,将客户的请求代理给恰当的子系统对象. 2.2 子系统类集合(SubSystem Classes):子系统类集合实现了子系统的功能,处理外观类对象指派的任务. 3. 模式解读 3.1 外观模式的类图 3.2 外观模式的代码实现 /// <summary> /// 子系统中的一个类 /// <

Android设计模式系列之组合模式_Android

Android中对组合模式的应用,可谓是泛滥成粥,随处可见,那就是View和ViewGroup类的使用.在android UI设计,几乎所有的widget和布局类都依靠这两个类. 组合模式,Composite Pattern,是一个非常巧妙的模式.几乎所有的面向对象系统都应用到了组合模式. 1.意图 将对象View和ViewGroup组合成树形结构以表示"部分-整体"的层次结构(View可以做为ViewGroup的一部分). 组合模式使得用户对单个对象View和组合对象ViewGrou