设计模式与抽象 四 行为模式

行为型模式

这些设计模式特别关注对象之间的通信。

•责任链模式（Chain of Responsibility Pattern）：拦截的类都实现统一接口，每个接收者都包含对下一个接收者的引用。将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。

•观察者模式（Observer Pattern）：一对多的依赖关系，在观察目标类里有一个 ArrayList 存放观察者们。当观察目标对象的状态发生改变，所有依赖于它的观察者都将得到通知，使这些观察者能够自动更新（即使用推送方式）

•模板模式（Template Pattern）：将这些通用算法抽象出来，在一个抽象类中公开定义了执行它的方法的方式/模板。它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行

•命令模式（Command Pattern）：将"行为请求者"与"行为实现者"解耦：调用者依赖命令，命令依赖接收者，调用者Invoker→命令Command→接收者Receiver
访问者模式（Visitor Pattern）：在不改变数据结构的前提下，增加作用于一组对象元素的新功能。

•解释器模式（Interpreter Pattern）：给定一个语言，定义它的文法表示，并定义一个解释器，这个解释器使用该标识来解释语言中的句子

•迭代器模式（Iterator Pattern）：集合中含有迭代器：分离了集合对象的遍历行为，抽象出一个迭代器类来负责，无须暴露该对象的内部表示

•中介者模式（Mediator Pattern）：对象与对象之间存在大量的关联关系，将对象之间的通信关联关系封装到一个中介类中单独处理，从而使其耦合松散，可以独立地改变它们之间的交互

•策略模式（Strategy Pattern）：策略对象依赖注入到context对象，context对象根据它的策略改变而改变它的相关行为(可通过调用内部的策略对象实现相应的具体策略行为)

•状态模式（State Pattern）：状态对象依赖注入到context对象，context对象根据它的状态改变而改变它的相关行为(可通过调用内部的状态对象实现相应的具体行为)

•备忘录模式（Memento Pattern）：通过一个备忘录类专门存储对象状态。客户通过备忘录管理类管理备忘录类。

1.责任链模式

职责链模式描述的请求如何沿着对象所组成的链来传递的,重在责任分离处理，让各个节点各司其职。

1、降低耦合度。它将请求的发送者和接收者解耦。

2、增强给对象指派职责的灵活性。通过改变链内的成员或者调动它们的次序，允许动态地新增或者删除责任。

3、增加新的请求处理类很方便。

2.观察者模式

主题和观察者之间以松耦合的方式结合，可以根据需要增加和删除观察者，使得系统更易于扩展。

观察者模式定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。

3.模板模式

例子:JdbcTemplate

定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。

4.命令模式

顺序：调用者Invoker→命令Command→接收者Receiver

例子: new Thread(new Runnable(){}).start()

命令模式可以将请求的发送者和接收者之间实现完全的解耦，发送者和接收者之间没有直接的联系，发送者只需要知道如何发送请求命令即可

发送一个请求，但是我们并不知道该请求的具体接收者是谁，具体的处理过程是如何的，这样的情况，适用命令模式。

5.解释器模式

所谓解释器模式就是定义语言的文法，并且建立一个解释器来解释该语言中的句子。解释器模式描述了如何构成一个简单的语言解释器，主要应用在使用面向对象语言开发的编译器中。

6.迭代器模式

迭代器模式提供了遍历容器的方便性，容器只要管理增减元素就可以了，需要遍历时交由迭代器进行

7.中介者模式

中介者模式就是用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。在中介者模式中，中介对象用来封装对象之间的关系，各个对象可以不需要知道具体的信息通过中介者对象就可以实现相互通信。

8.中介者模式

1、降低了类的复杂度，将一对多转化成了一对一。

2、各个类之间的解耦。

9.策略模式

策略模式就是定义了算法族，分别封装起来，让他们之间可以互相转换，此模式让该算法的变化独立于使用算法的客户。

优点： 1、算法可以自由切换。 2、避免使用多重条件判断。 3、扩展性良好。

10. 状态模式

在很多情况下我们对象的行为依赖于它的一个或者多个变化的属性，这些可变的属性我们称之为状态，也就是说行为依赖状态，即当该对象因为在外部的互动而导致他的状态发生变化，从而它的行为也会做出相应的变化。对于这种情况，我们是不能用行为来控制状态的变化，而应该站在状态的角度来思考行为，即是什么状态就要做出什么样的行为。这个就是状态模式。

同时状态模式是将所有与某个状态有关的行为放到一个类中，并且可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为。

11.备忘录模式

备忘录模式就是在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样可以在以后将对象恢复到原先保存的状态。它实现了对信息的封装，使得客户不需要关心状态保存的细节。

12.访问者模式

访问者模式是一种将数据操作与数据结构分离的设计模式；封装一些作用于某种数据结构中的各元素的操作，它可以在不改变这个数据结构的前提下定义作用于这些元素的新的操作。

过度抽象

使用设计模式时，如何判断一个问题是否被“过度抽象”了

以解决问题作为驱动，设计模式的目的是为了降低代码耦合和重复，以及使代码有更好的表现力，不要为了用技术而用技术。

开发时，不要专门想着去“套”某个设计模式，设计模式不是数学公式。
要先弄明白你想做哪件事，面临的困难和问题是什么，如果你能想到某个设计模式正好适用，当然可以拿来就用，否则，就自己设计，尽力用最简单的方式（也许是比较“野蛮”的“仅适用于此地”的方式）去解决。日后也许你有了新的思路和想法，发现了你原有代码缺陷，或者是知道了你原先不知道的某个设计模式比你原有解决方案更好，你可以重构代码以提升你代码的可维护性。
简单地说：可以把设计模式的应用推迟到代码重构阶段。设计模式是把双刃剑，用得不好，反而让代码变得复杂，难于理解和维护，伤人伤己。

SOLID原则

面向对象设计的六大原则

•单一职责原则（SRP）：一个类只能有一个职责并且只完成为它设计的功能任务。

•开闭原则（OCP）：对扩展开放，对修改封闭(open for extension, close for modification)。

•里氏替换原则（LSP）：所有基类出现的地方都可以用派生类替换而不会程序产生错误。子类可以扩展父类的功能，但不能改变父类原有的功能。

•迪米特法则（ LoD ） ：也叫最少知道原则（Least Knowledge Principle, LKP ）,一一个对象应该对其他对象有最少的了解。1、只和朋友交流，降低类之间的耦合，减少不必要的依赖；2. 类成员不需要对外提供的，就用private。

•接口隔离原则（ISP）：多个专用的接口比一个通用接口好,这个原则定义了一个类决不要实现不会用到的接口。

•依赖倒转原则 （ DIP ） ：一个特定的类不应该直接依赖于另外一个类，应该依赖于这个类的抽象（接口）。

 

 

 

欢迎关注公众号：“架构一线”，定期分享一些实战心得，互联网前沿技术等.