用html做家谱网站代码,腾讯企业邮箱注册入口,响应式视频网站模板下载,网站设计工作流程耦合与变化#xff1a; 耦合是软件不能抵御变化灾难的根本性原因。不仅实体对象与实体对象之间存在耦合关系#xff0c;实体对象与行为操作之间也存在耦合关系。 动机(Mot…耦合与变化 耦合是软件不能抵御变化灾难的根本性原因。不仅实体对象与实体对象之间存在耦合关系实体对象与行为操作之间也存在耦合关系。 动机(Motivate): 在软件系统中“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合比如要对行为进行“记录、撤销/重做、事务”等处理这种无法抵御变化的紧耦合是不合适的。 在这种情况下如何将“行为请求者”与“行为实现者”解耦将一组行为抽象为对象可以实现二者之间的松耦合。意图(Intent): 将一个请求封装为一个对象从而使你可用不同的请求对客户进行参数化对请求排队或记录请求日志以及支持可撤消的操作。 -------《设计模式》GOF结构图(Struct): 适用性
1使用命令模式作为CallBack在面向对象系统中的替代。CallBack讲的便是先将一个函数登记上然后在以后调用此函数。
2 需要在不同的时间指定请求、将请求排队。一个命令对象和原先的请求发出者可以有不同的生命期。换言之原先的请求发出者可能已经不在了而命令对象本身仍 然是活动的。这时命令的接收者可以是在本地也可以在网络的另外一个地址。命令对象可以在串形化之后传送到另外一台机器上去。
3系统需要支持命令的撤消(undo)。命令对象可以把状态存储起来等到客户端需要撤销命令所产生的效果时可以调用undo()方法把命令所产生的效果撤销掉。命令对象还可以提供redo()方法以供客户端在需要时再重新实施命令效果。
4如果一个系统要将系统中所有的数据更新到日志里以便在系统崩溃时可以根据日志里读回所有的数据更新命令重新调用Execute()方法一条一条执行这些命令从而恢复系统在崩溃前所做的数据更新。 生活中的例子 Command模式将一个请求封装为一个对象从而使你可以使用不同的请求对客户进行参数化。用餐时的账单是Command模式的一个例子。服务员接受顾客的点单把它记在账单上封装。这个点单被排队等待烹饪。注意这里的账单是不依赖于菜单的它可以被不同的顾客使用因此它可以添入不同的点单项目。 代码实现 在众多的设计模式中Command模式是很简单也很优雅的一种设计模式。Command模式它封装的是命令把命令发出者的责任和命令执行者的责任分开。我们知道一个类是一组操作和相应的一些变量的集合现在有这样一个类Document如下 1 /// summary 2 3 /// 文档类 4 5 /// /summary 6 7 public class Document 8 9 { 10 /** summary 11 12 /// 显示操作 13 14 /// /summary 15 16 public void Display() 17 18 { 19 Console.WriteLine(Display); 20 } 21 22 /** summary 23 24 /// 撤销操作 25 26 /// /summary 27 28 public void Undo() 29 30 { 31 Console.WriteLine(Undo); 32 } 33 34 /** summary 35 36 /// 恢复操作 37 38 /// /summary 39 40 public void Redo() 41 42 { 43 Console.WriteLine(Redo); 44 } 45 }
通常客户端实现代码如下 1 class Program 2 3 { 4 static void Main(string[] args) 5 6 { 7 Document doc new Document(); 8 9 doc.Display(); 10 11 doc.Undo(); 12 13 doc.Redo(); 14 } 15 } 这样的使用本来是没有任何问题的但是我们看到在这个特定的应用中出现了Undo/Redo的操作这时如果行为的请求者和行为的实现者之间还是呈现这样一种紧耦合就不太合适了。可以看到客户程序是依赖于具体Document的命令方法的引入Command模式需要对Document中的三个命令进行抽象这是Command模式最有意思的地方因为在我们看来Display()Undo()Redo()这三个方法都应该是Document所具有的如果单独抽象出来成一个命令对象那就是把函数层面的功能提到了类的层面有点功能分解的味道我觉得这正是Command模式解决这类问题的优雅之处先对命令对象进行抽象 1 /// summary 2 3 /// 抽象命令 4 5 /// /summary 6 7 public abstract class DocumentCommand 8 9 { 10 Document _document; 11 12 public DocumentCommand(Document doc) 13 14 { 15 this._document doc; 16 } 17 18 /** summary 19 20 /// 执行 21 22 /// /summary 23 24 public abstract void Execute(); 25 26 }
其他的具体命令类都继承于该抽象类如下 示意性代码如下 1 /// summary 2 3 /// 显示命令 4 5 /// /summary 6 7 public class DisplayCommand : DocumentCommand 8 9 { 10 public DisplayCommand(Document doc) 11 12 : base(doc) 13 { 14 15 } 16 17 public override void Execute() 18 19 { 20 _document.Display(); 21 } 22 } 23 24 25 /** summary 26 27 /// 撤销命令 28 29 /// /summary 30 31 public class UndoCommand : DocumentCommand 32 33 { 34 public UndoCommand(Document doc) 35 36 : base(doc) 37 { 38 39 } 40 41 public override void Execute() 42 43 { 44 _document.Undo(); 45 } 46 } 47 48 49 /** summary 50 51 /// 重做命令 52 53 /// /summary 54 55 public class RedoCommand : DocumentCommand 56 57 { 58 public RedoCommand(Document doc) 59 60 : base(doc) 61 { 62 63 } 64 65 public override void Execute() 66 67 { 68 _document.Redo(); 69 } 70 } 现在还需要一个Invoker角色的类这其实相当于一个中间角色前面我曾经说过使用这样的一个中间层也是我们经常使用的手法即把A对B的依赖转换为A对C的依赖。如下 1 /// summary 2 3 /// Invoker角色 4 5 /// /summary 6 7 public class DocumentInvoker 8 9 { 10 DocumentCommand _discmd; 11 12 DocumentCommand _undcmd; 13 14 DocumentCommand _redcmd; 15 16 public DocumentInvoker(DocumentCommand discmd,DocumentCommand undcmd,DocumentCommand redcmd) 17 { 18 19 this._discmd discmd; 20 21 this._undcmd undcmd; 22 23 this._redcmd redcmd; 24 25 } 26 27 public void Display() 28 29 { 30 _discmd.Execute(); 31 } 32 33 public void Undo() 34 35 { 36 _undcmd.Execute(); 37 } 38 39 public void Redo() 40 41 { 42 _redcmd.Execute(); 43 } 44 } 45 46 现在再来看客户程序的调用代码 47 class Program 48 49 { 50 static void Main(string[] args) 51 52 { 53 54 Document doc new Document(); 55 56 57 DocumentCommand discmd new DisplayCommand(doc); 58 59 DocumentCommand undcmd new UndoCommand(doc); 60 61 DocumentCommand redcmd new RedoCommand(doc); 62 63 64 DocumentInvoker invoker new DocumentInvoker(discmd,undcmd,redcmd); 65 66 invoker.Display(); 67 68 invoker.Undo(); 69 70 invoker.Redo(); 71 72 } 73 } 可以看到在客户程序中不再依赖于Document的Display()Undo()Redo()命令通过Command对这些命令进行了封装使用它的一个关键就是抽象的Command类它定义了一个操作的接口。同时我们也可以看到本来这三个命令仅仅是三个方法而已但是通过Command模式却把它们提到了类的层面这其实是违背了面向对象的原则但它却优雅的解决了分离命令的请求者和命令的执行者的问题在使用Command模式的时候一定要判断好使用它的时机。
Command实现要点
1Command模式的根本目的在于将“行为请求者”与“行为实现者”解耦在面向对象语言中常见的实现手段是“将行为抽象为对象”。
2实现Command接口的具体命令对象ConcreteCommand有时候根据需要可能会保存一些额外的状态信息。
3通过使用Compmosite模式可以将多个命令封装为一个“复合命令”MacroCommand。
4Command模式与C#中的Delegate有些类似。但两者定义行为接口的规范有所区别Command以面向对象中的“接口-实现”来定义行为接口规范更严格更符合抽象原则Delegate以函数签名来定义行为接口规范更灵活但抽象能力比较弱。
5使用命令模式会导致某些系统有过多的具体命令类。某些系统可能需要几十个几百个甚至几千个具体命令类这会使命令模式在这样的系统里变得不实际。Command的优缺点
命令允许请求的一方和接收请求的一方能够独立演化从而且有以下的优点 1.命令模式使新的命令很容易地被加入到系统里。 2.允许接收请求的一方决定是否要否决Veto请求。 3.能较容易地设计-个命令队列。 4.可以容易地实现对请求的Undo和Redo。 5.在需要的情况下可以较容易地将命令记入日志。 6.命令模式把请求一个操作的对象与知道怎么执行一个操作的对象分割开。 7.命令类与其他任何别的类一样可以修改和推广。 8.你可以把命令对象聚合在一起合成为合成命令。比如宏命令便是合成命令的例子。合成命令是合成模式的应用。 9.由于加进新的具体命令类不影响其他的类因此增加新的具体命令类很容易。 命令模式的缺点如下 1.使用命令模式会导致某些系统有过多的具体命令类。某些系统可能需要几十个几百个甚至几千个具体命令类这会使命令模式在这样的系统里变得不实际。 1 class Program 2 3 { 4 static void Main(string[] args) 5 6 { 7 Document doc new Document(); 8 9 doc.Display(); 10 11 doc.Undo(); 12 13 doc.Redo(); 14 } 15 }
