每天进步一点点---------设计模式JAVA 第三天

模板设计模式

首先，我们看一下模板设计模式的定义，定义一个操作中的算法骨架，而将算法的一些步骤延迟到子类中，使得子类可以不改变该算法结构的情况下重定义该算法的某些特定步骤。它是一种类行为型模式。
行为性模式主要用于描述类或对象的交互以及职责分配，可以认为是以行为为主要目标的设计模式。
那么，模板设计模式最基本的应用是什么呢？引用大神的一篇悍马为例的博客，（https://blog.csdn.net/eson_15/article/details/51323902），我们来用悍马为例的UML类图进行一下分析。

其中，HummerModel是抽象类，抽象方法包含alarm,run,start,stop，run为公共行为（驾考科三步骤，先系安全带，调座椅，按喇叭，开火），此处只做了按喇叭和开火
子类继承父类后，也就有了按喇叭和开火的run公共方法，就可以直接使用了。
那么，此模型的扩展性如何呢？
（1）如果想拓展一种悍马型号，那肯定很简单，只需添加一个H3即可，如果型号过多，也会出现类爆炸的问题，类爆炸可以参考桥接设计模式，能否将实现和抽象分离开。
（2）如果想修改一下行为，子类实现的行为可以在子类直接修改，公共类run的修改，会影响到所有子类型号。
（3）如果子类不想有部分方法，比如出了悍马4，只能响喇叭，不能跑（这车有啥用），那么可以使用钩子方法，即当钩子方法返回true的时候，行为才会调用某一方法。
（4）如果想多创建一个模板呢？那么就要考虑是否适合模板方法了，因为模板方法的适用于方法流程类似的方法。
（5）模板方法使用final，防止子类重写模板方法

命令设计模式

命令设计模式感觉是将组件的行为整合成一个同一的命令控制，我们看一下命令设计模式的定义：命令的责任和执行命令的责任分割开，委派给不同的对象。
以尚硅谷 韩老师课程中的例子为例，使LightOn和LightOff都继承Commond接口，其实调用的是自己的成员变量LightReceiver的on和off方法控制电灯的开和关。RemoteController(遥控器)构造成空命令，然后将灯的开关命令设置进去，如果系统固定的话，这部分其实应该由系统自己搞的。
其它讲的比较好的例子也可以查看大神的博客《https://blog.csdn.net/chunqiuwei/article/details/79030816》

那么，此模型的扩展性如何呢？
（1）如果新增一个组件，仅需搞组件的命令和初始化操作即可对外提供统一接口
关注点：
（1）空命令是一种很好的防止null命令的方法
（2）如果命令很多，会造成类爆炸，但是还是会比较容易理解

访问者设计模式

大神的博客讲解很清晰《https://www.jianshu.com/p/1f1049d0a0f4》，为方便个人理解，做下面的笔记。

访问者模式是针对将数据结构与数据操作分离，并且数据结构不变而操作易变的情况，此时增加一个操作，将变的很简单，感觉尚硅谷例子中的display应该只用于展示，即attach的Member带有操作，这样就变成了人成员去选择，ObjectStructor仅做收集的作用。
扩展性：
（1）仅针对数据结构固定的，如果这个不固定，将修改很大，对所有操作都需要修改
（2）操作依赖的是具体的Man，而不是Member，违反依赖倒置原则，没有依赖接口
（3）Man依赖于Member的方法，违反迪米特原则，知道的有点多

观察者设计模式

我们先看一下观察者的定义：多个对象间存在一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。这种模式有时又称作发布-订阅模式、模型-视图模式，它是对象行为型模式。
这种模式的应用应该会十分的广泛，微服务中好多对象是依赖于数据库中的数据的，如果数据发生变化，对象也应该发生变化。

中介者设计模式

先看一把定义：用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
感觉和命令模式呀、外观模式呀还是很相似的，都是将内部复杂的交流，提出一个中介类，用于返回统一接口，有点类似于中间层的概念，比如SpringMVC中的C层。

备忘录设计模式

先看一下定义：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态
备忘录的应用是很多的，比如游戏存档，我们玩游戏的时候肯定有存档功能，旨在下一次登录游戏时可以从上次退出的地方继续游戏，或者对复活点进行存档，如果挂掉了则可以读取复活点的存档信息重新开始。与之相类似的就是数据库的事务回滚，或者重做日志redo log等。
如果直接clone，会造成数据很大，并且暴露的细节，所以现在的游戏都是有存档点，可以恢复到哪一个位置，状态也只需要修改需要变更的那部分即可。

解释器设计模式

看一下定义：给定一个语言，定义它的文法表示，并定义一个解释器，这个解释器使用该标识来解释语言中的句子。
和语言解释、运算计算等感觉一致

状态设计模式

定义：允许一个对象在其内部状态改变时改变它的行为，即状态和行为是一一对应的，状态之间可以转换。
UML有一个图叫做状态图，也有一大类的问题是可以使用状态机解决的，状态模式的应用应该也会很多。

扩展性：
（1）状态表达很清晰，状态增减简单，但是活动的表现依赖活动，可以优化活动类。
（2）适用于状态转换的场景

策略设计模式

我们看一下定义，定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换，在有多种算法相似的情况下，使用 if…else 所带来的复杂和难以维护，一个系统有许多许多类，而区分它们的只是他们直接的行为。
通过尚硅谷 韩老师的鸭子课程，是将行为作为算法抽取，实现Context的时候给定策略就可以了。

扩展性：
（1）当新增策略的时候，如果在StrategyA或者B中的，可以直接添加，如果需要增加一个StrategyC，则需要修改Context了
（2）关键是分析变化部分和不变部分，好像所有设计模式都需要这一步
（3）按照行为细化，也有可能会造成类爆炸

职责链设计模式

看一下定义，避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。
这个和OS的防火墙是很相似的，链状处理，策略的修改，仅需要修改一个链就可以，不会影响其它的链，但是感觉是需要防止环的出现的。