【设计模式】行为型模式
模板方法模式：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
特点：
-
通过把不变行为搬移到超类，去除子类中的重复代码来体现它的优势。
-
提供了一个很好的代码复用平台
-
当不变的和可变的行为在方法的子类实现中混合在一起的时候，不变的行为就会在子类中重复出现。我们通过模板方法模式把这些行为搬移到单一的地方，这样就帮助子类摆脱重复的不变行为的纠缠。
命令模式（Command）：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。
命令模式的优点：
1.他能较容易的设计一个命令队列
2.在需要的情况下，可以较容易的将命令计入日志
3.允许接受请求的一方决定是否要否决请求
4.可以容易的实现队请求的撤销和重做，
5.由于加进新的具体命令类不影响其他的类，因此增加新的具体命令类很容易
6.命令模式把请求一个操作的对象与指导怎么执行一个操作的对象分隔开。
敏捷开发原则告诉我们：
不要为代码添加基于猜测的、实际不需要的功能。如果不清楚一个系统是否需要命令模式，一般就不要着急去实现它，事实上，在需要的时候通过重构实现这个模式并不困难，只有在真正需要如撤销/恢复操作等功能时，把原来的代码重构为命令模式才有意义。
迭代器模式：提供一种方法顺序访问一个聚合对象中各个元素，而又不暴露该对象的内部表示。
何时考虑使用迭代器模式：
当你需要访问一个聚集对象，而且不管这些对象是什么都需要遍历的时候，你就应该考虑用迭代器模式。
你需要对聚集有多种方式遍历时，可以考虑使用迭代器模式。
为遍历不同的聚集结构提供如开始、下一个、是否结束、当前哪一项等统一的接口。
迭代器模式就是分离了集合对象的遍历行为，抽象出一个迭代类来负责，这样既可以做到不暴露集合的内部结构，又可让外部代码透明的访问集合内部的数据。
观察者模式：定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，使他们能够自动更新自己。
观察者模式的动机：
将一个系统分割成一系列相互协作的类有一个很不好的副作用，那就是需要维护相关对象间的一致性。我们不希望为了维持一致性而使各类紧密耦合，这样会给维护、扩展和重用都带来不便。
何时使用观察者模式：
-
当一个对象的改变需要同时改变其他对象的时候
-
而且它不知道具体有多少对象有待改变时，应该考虑使用观察者模式
-
当一个抽象模型有两个方面，其中一方面依赖于另一方面，这时用观察者模式可以将这两者封装在独立的对象中使他们各自独立地改变和复用
观察者模式所做的工作其实就是在解除耦合。让耦合的双方都依赖于抽象，而不是依赖于具体。从而使得各自的变化都不会影响另一边的变化。
委托：就是一种引用方法的类型。一旦为委托分配了方法，委托将与该方法具有完全相同的行为。委托方法的使用可以像其他任何方法一样，具有参数和返回值。
委托可以看做是对抽象函数的抽象，是函数的“类”，委托的实例将代表一个具体的函数。
一个委托可以搭载多个方法，所有方法被一次唤起，他可以使得委托对象所搭载的方法并不需要属于同一各类。
中介者模式（Mediator）：用一个中介者来封装一系列的对象交互。中介者使各对象不需要显示的相互引用，从而使其耦合松散，而且可以独立的改变他们之间的交互。
为什么要使用中介者模式：
1.将一个系统分割成许多对象通常可以增加其可复用性，但是对象间相互连接的激增又会降低其可复用性了
2.大量的连接使得一个对象不可能在没有其他对象的支持下工作，系统表现为一个不可分割的整体，所以，对系统的行为进行任何较大的改动就十分困难了。
使用中介者模式需要注意的：
中介者模式很容易在系统中应用，也很容易在系统中误用。当系统出现了“多对多”交互复杂的对象群时，不要急于使用中介者模式，而要先反思你的系统在设计上是不是合理。
中介者模式的优缺点：
优点：
1.Mediator的出现减少了各个Colleague的耦合，使得可以对立的改变和复用各个Colleague类和Mediator。由于把对象如何写作进行了抽象，将中介作为一个独立的概念并将其封装在一个对象中，这样关注的对象就从对象各自本身的行为转移到他们之间的交互上来，也就是站在一个更宏观的角度去看待系统。
缺点：
1.由于ConcreteMediator控制了集中化，于是就把交互复杂性变成了中介者的复杂性，这就使得中介者会变得比任何一个ConcreteColleague都复杂
中介者模式一般以用于一组对象以定义良好但是复杂的方式进行通信的场合，以及想定制一个分部在多个类中的行为，而又不想生成太多的子类的场合。
备忘录（Memento）：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。
解释器模式（interpreter）：给定一个语言，定义他的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
解释器模式需要解决的是：
如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题。
解释器模式的好处：
1.当有一个语言需要解释执行，并且你可将该语言中的句子表示为一个抽象语法树时，可使用解释器模式。
2.容易地改变和扩展文法，因为该模式使用类来表示文法规则，你可使用继承来改变或扩展该文法。也比较容易实现文法，因为抽象语法树中各个结点的类的实现大体类似，这些都易于直接编写。
解释器模式的缺点：
1.解释器模式为文法中的每一条规则至少定义了一个类，因此包含许多规则的文法可能难以管理和维护。建议当文法非常复杂时，使用其他的技术如语法分析程序或编译器生成器来处理。
状态模式（State）：当一个对象在状态改变时允许改变其行为，这个对象看起来像是改变了其类。
状态模式主要解决的是当控制一个对象状态转换的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类当中，可以把复杂的判断逻辑简化。
好处：
1.将与特定状态相关的行为局部化，并且将不同状态的行为分隔开来。
2.将特定的状态相关的行为都放入一个对象中，由于所有状态相关的代码都存在于某个ConcreteState中，所以通过定义新的子类可以很容易的增加新的状态和转换。
3.消除庞大的条件分支语句
4.状态模式通过吧各种状态转移逻辑分布到State的子类之间，来减少相互间的依赖。
何时使用状态模式：
当一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为时，就可以考虑使用状态模式。
策略模式（Strategy）：它定义了算法家族，分别封装起来，让他们之间可以相互替换，此模式让算法的变化，不会影响到使用算法的客户。
策略模式是一种定义一系列算法的方法，从概念上来看，所有这些算法完成的都是相同的工作，只是实现不同，它可以以相同的方式调用所有的算法，减少了各种算法类与使用算法类之间的耦合。
优点：
1.策略模式的Strategy类层次为Context定义了一系列的可供重用的算法和行为。继承有助于析取出这些算法中的公共功能。
2.策略模式的优点是简化了单元测试，因为每个算法都有自己的类，可以通过自己的接口单独测试。
策略模式封装了变化
策略模式就是用来封装算法的，但在实践中，我们发现可以用它来封装几乎任何类型的规则，只要在分析过程中听到需要在不同的业务规则，就可以考虑使用策略模式处理这种变化的可能性。
职责链模式（Chain Of Responsibility）：使多个对象都有处理请求，从而避免请求的发送者和接受者之间的耦合关系。将这个对象练成一条链，并沿着这条链传递该请求，直到有一个对象处理他为止。
职责链的好处：
1.这当中最关键的是当客户提交一个请求时，请求时沿链传递直至有一个ConcreHandler对象负责处理它。
2.接受者和发送者都没有对方的明确信息，且链中的对象自己的也并不知道链的结构。结果是职责链可简化对象的相互连接。他们仅需要一个指向其后继者的引用，而不需要保持他所有的候选接受者的引用。
3.随时的增加或修改处理一个请求的结构。增强了给对象指派职责的灵活性。
4.一个请求极有可能到了链的末端都得不到处理，或者因为没有正确配置而得不到处理。
访问者模式（Visitor）：表示一个作用某对象中的各元素的操作。他使你可以在不改变各元素的类的前提下定义这些元素的新操作。
访问者模式适用于数据结构稳定的系统
访问者模式把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集合可以相对自由地演化
访问者模式的目的：
1.是要把处理从数据结构分离出来。一个系统由比较稳定的数据结构，又有易于变化的算法的话，使用访问者模式时比较合适的，因为访问者模式使得算法操作的增加变得容易。
2.访问者模式的优点就是增加新的操作很容易，因为增加新的操作就意味着增加一个新的访问者。访问者模式将有关的行为集中到一个访问者对象中。
缺点：
使增加新的数据结构变得困难了。
文章来源: blog.csdn.net，作者：翟文彪，版权归原作者所有，如需转载，请联系作者。
原文链接：blog.csdn.net/zwb568/article/details/108326158
- 点赞
- 收藏
- 关注作者
评论（0）