2020-03-16

庚子鼠年 己卯月 戊午日

描述

学习中介者模式，备忘录模式，解释器模式，状态模式，责任链模式

随笔

中介者模式

​ 参考博客：点我

​ 中介者对象封装了一系列的对象交互，中介者使各对象不需要彼此联系来相互作用，从而使耦合松散，而且可以独立的改变他们之间的交互。

应用场景

​ 当有多个对象彼此间相互交互的时候，自然就会想到对象间的耦合度过高，解决办法就是封装对象间的交互行为，因此就能想到中介者模式就是干这行的。

中介者模式角色组成

1. 抽象中介者（mediator）定义一个接口用于和对象通信（SmartDevice）依赖于抽象同事角色

2. 具体中介者（concretemediator）协调各同事对象实现协作，了解维护各个同事()

3. 抽象同事角色（colleague）规定了同事的基本类型

4. 具体同事角色（concreteColleague）每个同事都知道中介者对象，要与同事通信则把通信告诉中介者

备忘录模式

​ 参考博客：https://blog.csdn.net/weixin_42746530/article/details/91044483

核心类说明：

1. Originator：需要被备份的对象(用于操作State的)
2. State：对象属性对象
3. Memento：备忘录对象（需要传入State）
4. Caretaker：备忘录管理对象，维护所有备忘录

优缺点
备忘录模式将需要保存的细节全部封装至备忘录对象中，使客户端不需要知道属性细节也可以进行保存和回滚，需要修改保存内容时修改备忘录对象即可。

​ 备忘录模式通过对象保存内容，一旦滥用就意味着会产生大量的备忘录对象，在保存的内容又特别多的时候将十分占用内存，同时由于其内容保存在内存中，数据十分容易丢失。可以考虑将备忘录对象持久化到硬盘或数据库解决数据丢失问题。
笔者缺乏实际备忘录模式使用经验，以上问题仅供参考。

使用场景
Memento模式比较适用于功能比较复杂的，但需要维护或记录属性历史的类，或者需要保存的属性只是众多属性中的一小部分时，Originator可以根据保存的Memento信息还原到前一状态。

解释器模式

​ 参考博客：https://www.cnblogs.com/adamjwh/p/10938852.html

　解释器这个名词想必大家都不会陌生，比如编译原理中，一个算术表达式通过词法分析器形成词法单元，而后这些词法单元再通过语法分析器构建语法分析树，最终形成一颗抽象的语法分析树。诸如此类的例子也有很多，比如编译器、正则表达式等等。

　　如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子，这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题。

　　就比如正则表达式，它就是解释器模型的一种应用，解释器为正则表达式定义了一个文法，如何表示一个特定的正则表达式，以及如何解释这个正则表达式。

状态模式

参考博客：https://blog.csdn.net/xushiyu1996818/article/details/86719079

​ 状态模式用于解决系统中复杂对象的状态转换以及不同状态下行为的封装问题。当系统中某个对象存在多个状态，这些状态之间可以进行转换，而且对象在不同状态下行为不相同时可以使用状态模式。状态模式将一个对象的状态从该对象中分离出来，封装到专门的状态类中，使得对象状态可以灵活变化，对于客户端而言，无须关心对象状态的转换以及对象所处的当前状态，无论对于何种状态的对象，客户端都可以一致处理。

状态模式定义如下：

状态模式(State Pattern)：允许一个对象在其内部状态改变时改变它的行为，对象看起来似乎修改了它的类。其别名为状态对象(Objects for States)，状态模式是一种对象行为型模式。

策略模式

参考博客：https://www.cnblogs.com/lewis0077/p/5133812.html

策略这个词应该怎么理解，打个比方说，我们出门的时候会选择不同的出行方式，比如骑自行车、坐公交、坐火车、坐飞机、坐火箭等等，这些出行方式，每一种都是一个策略。

　　再比如我们去逛商场，商场现在正在搞活动，有打折的、有满减的、有返利的等等，其实不管商场如何进行促销，说到底都是一些算法，这些算法本身只是一种策略，并且这些算法是随时都可能互相替换的，比如针对同一件商品，今天打八折、明天满100减30，这些策略间是可以互换的。

　　策略模式（Strategy），定义了一组算法，将每个算法都封装起来，并且使它们之间可以互换。UML结构图如下：

策略模式的缺点：

1.客户端必须了解所有的策略，清楚它们的不同：

　　　　　如果由客户端来决定使用何种算法，那客户端必须知道所有的策略，清楚各个策略的功能和不同，这样才能做出正确的选择，但是这暴露了策略的具体实现。

　　2.增加了对象的数量：

　　　　由于策略模式将每个具体的算法都单独封装为一个策略类，如果可选的策略有很多的话，那对象的数量也会很多。

　　3.只适合偏平的算法结构：

　　　　由于策略模式的各个策略实现是平等的关系（可相互替换），实际上就构成了一个扁平的算法结构。即一个策略接口下面有多个平等的策略实现（多个策略实现是兄弟关系），并且运行时只能有一个算法被使用。这就限制了算法的使用层级，且不能被嵌套。

策略模式的本质：

　　分离算法，选择实现。

　　如果你仔细思考策略模式的结构和功能的话，就会发现：如果没有上下文，策略模式就回到了最基本的接口和实现了，只要是面向接口编程，就能够享受到面向接口编程带来的好处，通过一个统一的策略接口来封装和分离各个具体的策略实现，无需关系具体的策略实现。

　　貌似没有上下文什么事，但是如果没有上下文的话，客户端就必须直接和具体的策略实现进行交互了，尤其是需要提供一些公共功能或者是存储一些状态的时候，会大大增加客户端使用的难度；引入上下文之后，这部分工作可以由上下文来完成，客户端只需要和上下文进行交互就可以了。这样可以让策略模式更具有整体性，客户端也更加的简单。

　　策略模式体现了开闭原则：策略模式把一系列的可变算法进行封装，从而定义了良好的程序结构，在出现新的算法的时候，可以很容易的将新的算法实现加入到已有的系统中，而已有的实现不需要修改。

　　策略模式体现了里氏替换原则：策略模式是一个扁平的结构，各个策略实现都是兄弟关系，实现了同一个接口或者继承了同一个抽象类。这样只要使用策略的客户端保持面向抽象编程，就可以动态的切换不同的策略实现以进行替换。

责任链模式

参考博客：https://www.jianshu.com/p/9f7d9775bdda

​ 责任链，顾名思义，就是用来处理相关事务责任的一条执行链，执行链上有多个节点，每个节点都有机会（条件匹配）处理请求事务，如果某个节点处理完了就可以根据实际业务需求传递给下一个节点继续处理或者返回处理完毕。

角色

为了实现上述场景，我们可以采用责任链设计模式。

• 员工提交请求类：LeaveRequest。
• 抽象的请假责任处理类：AbstractLeaveHandler。
• 直接主管审批处理类：DirectLeaderLeaveHandler。
• 部门经理处理类：DeptManagerLeaveHandler。
• 总经理处理类： GManagerLeaveHandler。