标签：逆序 pattern target element 变化 工资 random 耦合度 角色
每个对象都有其对应的状态，而每个状态又对应一些相应的行为，如果某个对象有多个状态时，那么就会对应很多的行为。那么对这些状态的判断和根据状态完成的行为，就会导致多重条件语句，并且如果添加一种新的状态时，需要更改之前现有的代码。这样的设计显然违背了开闭原则，状态模式正是用来解决这样的问题的。
状态模式——允许一个对象在其内部状态改变时自动改变其行为，对象看起来就像是改变了它的类。具体的结构图如下所示：
就以银行账户的状态来实现下状态者模式。银行账户根据余额可分为RedState、SilverState和GoldState。这些状态分别代表透支账号，新开账户和标准账户。账号余额在【-100.0，0.0】范围表示处于RedState状态，账号余额在【0.0，1000.0】范围表示处于SilverState，账号在【1000.0， 100000.0】范围表示处于GoldState状态。
状态者模式涉及以下三个角色：
Account类：维护一个State类的一个实例，该实例标识着当前对象的状态。
State类：抽象状态类，定义了一个具体状态类需要实现的行为约定。
SilveStater、GoldState和RedState类：具体状态类，实现抽象状态类的每个行为。
下面以这样的一个场景实现下状态者模式，具体实现代码如下所示：
namespace StatePatternSample { public class Account { public State State {get;set;} public string Owner { get; set; } //owner字段是不改变的，而State这个内部的类是根据不同的存款额而更改。 public Account(string owner) { this.Owner = owner; //默认提供的是0元账户，账户级别是SilverState this.State = new SilverState(0.0, this); } public double Balance { get {return State.Balance; }} // 余额 // 存钱 存取钱的操作都是调用ACCount的类，然后account调用state对应的存取钱操作，由于state的类型是已知的，所以会有对应的操作。 public void Deposit(double amount) { State.Deposit(amount); Console.WriteLine("存款金额为 {0:C}——", amount); Console.WriteLine("账户余额为 =:{0:C}", this.Balance); Console.WriteLine("账户状态为: {0}", this.State.GetType().Name); Console.WriteLine(); } // 取钱 public void Withdraw(double amount) { State.Withdraw(amount); Console.WriteLine("取款金额为 {0:C}——",amount); Console.WriteLine("账户余额为 =:{0:C}", this.Balance); Console.WriteLine("账户状态为: {0}", this.State.GetType().Name); Console.WriteLine(); } // 获得利息 public void PayInterest() { State.PayInterest(); Console.WriteLine("Interest Paid --- "); Console.WriteLine("账户余额为 =:{0:C}", this.Balance); Console.WriteLine("账户状态为: {0}", this.State.GetType().Name); Console.WriteLine(); } } // 抽象状态类 public abstract class State { // Properties public Account Account { get; set; } public double Balance { get; set; } // 余额 public double Interest { get; set; } // 利率 public double LowerLimit { get; set; } // 下限 public double UpperLimit { get; set; } // 上限 public abstract void Deposit(double amount); // 存款 public abstract void Withdraw(double amount); // 取钱 public abstract void PayInterest(); // 获得的利息 } // Red State意味着Account透支了 public class RedState : State { public RedState(State state) { // Initialize this.Balance = state.Balance; this.Account = state.Account; Interest = 0.00; LowerLimit = -100.00; UpperLimit = 0.00; } // 存款 public override void Deposit(double amount) { Balance += amount; StateChangeCheck(); } // 取钱 public override void Withdraw(double amount) { Console.WriteLine("没有钱可以取了！"); } public override void PayInterest() { // 没有利息 } private void StateChangeCheck() { if (Balance > UpperLimit) { Account.State = new SilverState(this); } } } // Silver State意味着没有利息得 public class SilverState :State { public SilverState(State state) : this(state.Balance, state.Account) { } public SilverState(double balance, Account account) { this.Balance = balance; this.Account = account; Interest = 0.00; LowerLimit = 0.00; UpperLimit = 1000.00; } public override void Deposit(double amount) { Balance += amount; StateChangeCheck(); } public override void Withdraw(double amount) { Balance -= amount; StateChangeCheck(); } public override void PayInterest() { Balance += Interest * Balance; StateChangeCheck(); } private void StateChangeCheck() { if (Balance < LowerLimit) { Account.State = new RedState(this); } else if (Balance > UpperLimit) { Account.State = new GoldState(this); } } } // Gold State意味着有利息状态 public class GoldState : State { public GoldState(State state) { this.Balance = state.Balance; this.Account = state.Account; Interest = 0.05; LowerLimit = 1000.00; UpperLimit = 1000000.00; } // 存钱 public override void Deposit(double amount) { Balance += amount; StateChangeCheck(); } // 取钱 public override void Withdraw(double amount) { Balance -= amount; StateChangeCheck(); } public override void PayInterest() { Balance += Interest * Balance; StateChangeCheck(); } private void StateChangeCheck() { if (Balance < 0.0) { Account.State = new RedState(this); } else if (Balance < LowerLimit) { Account.State = new SilverState(this); } } } class App { static void Main(string[] args) { // 开一个新的账户 Account account = new Account("Learning Hard"); // 进行交易 // 存钱 account.Deposit(1000.0); account.Deposit(200.0); account.Deposit(600.0); // 付利息 account.PayInterest(); // 取钱 account.Withdraw(2000.00); account.Withdraw(500.00); // 等待用户输入 Console.ReadKey(); } } }
下面利用观察者模式和状态者模式来完善中介者模式，具体的实现代码如下所示：
// 抽象牌友类 public abstract class AbstractCardPartner { public int MoneyCount { get; set; } public AbstractCardPartner() { MoneyCount = 0; } public abstract void ChangeCount(int Count, AbstractMediator mediator); } // 牌友A类 public class ParterA : AbstractCardPartner { // 依赖与抽象中介者对象 public override void ChangeCount(int Count, AbstractMediator mediator) { mediator.ChangeCount(Count); } } // 牌友B类 public class ParterB : AbstractCardPartner { // 依赖与抽象中介者对象 public override void ChangeCount(int Count, AbstractMediator mediator) { mediator.ChangeCount(Count); } } // 抽象状态类 public abstract class State { protected AbstractMediator meditor; public abstract void ChangeCount(int count); } // A赢状态类 public class AWinState : State { public AWinState(AbstractMediator concretemediator) { this.meditor = concretemediator; } public override void ChangeCount(int count) { foreach (AbstractCardPartner p in meditor.list) { ParterA a = p as ParterA; // if (a != null) { a.MoneyCount += count; } else { p.MoneyCount -= count; } } } } // B赢状态类 public class BWinState : State { public BWinState(AbstractMediator concretemediator) { this.meditor = concretemediator; } public override void ChangeCount(int count) { foreach (AbstractCardPartner p in meditor.list) { ParterB b = p as ParterB; // 如果集合对象中时B对象，则对B的钱添加 if (b != null) { b.MoneyCount += count; } else { p.MoneyCount -= count; } } } } // 初始化状态类 public class InitState : State { public InitState() { Console.WriteLine("游戏才刚刚开始,暂时还有玩家胜出"); } public override void ChangeCount(int count) { // return; } } // 抽象中介者类 public abstract class AbstractMediator { public List<AbstractCardPartner> list = new List<AbstractCardPartner>(); public State State { get; set; } public AbstractMediator(State state) { this.State = state; } public void Enter(AbstractCardPartner partner) { list.Add(partner); } public void Exit(AbstractCardPartner partner) { list.Remove(partner); } public void ChangeCount(int count) { State.ChangeCount(count); } } // 具体中介者类 public class MediatorPater : AbstractMediator { public MediatorPater(State initState) : base(initState) { } } class Program { static void Main(string[] args) { AbstractCardPartner A = new ParterA(); AbstractCardPartner B = new ParterB(); // 初始钱 A.MoneyCount = 20; B.MoneyCount = 20; AbstractMediator mediator = new MediatorPater(new InitState()); // A,B玩家进入平台进行游戏 mediator.Enter(A); mediator.Enter(B); // A赢了 mediator.State = new AWinState(mediator); mediator.ChangeCount(5); Console.WriteLine("A 现在的钱是：{0}", A.MoneyCount);// 应该是25 Console.WriteLine("B 现在的钱是：{0}", B.MoneyCount); // 应该是15 // B 赢了 mediator.State = new BWinState(mediator); mediator.ChangeCount(10); Console.WriteLine("A 现在的钱是：{0}", A.MoneyCount);// 应该是25 Console.WriteLine("B 现在的钱是：{0}", B.MoneyCount); // 应该是15 Console.Read(); } }
在以下情况下可以考虑使用状态者模式。
A当一个对象状态转换的条件表达式过于复杂时可以使用状态者模式。把状态的判断逻辑转移到表示不同状态的一系列类中，可以把复杂的判断逻辑简单化。
B当一个对象行为取决于它的状态，并且它需要在运行时刻根据状态改变它的行为时，就可以考虑使用状态者模式。
状态者模式的主要优点是：
将状态判断逻辑每个状态类里面，可以简化判断的逻辑。
当有新的状态出现时，可以通过添加新的状态类来进行扩展，扩展性好。
状态者模式的主要缺点是：
如果状态过多的话，会导致有非常多的状态类，加大了开销。
在现实生活中，中国的所得税，分为企业所得税、外商投资企业或外商企业所得税和个人所得税，针对于这3种所得税，每种所计算的方式不同，个人所得税有个人所得税的计算方式，而企业所得税有其对应计算方式。如果不采用策略模式来实现这样一个需求的话，我们会定义一个所得税类，该类有一个属性来标识所得税的类型，并且有一个计算税收的CalculateTax()方法，在该方法体内需要对税收类型进行判断，通过if-else语句来针对不同的税收类型来计算其所得税。这样的实现确实可以解决这个场景，但是这样的设计不利于扩展，如果系统后期需要增加一种所得税时，此时不得不回去修改CalculateTax方法来多添加一个判断语句，这样明白违背了“开放——封闭”原则。此时，我们可以考虑使用策略模式来解决这个问题，既然税收方法是这个场景中的变化部分，此时自然可以想到对税收方法进行抽象，这也是策略模式实现的精髓所在。
策略模式是对算法的包装，是把使用算法的责任和算法本身分割开，委派给不同的对象负责。策略模式通常把一系列的算法包装到一系列的策略类里面。用一句话慨括策略模式就是——“将每个算法封装到不同的策略类中，使得它们可以互换”。下面是策略模式的结构图：
namespace StrategyPattern { // 所得税计算策略 public interface ITaxStragety { double CalculateTax(double income); }. // 个人所得税 public class PersonalTaxStrategy : ITaxStragety { public double CalculateTax(double income) { return income * 0.12; } } // 企业所得税 public class EnterpriseTaxStrategy : ITaxStragety { public double CalculateTax(double income) { return (income - 3500) > 0 ? (income - 3500) * 0.045 : 0.0; } } public class InterestOperation { private ITaxStragety m_strategy; public InterestOperation(ITaxStragety strategy) { this.m_strategy = strategy; } public double GetTax(double income) { return m_strategy.CalculateTax(income); } } class App { static void Main(string[] args) { // 个人所得税方式 InterestOperation operation = new InterestOperation(new PersonalTaxStrategy()); Console.WriteLine("个人支付的税为：{0}", operation.GetTax(5000.00)); // 企业所得税 operation = new InterestOperation(new EnterpriseTaxStrategy()); Console.WriteLine("企业支付的税为：{0}", operation.GetTax(50000.00)); Console.Read(); } } }
在.NET Framework中也不乏策略模式的应用例子。例如，在.NET中，为集合类型ArrayList和List<T>提供的排序功能，其中实现就利用了策略模式，定义了IComparer接口来对比较算法进行封装，实现IComparer接口的类可以是顺序，或逆序地比较两个对象的大小，具体.NET中的实现可以使用反编译工具查看List<T>.Sort(IComparer<T>)的实现。其中List<T>就是承担着环境角色，而IComparer<T>接口承担着抽象策略角色，具体的策略角色就是实现了IComparer<T>接口的类，List<T>类本身实现了存在实现了该接口的类，我们可以自定义继承与该接口的具体策略类。
在下面的情况下可以考虑使用策略模式：
A一个系统需要动态地在几种算法中选择一种的情况下。那么这些算法可以包装到一个个具体的算法类里面，并为这些具体的算法类提供一个统一的接口。
B如果一个对象有很多的行为，如果不使用合适的模式，这些行为就只好使用多重的if-else语句来实现，此时，可以使用策略模式，把这些行为转移到相应的具体策略类里面，就可以避免使用难以维护的多重条件选择语句，并体现面向对象涉及的概念。
策略模式的主要优点有：
A策略类之间可以自由切换。由于策略类都实现同一个接口，所以使它们之间可以自由切换。
B易于扩展。增加一个新的策略只需要添加一个具体的策略类即可，基本不需要改变原有的代码。
C避免使用多重条件选择语句，充分体现面向对象设计思想。
策略模式的主要缺点有：
A客户端必须知道所有的策略类，并自行决定使用哪一个策略类。这点可以考虑使用IOC容器和依赖注入的方式来解决，关于IOC容器和依赖注入（Dependency Inject）的文章可以参考：IoC 容器和Dependency Injection 模式。
策略模式会造成很多的策略类。
在现实生活中，有很多请求并不是一个人说了就算的，例如面试时的工资，低于1万的薪水可能技术经理就可以决定了，但是1万~1万5的薪水可能技术经理就没这个权利批准，可能需要请求技术总监的批准。
责任链模式——某个请求需要多个对象进行处理，从而避免请求的发送者和接收之间的耦合关系。将这些对象连成一条链子，并沿着这条链子传递该请求，直到有对象处理它为止。
责任链降低了请求端和接收端之间的耦合，使多个对象都有机会处理某个请求。如考试中作弊传纸条，泡妞传情书一般。
具体结构图如下所示：
下面以公司采购东西为例子来实现责任链模式。公司规定，采购架构总价在1万之内，经理级别的人批准即可，总价大于1万小于2万5的则还需要副总进行批准，总价大于2万5小于10万的需要还需要总经理批准，而大于总价大于10万的则需要组织一个会议进行讨论
namespace ChainofResponsibility { // 采购请求 public class PurchaseRequest { // 金额 public double Amount { get; set; } // 产品名字 public string ProductName { get; set; } public PurchaseRequest(double amount, string productName) { Amount = amount; ProductName = productName; } } // 审批人,Handler public abstract class Approver { public Approver NextApprover { get; set; } public string Name { get; set; } //有点像链表啊！ public Approver(string name) { this.Name = name; } public abstract void ProcessRequest(PurchaseRequest request); } // ConcreteHandler public class Manager : Approver { public Manager(string name) : base(name) { } public override void ProcessRequest(PurchaseRequest request) { if (request.Amount < 10000.0) { Console.WriteLine("{0}-{1} approved the request of purshing {2}", this, Name, request.ProductName); } else if (NextApprover != null) { NextApprover.ProcessRequest(request); } } } // ConcreteHandler,副总 public class VicePresident : Approver { public VicePresident(string name) : base(name) { } public override void ProcessRequest(PurchaseRequest request) { if (request.Amount < 25000.0) { Console.WriteLine("{0}-{1} approved the request of purshing {2}", this, Name, request.ProductName); } else if (NextApprover != null) { NextApprover.ProcessRequest(request); } } } // ConcreteHandler，总经理 public class President :Approver { public President(string name) : base(name) { } public override void ProcessRequest(PurchaseRequest request) { if (request.Amount < 100000.0) { Console.WriteLine("{0}-{1} approved the request of purshing {2}", this, Name, request.ProductName); } else { Console.WriteLine("Request需要组织一个会议讨论"); } } } class Program { static void Main(string[] args) { PurchaseRequest requestTelphone = new PurchaseRequest(4000.0, "Telphone"); PurchaseRequest requestSoftware = new PurchaseRequest(10000.0, "Visual Studio"); PurchaseRequest requestComputers = new PurchaseRequest(40000.0, "Computers"); Approver manager = new Manager("LearningHard"); Approver Vp = new VicePresident("Tony"); Approver Pre = new President("BossTom"); // 设置责任链 manager.NextApprover = Vp; Vp.NextApprover = Pre; // 处理请求 manager.ProcessRequest(requestTelphone); manager.ProcessRequest(requestSoftware); manager.ProcessRequest(requestComputers); Console.ReadLine(); } } }
在以下场景中可以考虑使用责任链模式：
A一个系统的审批需要多个对象才能完成处理的情况下，例如请假系统等。
B代码中存在多个if-else语句的情况下，此时可以考虑使用责任链模式来对代码进行重构。
责任链模式的优点不言而喻，主要有以下点：
A降低了请求的发送者和接收者之间的耦合。
B把多个条件判定分散到各个处理类中，使得代码更加清晰，责任更加明确。
责任链模式也具有一定的缺点，如：
A在找到正确的处理对象之前，所有的条件判定都要执行一遍，当责任链过长时，可能会引起性能的问题
B可能导致某个请求不被处理。
生活中的手机通讯录备忘录，操作系统备份点，数据库备份等都是备忘录模式的应用。备忘录模式是在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样以后就可以把该对象恢复到原先的状态。具体的结构图如下所示：
Memento 是遗物 纪念品的意思。
备忘录模式中主要有三类角色：
发起人角色：记录当前时刻的内部状态，负责创建和恢复备忘录数据。
备忘录角色：负责存储发起人对象的内部状态，在进行恢复时提供给发起人需要的状态。
管理者角色：负责保存备忘录对象。
// 联系人 public class ContactPerson { public string Name { get; set; } public string MobileNum { get; set; } } // 发起人 public class MobileOwner { // 发起人需要保存的内部状态 public List<ContactPerson> ContactPersons { get; set; } public MobileOwner(List<ContactPerson> persons) { ContactPersons = persons; } // 创建备忘录，将当期要保存的联系人列表导入到备忘录中 public ContactMemento CreateMemento() { // 这里也应该传递深拷贝，new List方式传递的是浅拷贝， // 因为ContactPerson类中都是string类型,所以这里new list方式对ContactPerson对象执行了深拷贝 // 如果ContactPerson包括非string的引用类型就会有问题，所以这里也应该用序列化传递深拷贝 return new ContactMemento(new List<ContactPerson>(this.ContactPersons)); } // 将备忘录中的数据备份导入到联系人列表中 public void RestoreMemento(ContactMemento memento) { // 下面这种方式是错误的，因为这样传递的是引用， // 则删除一次可以恢复，但恢复之后再删除的话就恢复不了.因为这次保存的地址是备忘录里面的地址！！再次删除会导致备忘录的地址也删除了！（相当于第二次删除把备忘录内部的数据也删除了） // 所以应该传递contactPersonBack的深拷贝，深拷贝可以使用序列化来完成 this.ContactPersons = memento.contactPersonBack; } public void Show() { Console.WriteLine("联系人列表中有{0}个人，他们是:", ContactPersons.Count); foreach (ContactPerson p in ContactPersons) { Console.WriteLine("姓名: {0} 号码为: {1}", p.Name, p.MobileNum); } } // 备忘录 public class ContactMemento { // 保存发起人的内部状态 public List<ContactPerson> contactPersonBack; public ContactMemento(List<ContactPerson> persons) { contactPersonBack = persons; } } // 管理角色 public class Caretaker { public ContactMemento ContactM { get; set; } } class Program { static void Main(string[] args) { List<ContactPerson> persons = new List<ContactPerson>() { new ContactPerson() { Name= "Learning Hard", MobileNum = "123445"}, new ContactPerson() { Name = "Tony", MobileNum = "234565"}, new ContactPerson() { Name = "Jock", MobileNum = "231455"} }; MobileOwner mobileOwner = new MobileOwner(persons); mobileOwner.Show(); // 创建备忘录并保存备忘录对象 Caretaker caretaker = new Caretaker(); caretaker.ContactM = mobileOwner.CreateMemento(); // 更改发起人联系人列表 Console.WriteLine("----移除最后一个联系人--------"); mobileOwner.ContactPersons.RemoveAt(2); mobileOwner.Show(); // 恢复到原始状态 Console.WriteLine("-------恢复联系人列表------"); mobileOwner.RestoreMemento(caretaker.ContactM); mobileOwner.Show(); Console.Read(); } }
具体的运行结果如下图所示：
从上图可以看出，刚开始通讯录中有3个联系人，然后移除以后一个后变成2个联系人了，最后恢复原来的联系人列表后，联系人列表中又恢复为3个联系人了。
上面代码只是保存了一个还原点，即备忘录中只保存了3个联系人的数据，但是，如果想备份多个还原点怎么办呢？即恢复到3个人后，又想恢复到前面2个人的状态，这时候可能你会想，这样没必要啊，到时候在删除不就好了。但是如果在实际应用中，可能我们发了很多时间去创建通讯录中只有2个联系人的状态，恢复到3个人的状态后，发现这个状态时错误的，还是原来2个人的状态是正确的，难道我们又去花之前的那么多时间去重复操作吗？这显然不合理，如果就思考，能不能保存多个还原点呢？保存多个还原点其实很简单，只需要保存多个备忘录对象就可以了。具体实现代码如下所示：
namespace MultipleMementoPattern { // 联系人 public class ContactPerson { public string Name { get; set; } public string MobileNum { get; set; } } // 发起人 public class MobileOwner { public List<ContactPerson> ContactPersons { get; set; } public MobileOwner(List<ContactPerson> persons) { ContactPersons = persons; } // 创建备忘录，将当期要保存的联系人列表导入到备忘录中 public ContactMemento CreateMemento() { // 这里也应该传递深拷贝，new List方式传递的是浅拷贝， // 因为ContactPerson类中都是string类型,所以这里new list方式对ContactPerson对象执行了深拷贝 // 如果ContactPerson包括非string的引用类型就会有问题，所以这里也应该用序列化传递深拷贝 return new ContactMemento(new List<ContactPerson>(this.ContactPersons)); } // 将备忘录中的数据备份导入到联系人列表中 public void RestoreMemento(ContactMemento memento) { if (memento != null) { // 下面这种方式是错误的，因为这样传递的是引用， // 则删除一次可以恢复，但恢复之后再删除的话就恢复不了. // 所以应该传递contactPersonBack的深拷贝，深拷贝可以使用序列化来完成 this.ContactPersons = memento.ContactPersonBack; } } public void Show() { Console.WriteLine("联系人列表中有{0}个人，他们是:", ContactPersons.Count); foreach (ContactPerson p in ContactPersons) { Console.WriteLine("姓名: {0} 号码为: {1}", p.Name, p.MobileNum); } } } // 备忘录 public class ContactMemento { public List<ContactPerson> ContactPersonBack {get;set;} public ContactMemento(List<ContactPerson> persons) { ContactPersonBack = persons; } } // 管理角色 public class Caretaker { // 使用多个备忘录来存储多个备份点 public Dictionary<string, ContactMemento> ContactMementoDic { get; set; } public Caretaker() { ContactMementoDic = new Dictionary<string, ContactMemento>(); } } class Program { static void Main(string[] args) { List<ContactPerson> persons = new List<ContactPerson>() { new ContactPerson() { Name= "Learning Hard", MobileNum = "123445"}, new ContactPerson() { Name = "Tony", MobileNum = "234565"}, new ContactPerson() { Name = "Jock", MobileNum = "231455"} }; MobileOwner mobileOwner = new MobileOwner(persons); mobileOwner.Show(); // 创建备忘录并保存备忘录对象 Caretaker caretaker = new Caretaker(); caretaker.ContactMementoDic.Add(DateTime.Now.ToString(), mobileOwner.CreateMemento()); // 更改发起人联系人列表 Console.WriteLine("----移除最后一个联系人--------"); mobileOwner.ContactPersons.RemoveAt(2); mobileOwner.Show(); // 创建第二个备份 Thread.Sleep(1000); caretaker.ContactMementoDic.Add(DateTime.Now.ToString(), mobileOwner.CreateMemento()); // 恢复到原始状态 Console.WriteLine("-------恢复联系人列表,请从以下列表选择恢复的日期------"); var keyCollection = caretaker.ContactMementoDic.Keys; foreach (string k in keyCollection) { Console.WriteLine("Key = {0}", k); } while (true) { Console.Write("请输入数字,按窗口的关闭键退出:"); int index = -1; try { index = Int32.Parse(Console.ReadLine()); } catch { Console.WriteLine("输入的格式错误"); continue; } ContactMemento contactMentor = null; if (index < keyCollection.Count && caretaker.ContactMementoDic.TryGetValue(keyCollection.ElementAt(index), out contactMentor)) { mobileOwner.RestoreMemento(contactMentor); mobileOwner.Show(); } else { Console.WriteLine("输入的索引大于集合长度！"); } } } } }
这样就保存了多个状态，客户端可以选择恢复的状态点，具体运行结果如下所示：
在以下情况下可以考虑使用备忘录模式：
如果系统需要提供回滚操作时，使用备忘录模式非常合适。例如文本编辑器的Ctrl+Z撤销操作的实现，数据库中事务操作。
备忘录模式具有以下优点：
A如果某个操作错误地破坏了数据的完整性，此时可以使用备忘录模式将数据恢复成原来正确的数据。
B备份的状态数据保存在发起人角色之外，这样发起人就不需要对各个备份的状态进行管理。而是由备忘录角色进行管理，而备忘录角色又是由管理者角色管理，符合单一职责原则。
当然，备忘录模式也存在一定的缺点：
在实际的系统中，可能需要维护多个备份，需要额外的资源，这样对资源的消耗比较严重。
访问者模式是封装一些施加于某种数据结构之上的操作。一旦这些操作需要修改的话，接受这个操作的数据结构则可以保存不变。访问者模式适用于数据结构相对稳定的系统， 它把数据结构和作用于数据结构之上的操作之间的耦合度降低，使得操作集合可以相对自由地改变。
具体结构图如下所示：
这里需要明确一点：访问者模式中具体访问者的数目和具体节点的数目没有任何关系。从访问者的结构图可以看出，访问者模式涉及以下几类角色。
抽象访问者角色（Vistor）:声明一个或多个访问操作，使得所有具体访问者必须实现的接口。
具体访问者角色（ConcreteVistor）：实现抽象访问者角色中所有声明的接口。
抽象节点角色（Element）：声明一个接受操作，接受一个访问者对象作为参数。
具体节点角色（ConcreteElement）：实现抽象元素所规定的接受操作。
结构对象角色（ObjectStructure）：节点的容器，可以包含多个不同类或接口的容器。
不用访问者模式的方式来实现某个场景。具体场景是——现在我想遍历每个元素对象，然后调用每个元素对象的Print方法来打印该元素对象的信息。如果此时不采用访问者模式的话，实现这个场景再简单不过了，具体实现代码如下所示：
namespace DonotUsevistorPattern { // 抽象元素角色 public abstract class Element { public abstract void Print(); } // 具体元素A public class ElementA : Element { public override void Print() { Console.WriteLine("我是元素A"); } } // 具体元素B public class ElementB : Element { public override void Print() { Console.WriteLine("我是元素B"); } } // 对象结构 public class ObjectStructure { private ArrayList elements = new ArrayList(); public ArrayList Elements { get { return elements; } } public ObjectStructure() { Random ran = new Random(); for (int i = 0; i < 6; i++) { int ranNum = ran.Next(10); if (ranNum > 5) { elements.Add(new ElementA()); } else { elements.Add(new ElementB()); } } } } class Program { static void Main(string[] args) { ObjectStructure objectStructure = new ObjectStructure(); // 遍历对象结构中的对象集合，访问每个元素的Print方法打印元素信息 foreach (Element e in objectStructure.Elements) { e.Print(); } Console.Read(); } } }
上面代码很准确了解决了我们刚才提出的场景，但是需求在时刻变化的，如果此时，我除了想打印元素的信息外，还想打印出元素被访问的时间，此时我们就不得不去修改每个元素的Print方法，再加入相对应的输入访问时间的输出信息。这样的设计显然不符合“开-闭”原则，即某个方法操作的改变，会使得必须去更改每个元素类。既然，这里变化的点是操作的改变，而每个元素的数据结构是不变的。所以此时就思考——能不能把操作于元素的操作和元素本身的数据结构分开呢？解开这两者的耦合度，这样如果是操作发现变化时，就不需要去更改元素本身了，但是如果是元素数据结构发现变化，例如，添加了某个字段，这样就不得不去修改元素类了。此时，我们可以使用访问者模式来解决这个问题，即把作用于具体元素的操作由访问者对象来调用。具体的实现代码如下所示：
namespace VistorPattern { // 抽象元素角色 public abstract class Element { public abstract void Accept(IVistor vistor); public abstract void Print(); // 具体元素A public class ElementA :Element { public override void Accept(IVistor vistor) { // 调用访问者visit方法 vistor.Visit(this); } public override void Print() { Console.WriteLine("我是元素A"); } } // 具体元素B public class ElementB :Element { public override void Accept(IVistor vistor) { vistor.Visit(this); } public override void Print() { Console.WriteLine("我是元素B"); } } // 抽象访问者 public interface IVistor { void Visit(ElementA a); void Visit(ElementB b); } // 具体访问者 public class ConcreteVistor :IVistor { // visit方法而是再去调用元素的Accept方法 public void Visit(ElementA a) { a.Print(); } public void Visit(ElementB b) { b.Print(); } } // 对象结构 public class ObjectStructure { private ArrayList elements = new ArrayList(); public ArrayList Elements { get { return elements; } } public ObjectStructure() { Random ran = new Random(); for (int i = 0; i < 6; i++) { int ranNum = ran.Next(10); if (ranNum > 5) { elements.Add(new ElementA()); } else { elements.Add(new ElementB()); } } } } class Program { static void Main(string[] args) { ObjectStructure objectStructure = new ObjectStructure(); foreach (Element e in objectStructure.Elements) { // 每个元素接受访问者访问 e.Accept(new ConcreteVistor()); } Console.Read(); } } }
从上面代码可知，使用访问者模式实现上面场景后，元素Print方法的访问封装到了访问者对象中了（我觉得可以把Print方法封装到具体访问者对象中。），此时客户端与元素的Print方法就隔离开了。此时，如果需要添加打印访问时间的需求时，此时只需要再添加一个具体的访问者类即可。此时就不需要去修改元素中的Print()方法了。
每个设计模式都有其应当使用的情况，那让我们看看访问者模式具体应用场景。如果遇到以下场景，此时我们可以考虑使用访问者模式。
A如果系统有比较稳定的数据结构，而又有易于变化的算法时，此时可以考虑使用访问者模式。因为访问者模式使得算法操作的添加比较容易。
B如果一组类中，存在着相似的操作，为了避免出现大量重复的代码，可以考虑把重复的操作封装到访问者中。（当然也可以考虑使用抽象类了）
C如果一个对象存在着一些与本身对象不相干，或关系比较弱的操作时，为了避免操作污染这个对象，则可以考虑把这些操作封装到访问者对象中。
访问者模式具有以下优点：
A访问者模式使得添加新的操作变得容易。如果一些操作依赖于一个复杂的结构对象的话，那么一般而言，添加新的操作会变得很复杂。而使用访问者模式，增加新的操作就意味着添加一个新的访问者类。因此，使得添加新的操作变得容易。
B访问者模式使得有关的行为操作集中到一个访问者对象中，而不是分散到一个个的元素类中。这点类似与"中介者模式"。
C访问者模式可以访问属于不同的等级结构的成员对象，而迭代只能访问属于同一个等级结构的成员对象。
访问者模式也有如下的缺点：
增加新的元素类变得困难。每增加一个新的元素意味着要在抽象访问者角色中增加一个新的抽象操作，并在每一个具体访问者类中添加相应的具体操作。
解释器模式是一个比较少用的模式，所以我自己也没有对该模式进行深入研究，在生活中，英汉词典的作用就是实现英文和中文互译，这就是解释器模式的应用。
解释器模式是给定一种语言，定义它文法的一种表示，并定义一种解释器，这个解释器使用该表示来解释器语言中的句子。具体的结构图如下所示：
标签：逆序 pattern target element 变化 工资 random 耦合度 角色
原文地址：https://www.cnblogs.com/qixinbo/p/9193258.html
