Java 23种设计模式之行为型模式-全例子详解
设计模式的三个分类
-
创建型模式(5)：对象实例化的模式，创建型模式用于解耦对象的实例化过程。
-
结构型模式(7)：把类或对象结合在一起形成一个更大的结构。
-
行为型模式(11)：类和对象如何交互，及划分责任和算法。
其实还有两类：
- 并发型模式
- 线程池模式
用一个图片来整体描述一下：
上一篇文章主要说明了结构型模式。下面继续说明行为型模式
行为型模式的关键点
行为型模式用来识别对象之间的常用交流模式并加以实现。如此，可在进行这些交流活动时增强弹性。
| 范围 | 模式 | 特点 |
|---|---|---|
| 类模式 | 解释器模式 | 给定一个语言，定义它的文法的一种表示，并定义一个解释器。 |
| 类模式 | 模板模式 | 定义一个算法结构，而将一些步骤延迟到子类实现。 |
| 对象模式 | 责任链模式 | 将请求的发送者和接收者解耦，使的多个对象都有处理这个请求的机会。 |
| 对象模式 | 命令模式 | 将命令请求封装为一个对象，使得可以用不同的请求来进行参数化。 |
| 对象模式 | 迭代器模式 | 一种遍历访问聚合对象中各个元素的方法，不暴露该对象的内部结构。 |
| 对象模式 | 中介者模式 | 用一个中介对象来封装一系列的对象交互。 |
| 对象模式 | 备忘录模式 | 不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。 |
| 对象模式 | 观察者模式 | 定义了对象之间的一对多依赖关系。 |
| 对象模式 | 状态模式 | 允许一个对象在其对象内部状态改变时改变它的行为。 |
| 对象模式 | 策略模式 | 定义一系列算法，把他们封装起来，并且使它们可以相互替换。 |
| 对象模式 | 访问者模式 | 在不改变数据结构的前提下，增加作用于一组对象元素的新功能。 |
概说行为型设计模式
解释器模式
所谓解释器模式就是定义语言的文法，并且建立一个解释器来解释该语言中的句子。解释器模式描述了如何构成一个简单的语言解释器，主要应用在使用面向对象语言开发的编译器中。它描述了如何为简单的语言定义一个文法，如何在该语言中表示一个句子，以及如何解释这些句子。
模式结构
解释器模式包含如下角色：
- AbstractExpression: 抽象表达式
- TerminalExpression: 终结符表达式
- NonterminalExpression: 非终结符表达式
- Context: 环境类
- Client: 客户类
用大多数人举过的例子：简化的后缀表达式解释器（仅支持对整数的加法和乘法）
/**
* 定义抽象表达式接口
*/
public interface Interpreter {
int interpret();
}
/**
* 非终结符表达式，对整数进行解释
*/
public class NumberInterpreter implements Interpreter {
private int number;
public NumberInterpreter(int number) {
this.number = number;
}
public NumberInterpreter(String number) {
this.number = Integer.parseInt(number);
}
@Override
public int interpret() {
return this.number;
}
}
/**
* 加法的终结符表达式
*/
public class AddInterpreter implements Interpreter {
private Interpreter firstExpression, secondExpression;
public AddInterpreter(Interpreter firstExpression, Interpreter secondExpression) {
this.firstExpression = firstExpression;
this.secondExpression = secondExpression;
}
@Override
public int interpret() {
return this.firstExpression.interpret() + this.secondExpression.interpret();
}
@Override
public String toString() {
return "+";
}
}
/**
* 乘法的终结符表达式
*/
public class MultiInterpreter implements Interpreter {
private Interpreter firstExpression, secondExpression;
public MultiInterpreter(Interpreter firstExpression, Interpreter secondExpression) {
this.firstExpression = firstExpression;
this.secondExpression = secondExpression;
}
@Override
public int interpret() {
return this.firstExpression.interpret() * this.secondExpression.interpret();
}
@Override
public String toString() {
return "*";
}
}
由上面可以知道，如果需要扩展的话就需要不断添加新的解释类
/**
* 使用工具类装起来
*/
public class OperatorUtil {
public static boolean isOperator(String symbol) {
return (symbol.equals("+") || symbol.equals("*"));
}
public static Interpreter getExpressionObject(Interpreter firstExpression, Interpreter secondExpression, String symbol) {
if ("+".equals(symbol)) { // 加法
return new AddInterpreter(firstExpression, secondExpression);
} else if ("*".equals(symbol)) { // 乘法
return new MultiInterpreter(firstExpression, secondExpression);
} else {
throw new RuntimeException("不支持的操作符：" + symbol);
}
}
}
/**
* 转移器类
*/
public class MyExpressionParser {
private Stack<Interpreter> stack = new Stack<Interpreter>();
public int parser(String str) {
String[] strItemArray = str.split(" ");
for (String symbol : strItemArray) {
if (!OperatorUtil.isOperator(symbol)) {
Interpreter numberExpression = new NumberInterpreter(symbol);
stack.push(numberExpression);
System.out.println(String.format("入栈：%d", numberExpression.interpret()));
} else {
// 是运算符,可以计算
Interpreter firstExpression = stack.pop();
Interpreter secondExpression = stack.pop();
System.out.println(String.format("出栈：%d 和 %d", firstExpression.interpret(), secondExpression.interpret()));
Interpreter operator = OperatorUtil.getExpressionObject(firstExpression, secondExpression, symbol);
System.out.println(String.format("应用运算符：%s", operator));
int result = operator.interpret();
NumberInterpreter resultExpression = new NumberInterpreter(result);
stack.push(resultExpression);
System.out.println(String.format("阶段结果入栈：%d", resultExpression.interpret()));
}
}
int result = stack.pop().interpret();
return result;
}
}
测试使用
public class Test {
public static void main(String[] args) {
String inputStr = "6 100 11 + *";
MyExpressionParser expressionParser = new MyExpressionParser();
int result = expressionParser.parse(inputStr);
System.out.println("解释器计算结果: " + result);
}
// 运行结果
// 入栈: 6
// 入栈: 100
// 入栈: 11
// 出栈: 11 和 100
// 应用运算符: +
// 阶段结果入栈: 111
// 出栈: 111 和 6
// 应用运算符: *
// 阶段结果入栈: 666
// 解释器计算结果: 666
}
总结
意图：给定一个语言，定义它的文法表示，并定义一个解释器，这个解释器使用该标识来解释语言中的句子。
主要解决：对于一些固定文法构建一个解释句子的解释器。
何时使用：如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题。
如何解决：构建语法树，定义终结符与非终结符。
关键代码：构建环境类，包含解释器之外的一些全局信息，一般是 HashMap。
应用实例：编译器、运算表达式计算。
优点：
- 可扩展性比较好，灵活。
- 增加了新的解释表达式的方式。
- 易于实现简单文法。
缺点：
- 可利用场景比较少。
- 对于复杂的文法比较难维护。
- 解释器模式会引起类膨胀。
- 解释器模式采用递归调用方法。
使用场景：
- 可以将一个需要解释执行的语言中的句子表示为一个抽象语法树。
- 一些重复出现的问题可以用一种简单的语言来进行表达。
- 一个简单语法需要解释的场景。
注意事项：可利用场景比较少，JAVA 中如果碰到可以用 expression4J 代替。
模板模式
模板方法模式，可以从模板的角度考虑，就是一个对模板的应用，就好比老师出试卷，每个人的试卷都是一样的，即都是从老师的原版试卷复印来的，这个原版试卷就是一个模板，可每个人写在试卷上的答案都是不一样的，这就是模板方法模式，是不是很好理解。它的主要用途在于将不变的行为从子类搬到超类，去除了子类中的重复代码。
所谓模板方法模式就是在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤。
模板方法模式就是基于继承的代码复用技术的。在模板方法模式中，我们可以将相同部分的代码放在父类中，而将不同的代码放入不同的子类中。也就是说我们需要声明一个抽象的父类，将部分逻辑以具体方法以及具体构造函数的形式实现，然后声明一些抽象方法让子类来实现剩余的逻辑，不同的子类可以以不同的方式来实现这些逻辑。所以模板方法的模板其实就是一个普通的方法，只不过这个方法是将算法实现的步骤封装起来的。
模式结构
模板方法模式包含如下角色：
- AbstractClass: 抽象类
- ConcreteClass: 具体子类
/**
* 抽象模板类
*/
public abstract class AbstractClass {
public abstract void PrimitiveOperation1();
public abstract void PrimitiveOperation2();
public void TemplateMethod() {
PrimitiveOperation1();
PrimitiveOperation2();
}
}
/**
* 具体类A
*/
public class ConcreteClassA extends AbstractClass {
@Override
public void PrimitiveOperation1() {
System.out.println("具体方法A方法1实现");
}
@Override
public void PrimitiveOperation2() {
System.out.println("具体方法A方法2实现");
}
}
/**
* 具体类B
*/
public class ConcreteClassB extends AbstractClass {
@Override
public void PrimitiveOperation1() {
System.out.println("具体方法B方法1实现");
}
@Override
public void PrimitiveOperation2() {
System.out.println("具体方法B方法2实现");
}
}
/**
* client调用
*/
public class Client {
public static void main(String[] args) {
AbstractClass abstractClass;
abstractClass = new ConcreteClassA();
abstractClass.TemplateMethod();
abstractClass = new ConcreteClassB();
abstractClass.TemplateMethod();
}
// 运行结果：
// 具体方法A方法1实现
// 具体方法A方法2实现
// 具体方法B方法1实现
// 具体方法B方法2实现
}
总结
意图：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
主要解决：一些方法通用，却在每一个子类都重新写了这一方法。
何时使用：有一些通用的方法。
如何解决：将这些通用算法抽象出来。
关键代码：在抽象类实现，其他步骤在子类实现。
应用实例：
- 在造房子的时候，地基、走线、水管都一样，只有在建筑的后期才有加壁橱加栅栏等差异。
- 西游记里面菩萨定好的 81 难，这就是一个顶层的逻辑骨架。
- spring 中对 Hibernate 的支持，将一些已经定好的方法封装起来，比如开启事务、获取 Session、关闭 Session 等，程序员不重复写那些已经规范好的代码，直接丢一个实体就可以保存。
优点：
- 封装不变部分，扩展可变部分。
- 提取公共代码，便于维护。
- 行为由父类控制，子类实现。
缺点：
- 每一个不同的实现都需要一个子类来实现，导致类的个数增加，使得系统更加庞大。
使用场景：
- 有多个子类共有的方法，且逻辑相同。
- 重要的、复杂的方法，可以考虑作为模板方法。
注意事项：为防止恶意操作，一般模板方法都加上 final 关键词。
责任链模式
职责链模式描述的请求如何沿着对象所组成的链来传递的。它将对象组成一条链，发送者将请求发给链的第一个接收者，并且沿着这条链传递，直到有一个对象来处理它或者直到最后也没有对象处理而留在链末尾端。
避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止，这就是职责链模式。在职责链模式中，使得每一个对象都有可能来处理请求，从而实现了请求的发送者和接收者之间的解耦。同时职责链模式简化了对象的结构，它使得每个对象都只需要引用它的后继者即可，而不必了解整条链，这样既提高了系统的灵活性也使得增加新的请求处理类也比较方便。但是在职责链中我们不能保证所有的请求都能够被处理，而且不利于观察运行时特征。
模式结构
职责链模式包含如下角色：
- Handler: 抽象处理者
- ConcreteHandler: 具体处理者
- Client: 客户类
/**
* 抽象的记录器
*/
public abstract class AbstractLogger {
public static int INFO = 1;
public static int DEBUG = 2;
public static int ERROR = 3;
protected int level;
//责任链中的下一个元素
protected AbstractLogger nextLogger;
public void setNextLogger(AbstractLogger nextLogger){
this.nextLogger = nextLogger;
}
public void logMessage(int level, String message){
if(this.level <= level){
write(message);
}
if(nextLogger !=null){
nextLogger.logMessage(level, message);
}
}
abstract protected void write(String message);
}
/**
* 扩展了记录器类的实体类：Console
*/
public class ConsoleLogger extends AbstractLogger {
public ConsoleLogger(int level){
this.level = level;
}
@Override
protected void write(String message) {
System.out.println("Standard Console::Logger: " + message);
}
}
/**
* 扩展了记录器类的实体类：Error
*/
public class ErrorLogger extends AbstractLogger {
public ErrorLogger(int level){
this.level = level;
}
@Override
protected void write(String message) {
System.out.println("Error Console::Logger: " + message);
}
}
/**
* 扩展了记录器类的实体类：File
*/
public class FileLogger extends AbstractLogger {
public FileLogger(int level){
this.level = level;
}
@Override
protected void write(String message) {
System.out.println("File::Logger: " + message);
}
}
public class ChainPatternDemo {
/**
* 创建不同类型的记录器。
* 赋予它们不同的错误级别，并在每个记录器中设置下一个记录器。
* 每个记录器中的下一个记录器代表的是链的一部分。
*/
private static AbstractLogger getChainOfLoggers(){
AbstractLogger errorLogger = new ErrorLogger(AbstractLogger.ERROR);
AbstractLogger fileLogger = new FileLogger(AbstractLogger.DEBUG);
AbstractLogger consoleLogger = new ConsoleLogger(AbstractLogger.INFO);
errorLogger.setNextLogger(fileLogger);
fileLogger.setNextLogger(consoleLogger);
return errorLogger;
}
/**
* 调用者
*/
public static void main(String[] args) {
AbstractLogger loggerChain = getChainOfLoggers();
loggerChain.logMessage(AbstractLogger.INFO, "This is an information.");
loggerChain.logMessage(AbstractLogger.DEBUG,
"This is a debug level information.");
loggerChain.logMessage(AbstractLogger.ERROR,
"This is an error information.");
}
}
最后也可以在实体类中构造的时候初始化下一个nextLogger，这样可以只需创建最前面的对象，暴露最小级别的等级就可以了
总结
意图：避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。
主要解决：职责链上的处理者负责处理请求，客户只需要将请求发送到职责链上即可，无须关心请求的处理细节和请求的传递，所以职责链将请求的发送者和请求的处理者解耦了。
何时使用：在处理消息的时候以过滤很多道。
如何解决：拦截的类都实现统一接口。
关键代码：Handler 里面聚合它自己，在 HandlerRequest 里判断是否合适，如果没达到条件则向下传递，向谁传递之前 set 进去。
应用实例：
- 红楼梦中的"击鼓传花"。
- JS 中的事件冒泡。
- JAVA WEB 中 Apache Tomcat 对 Encoding 的处理，Struts2的拦截器，jsp servlet 的 Filter。
优点：
- 降低耦合度。它将请求的发送者和接收者解耦。
- 简化了对象。使得对象不需要知道链的结构。
- 增强给对象指派职责的灵活性。通过改变链内的成员或者调动它们的次序，允许动态地新增或者删除责任。
- 增加新的请求处理类很方便。
缺点：
- 不能保证请求一定被接收。
- 系统性能将受到一定影响，而且在进行代码调试时不太方便，可能会造成循环调用。
- 可能不容易观察运行时的特征，有碍于除错。
使用场景：
- 有多个对象可以处理同一个请求，具体哪个对象处理该请求由运行时刻自动确定。
- 在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。
- 可动态指定一组对象处理请求。
注意事项：在 JAVA WEB 中遇到很多应用。
命令模式
有些时候我们想某个对象发送一个请求，但是我们并不知道该请求的具体接收者是谁，具体的处理过程是如何的，们只知道在程序运行中指定具体的请求接收者即可，对于这样将请求封装成对象的我们称之为命令模式。所以命令模式将请求封装成对象，以便使用不同的请求、队列或者日志来参数化其他对象。同时命令模式支持可撤销的操作。
命令模式可以将请求的发送者和接收者之间实现完全的解耦，发送者和接收者之间没有直接的联系，发送者只需要知道如何发送请求命令即可，其余的可以一概不管，甚至命令是否成功都无需关心。同时我们可以非常方便的增加新的命令，但是可能就是因为方便和对请求的封装就会导致系统中会存在过多的具体命令类。
模式结构
命令模式包含如下角色：
- Command: 抽象命令类
- ConcreteCommand: 具体命令类
- Invoker: 调用者
- Receiver: 接收者
- Client:客户类
/**
* 命令接口
*/
public interface Order {
void execute();
}
/**
* 请求类
*/
public class Stock {
private String name = "ABC";
private int quantity = 10;
public void buy(){
System.out.println("Stock [ Name: "+name+",
Quantity: " + quantity +" ] bought");
}
public void sell(){
System.out.println("Stock [ Name: "+name+",
Quantity: " + quantity +" ] sold");
}
}
/**
* Order 接口的购买实体类
*/
public class BuyStock implements Order {
private Stock abcStock;
public BuyStock(Stock abcStock){
this.abcStock = abcStock;
}
public void execute() {
abcStock.buy();
}
}
/**
* Order 接口的销售实体类
*/
public class SellStock implements Order {
private Stock abcStock;
public SellStock(Stock abcStock){
this.abcStock = abcStock;
}
public void execute() {
abcStock.sell();
}
}
/**
* 命令调用类
*/
public class Broker {
private List<Order> orderList = new ArrayList<Order>();
public void takeOrder(Order order){
orderList.add(order);
}
public void placeOrders(){
for (Order order : orderList) {
order.execute();
}
orderList.clear();
}
}
/**
* 使用 Broker 类来接受并执行命令。
*/
public class CommandPatternDemo {
public static void main(String[] args) {
Stock abcStock = new Stock();
BuyStock buyStockOrder = new BuyStock(abcStock);
SellStock sellStockOrder = new SellStock(abcStock);
Broker broker = new Broker();
broker.takeOrder(buyStockOrder);
broker.takeOrder(sellStockOrder);
broker.placeOrders();
}
// 执行结果
// Stock [ Name: ABC, Quantity: 10 ] bought
// Stock [ Name: ABC, Quantity: 10 ] sold
}
总结
意图：将一个请求封装成一个对象，从而使您可以用不同的请求对客户进行参数化。
主要解决：在软件系统中，行为请求者与行为实现者通常是一种紧耦合的关系，但某些场合，比如需要对行为进行记录、撤销或重做、事务等处理时，这种无法抵御变化的紧耦合的设计就不太合适。
何时使用：在某些场合，比如要对行为进行"记录、撤销/重做、事务"等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将"行为请求者"与"行为实现者"解耦？将一组行为抽象为对象，可以实现二者之间的松耦合。
如何解决：通过调用者调用接受者执行命令，顺序：调用者→命令→接受者。
关键代码：定义三个角色：1、received 真正的命令执行对象 2、Command 3、invoker 使用命令对象的入口
应用实例：struts 1 中的 action 核心控制器 ActionServlet 只有一个，相当于 Invoker，而模型层的类会随着不同的应用有不同的模型类，相当于具体的 Command。
优点：
- 降低了系统耦合度。
- 新的命令可以很容易添加到系统中去。
缺点：使用命令模式可能会导致某些系统有过多的具体命令类。
使用场景：认为是命令的地方都可以使用命令模式，比如： 1、GUI 中每一个按钮都是一条命令。 2、模拟 CMD。
注意事项：系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作，也可以考虑使用命令模式，见命令模式的扩展。
迭代器模式
对于迭代在编程过程中我们经常用到，能够游走于聚合内的每一个元素，同时还可以提供多种不同的遍历方式，这就是迭代器模式的设计动机。在我们实际的开发过程中，我们可能会需要根据不同的需求以不同的方式来遍历整个对象，但是我们又不希望在聚合对象的抽象接口中充斥着各种不同的遍历操作，于是我们就希望有某个东西能够以多种不同的方式来遍历一个聚合对象，这时迭代器模式出现了。
何为迭代器模式？所谓迭代器模式就是提供一种方法顺序访问一个聚合对象中的各个元素，而不是暴露其内部的表示。迭代器模式是将迭代元素的责任交给迭代器，而不是聚合对象，我们甚至在不需要知道该聚合对象的内部结构就可以实现该聚合对象的迭代。
通过迭代器模式，使得聚合对象的结构更加简单，它不需要关注它元素的遍历，只需要专注它应该专注的事情，这样就更加符合单一职责原则了。
模式结构
迭代器模式包含如下角色：
- Iterator: 抽象迭代器
- ConcreteIterator: 具体迭代器
- Aggregate: 抽象聚合类
- ConcreteAggregate: 具体聚合类
接口
public interface Iterator {
public boolean hasNext();
public Object next();
}
public interface Container {
public Iterator getIterator();
}
/**
* 实现了 Container 接口的实体类。
* 该类有实现了 Iterator 接口的内部类 NameIterator。
*/
public class NameRepository implements Container {
public String names[] = {"Robert" , "John" ,"Julie" , "Lora"};
@Override
public Iterator getIterator() {
return new NameIterator();
}
private class NameIterator implements Iterator {
int index;
@Override
public boolean hasNext() {
if(index < names.length){
return true;
}
return false;
}
@Override
public Object next() {
if(this.hasNext()){
return names[index++];
}
return null;
}
}
}
/**
* 使用 NameRepository 来获取迭代器，并打印名字。
*/
public class IteratorPatternDemo {
public static void main(String[] args) {
NameRepository namesRepository = new NameRepository();
for(Iterator iter = namesRepository.getIterator(); iter.hasNext();){
String name = (String)iter.next();
System.out.println("Name : " + name);
}
}
// Name : Robert
// Name : John
// Name : Julie
// Name : Lora
}
这个只是个简单举例，实际上可以优化成公有迭代类，用数组传参进去。
不过这个模式Java中已经实现，我们很少自己单独实现。
总结
意图：提供一种方法顺序访问一个聚合对象中各个元素, 而又无须暴露该对象的内部表示。
主要解决：不同的方式来遍历整个整合对象。
何时使用：遍历一个聚合对象。
如何解决：把在元素之间游走的责任交给迭代器，而不是聚合对象。
关键代码：定义接口：hasNext, next。
应用实例：JAVA 中的 iterator。
优点：
- 它支持以不同的方式遍历一个聚合对象。
- 迭代器简化了聚合类。
- 在同一个聚合上可以有多个遍历。
- 在迭代器模式中，增加新的聚合类和迭代器类都很方便，无须修改原有代码。
缺点：由于迭代器模式将存储数据和遍历数据的职责分离，增加新的聚合类需要对应增加新的迭代器类，类的个数成对增加，这在一定程度上增加了系统的复杂性。
使用场景：
- 访问一个聚合对象的内容而无须暴露它的内部表示。
- 需要为聚合对象提供多种遍历方式。
- 为遍历不同的聚合结构提供一个统一的接口。
注意事项：迭代器模式就是分离了集合对象的遍历行为，抽象出一个迭代器类来负责，这样既可以做到不暴露集合的内部结构，又可让外部代码透明地访问集合内部的数据。
中介者模式
所谓中介者模式就是用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。在中介者模式中，中介对象用来封装对象之间的关系，各个对象可以不需要知道具体的信息通过中介者对象就可以实现相互通信。它减少了对象之间的互相关系，提供了系统可复用性，简化了系统的结构。
在中介者模式中，各个对象不需要互相知道了解，他们只需要知道中介者对象即可，但是中介者对象就必须要知道所有的对象和他们之间的关联关系，正是因为这样就导致了中介者对象的结构过于复杂，承担了过多的职责，同时它也是整个系统的核心所在，它有问题将会导致整个系统的问题。所以如果在系统的设计过程中如果出现“多对多”的复杂关系群时，千万别急着使用中介者模式，而是要仔细思考是不是您设计的系统存在问题。
模式结构
中介者模式包含如下角色：
- Mediator: 抽象中介者
- ConcreteMediator: 具体中介者
- Colleague: 抽象同事类
- ConcreteColleague: 具体同事类
/**
* 中介类
*/
public class ChatRoom {
public static void showMessage(User user, String message){
System.out.println(new Date().toString()
+ " [" + user.getName() +"] : " + message);
}
}
/**
* 具体用户类
*/
public class User {
private String name;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public User(String name){
this.name = name;
}
public void sendMessage(String message){
ChatRoom.showMessage(this,message);
}
}
/**
* 使用 User 对象来显示他们之间的通信。
*/
public class MediatorPatternDemo {
public static void main(String[] args) {
User robert = new User("Robert");
User john = new User("John");
robert.sendMessage("Hi! John!");
john.sendMessage("Hello! Robert!");
}
// 执行结果：
// Thu Jan 31 16:05:46 IST 2013 [Robert] : Hi! John!
// Thu Jan 31 16:05:46 IST 2013 [John] : Hello! Robert!
}
总结
意图：用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
主要解决：对象与对象之间存在大量的关联关系，这样势必会导致系统的结构变得很复杂，同时若一个对象发生改变，我们也需要跟踪与之相关联的对象，同时做出相应的处理。
何时使用：多个类相互耦合，形成了网状结构。
如何解决：将网状结构分离为星型结构，中间为中介者。
关键代码：对象 Colleague 之间的通信封装到一个类中单独处理。
应用实例：
- 中国加入 WTO 之前是各个国家相互贸易，结构复杂，现在是各个国家通过 WTO 来互相贸易。
- 机场调度系统。
- MVC 框架，其中C（控制器）就是 M（模型）和 V（视图）的中介者。
优点：
- 降低了类的复杂度，将一对多转化成了一对一。
- 各个类之间的解耦。
- 符合迪米特原则。
缺点：
- 中介者会庞大，变得复杂难以维护。
使用场景：
- 系统中对象之间存在比较复杂的引用关系，导致它们之间的依赖关系结构混乱而且难以复用该对象。
- 想通过一个中间类来封装多个类中的行为，而又不想生成太多的子类。
注意事项：不应当在职责混乱的时候使用。
备忘录模式
备忘录模式就是在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样可以在以后将对象恢复到原先保存的状态。
与之相关的最常见的应用有许多，比如游戏存档，我们玩游戏的时候肯定有存档功能，旨在下一次登录游戏时可以从上次退出的地方继续游戏，或者对复活点进行存档，如果挂掉了则可以读取复活点的存档信息重新开始。与之相类似的就是数据库的事务回滚，或者重做日志redo log等。
备忘录模式实现了对信息的封装，使得客户不需要关心状态保存的细节。保存就要消耗资源，所以备忘录模式的缺点就在于消耗资源。如果类的成员变量过多，势必会占用比较大的资源，而且每一次保存都会消耗一定的内存。
模式结构
备忘录模式包含如下角色：
- Originator: 原发器
- Memento: 备忘录
- Caretaker: 负责人
/**
* 备忘录角色
*/
public class Memento {
private String state;
public Memento(String state) {
this.state = state;
}
public String getState() {
return state;
}
}
/**
* 备忘录管理员角色
*/
public class Caretaker {
private Memento memento;
public Memento getMemento() {
return memento;
}
public void setMemento(Memento memento) {
this.memento = memento;
}
}
/**
* 发起人角色
*/
public class Originator {
private String state;
public String getState() {
return state;
}
public void setState(String state) {
this.state = state;
}
public Memento createMento() {
return (new Memento(state));
}
public void setMemento(Memento memento) {
state = memento.getState();
}
public void show() {
System.out.println("state = " + state);
}
}
/**
* Client客户端
*/
public class Client {
public static void main(String[] args) {
Originator originator = new Originator();
originator.setState("On"); //Originator初始状态
originator.show();
Caretaker caretaker = new Caretaker();
caretaker.setMemento(originator.createMento());
originator.setState("Off"); //Originator状态变为Off
originator.show();
originator.setMemento(caretaker.getMemento()); //回复初始状态
originator.show();
}
// state = On
// state = Off
// state = On
}
总结
意图：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。
主要解决：所谓备忘录模式就是在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样可以在以后将对象恢复到原先保存的状态。
何时使用：很多时候我们总是需要记录一个对象的内部状态，这样做的目的就是为了允许用户取消不确定或者错误的操作，能够恢复到他原先的状态，使得他有"后悔药"可吃。
如何解决：通过一个备忘录类专门存储对象状态。
关键代码：客户不与备忘录类耦合，与备忘录管理类耦合。
应用实例：
- 后悔药。
- 打游戏时的存档。
- Windows 里的 ctri + z。
- IE 中的后退。
- 数据库的事务管理。
优点：
- 给用户提供了一种可以恢复状态的机制，可以使用户能够比较方便地回到某个历史的状态。
- 实现了信息的封装，使得用户不需要关心状态的保存细节。
缺点：消耗资源。如果类的成员变量过多，势必会占用比较大的资源，而且每一次保存都会消耗一定的内存。
使用场景：
- 需要保存/恢复数据的相关状态场景。
- 提供一个可回滚的操作。
注意事项：
- 为了符合迪米特原则，还要增加一个管理备忘录的类。
- 为了节约内存，可使用原型模式+备忘录模式。
观察者模式
观察者模式，又叫发布-订阅模式，本质上是一样的，发布订阅模式可能中间还有管理者进行解耦，但是实际内部用的还是观察者模式。这是定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并自动更新。
一般可以看做是第三者，比如在学校上自习的时候，大家肯定都有过交头接耳、各种玩耍的经历，这时总会有一个“放风”的小伙伴，当老师即将出现时及时“通知”大家老师来了。再比如，拍卖会的时候，大家相互叫价，拍卖师会观察最高标价，然后通知给其它竞价者竞价，这就是一个观察者模式。
观察者之间没有相互联系，所以么可以根据需要增加和删除观察者，使得系统更易于扩展。所以观察者提供了一种对象设计，让主题和观察者之间以松耦合的方式结合。
模式结构
观察者模式包含如下角色：
- Subject: 目标
- ConcreteSubject: 具体目标
- Observer: 观察者
- ConcreteObserver: 具体观察者
/**
* 主题Subject
* 它的职责很简单，就是定义谁能观察，谁不能观察
*/
public class Subject {
//观察者数组
//用Vector是线程同步的，比较安全，也可以使用ArrayList，是线程异步的，但不安全。
private Vector<Observer> oVector = new Vector<>();
//增加一个观察者
public void addObserver(Observer observer) {
this.oVector.add(observer);
}
//删除一个观察者
public void deleteObserver(Observer observer) {
this.oVector.remove(observer);
}
//通知所有观察者
public void notifyObserver() {
for(Observer observer : this.oVector) {
observer.update();
}
}
}
/**
* 继承Subject类，在这里实现具体业务，在具体项目中，该类会有很多变种。
*/
public class ConcreteSubject extends Subject {
//具体业务
public void doSomething() {
//...
super.notifyObserver();
}
}
/**
* 抽象观察者Observer
*/
public interface Observer {
//更新
public void update();
}
/**
* 具体观察者
*/
public class ConcreteObserver implements Observer {
@Override
public void update() {
System.out.println("收到消息，进行处理");
}
}
/**
* 测试客户端
*/
public class Client {
public static void main(String[] args) {
//创建一个主题
ConcreteSubject subject = new ConcreteSubject();
//定义一个观察者
Observer observer = new ConcreteObserver();
//观察
subject.addObserver(observer);
//开始活动
subject.doSomething();
}
// 运行结果：
// 收到消息，进行处理
}
总结
意图：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
主要解决：一个对象状态改变给其他对象通知的问题，而且要考虑到易用和低耦合，保证高度的协作。
何时使用：一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知，进行广播通知。
如何解决：使用面向对象技术，可以将这种依赖关系弱化。
关键代码：在抽象类里有一个 观察者数组 存放观察者们。
应用实例：
- 拍卖的时候，拍卖师观察最高标价，然后通知给其他竞价者竞价。
- 西游记里面悟空请求菩萨降服红孩儿，菩萨洒了一地水招来一个老乌龟，这个乌龟就是观察者，他观察菩萨洒水这个动作。
优点：
- 观察者和被观察者是抽象耦合的。
- 建立一套触发机制。
缺点：
- 如果一个被观察者对象有很多的直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间。
- 如果在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。
- 观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化。
使用场景：
- 一个抽象模型有两个方面，其中一个方面依赖于另一个方面。将这些方面封装在独立的对象中使它们可以各自独立地改变和复用。
- 一个对象的改变将导致其他一个或多个对象也发生改变，而不知道具体有多少对象将发生改变，可以降低对象之间的耦合度。
- 一个对象必须通知其他对象，而并不知道这些对象是谁。
- 需要在系统中创建一个触发链，A对象的行为将影响B对象，B对象的行为将影响C对象……，可以使用观察者模式创建一种链式触发机制。
注意事项：
- JAVA 中已经有了对观察者模式的支持类。
- 避免循环引用。
- 如果顺序执行，某一观察者错误会导致系统卡壳，一般采用异步方式。
状态模式
在很多情况下我们对象的行为依赖于它的一个或者多个变化的属性，这些可变的属性我们称之为状态，也就是说行为依赖状态，即当该对象因为在外部的互动而导致他的状态发生变化，从而它的行为也会做出相应的变化。对于这种情况，我们是不能用行为来控制状态的变化，而应该站在状态的角度来思考行为，即是什么状态就要做出什么样的行为。这个就是状态模式。
所以状态模式就是允许对象在内部状态发生改变时改变它的行为，对象看起来好像修改了它的类。
在状态模式中我们可以减少大块的if…else语句，它是允许态转换逻辑与状态对象合成一体，但是减少if…else语句的代价就是会换来大量的类，所以状态模式势必会增加系统中类或者对象的个数。
同时状态模式是将所有与某个状态有关的行为放到一个类中，并且可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为。但是这样就会导致系统的结构和实现都会比较复杂，如果使用不当就会导致程序的结构和代码混乱，不利于维护。
模式结构
状态模式包含如下角色：
- Context: 环境类
- State: 抽象状态类
- ConcreteState: 具体状态类
/**
* Context类为环境角色，具有两个职责：
* 1：处理本状态必须完成的任务
* 2：决定是否可以过渡到其它状态
*/
public class Context {
//定义状态
public final static State STATE1 = new ConcreteState1();
public final static State STATE2 = new ConcreteState2();
//当前状态
private State currentState;
//获得当前状态
public State getCurrentState() {
return currentState;
}
//设置当前状态
public void setCurrentState(State currentState) {
this.currentState = currentState;
// System.out.println("当前状态：" + currentState);
//切换状态
this.currentState.setContext(this);
}
public void handle1() {
this.currentState.handle1();
}
public void handle2() {
this.currentState.handle2();
}
}
对于环境角色，有几个不成文的约束：
- 把状态对象声明为静态常量，有几个状态对象就声明几个状态常量
- 环境角色具有状态抽象角色定义的所有行为，具体执行使用委托方式
/**
* 抽象状态类
* 抽象环境中声明一个环境角色，提供各个状态类自行访问,
* 并且提供所有状态的抽象行为，由各个实现类实现。
*/
public abstract class State {
protected Context context;
public void setContext(Context context) {
this.context = context;
}
//行为1
public abstract void handle1();
//行为2
public abstract void handle2();
}
/**
* 具体状态
*/
public class ConcreteState1 extends State {
@Override
public void handle1() {
//...
System.out.println("ConcreteState1 的 handle1 方法");
}
@Override
public void handle2() {
super.context.setCurrentState(Context.STATE2);
System.out.println("ConcreteState1 的 handle2 方法");
}
}
public class Client {
public static void main(String[] args) {
//定义环境角色
Context context = new Context();
//初始化状态
context.setCurrentState(new ConcreteState1());
//行为执行
context.handle1();
context.handle2();
}
// 执行结果：
// ConcreteState1 的 handle1 方法
// ConcreteState1 的 handle2 方法
}
从运行结果可见，我们已经隐藏了状态的变化过程，它的切换引起了行为的变化。对外来说，我们只看到了行为的改变，而不用知道是状态变化引起的。
总结
意图：允许对象在内部状态发生改变时改变它的行为，对象看起来好像修改了它的类。
主要解决：对象的行为依赖于它的状态（属性），并且可以根据它的状态改变而改变它的相关行为。
何时使用：代码中包含大量与对象状态有关的条件语句。
如何解决：将各种具体的状态类抽象出来。
关键代码：通常命令模式的接口中只有一个方法。而状态模式的接口中有一个或者多个方法。而且，状态模式的实现类的方法，一般返回值，或者是改变实例变量的值。也就是说，状态模式一般和对象的状态有关。实现类的方法有不同的功能，覆盖接口中的方法。状态模式和命令模式一样，也可以用于消除 if...else 等条件选择语句。
应用实例：
- 打篮球的时候运动员可以有正常状态、不正常状态和超常状态。
- 曾侯乙编钟中，'钟是抽象接口','钟A'等是具体状态，'曾侯乙编钟'是具体环境（Context）。
优点：
- 封装了转换规则。
- 枚举可能的状态，在枚举状态之前需要确定状态种类。
- 将所有与某个状态有关的行为放到一个类中，并且可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为。
- 允许状态转换逻辑与状态对象合成一体，而不是某一个巨大的条件语句块。
- 可以让多个环境对象共享一个状态对象，从而减少系统中对象的个数。
缺点：
- 状态模式的使用必然会增加系统类和对象的个数。
- 状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱。
- 状态模式对"开闭原则"的支持并不太好，对于可以切换状态的状态模式，增加新的状态类需要修改那些负责状态转换的源代码，否则无法切换到新增状态，而且修改某个状态类的行为也需修改对应类的源代码。
使用场景：
- 行为随状态改变而改变的场景。
- 条件、分支语句的代替者。
注意事项：在行为受状态约束的时候使用状态模式，而且状态不超过 5 个。
策略模式
我们有很多种方法来实现一个功能，但是我们需要一种简单、高效的方式来实现它，使得系统能够非常灵活，这就是策略模式。
所以策略模式就是定义了算法族，分别封装起来，让他们之前可以互相转换，此模式然该算法的变化独立于使用算法的客户。
比如我们去逛商场，商场现在正在搞活动，有打折的、有满减的、有返利的等等，其实不管商场如何进行促销，说到底都是一些算法，这些算法本身只是一种策略，并且这些算法是随时都可能互相替换的。
在策略模式中它将这些解决问题的方法定义成一个算法群，每一个方法都对应着一个具体的算法，这里的一个算法我就称之为一个策略。虽然策略模式定义了算法，但是它并不提供算法的选择，即什么算法对于什么问题最合适这是策略模式所不关心的，所以对于策略的选择还是要客户端来做。客户必须要清楚的知道每个算法之间的区别和在什么时候什么地方使用什么策略是最合适的，这样就增加客户端的负担。
同时策略模式也非常完美的符合了“开闭原则”，用户可以在不修改原有系统的基础上选择算法或行为，也可以灵活地增加新的算法或行为。但是一个策略对应一个类将会是系统产生很多的策略类。
模式结构
策略模式包含如下角色：
- Context: 环境类
- Strategy: 抽象策略类
- ConcreteStrategy: 具体策略类
策略模式的类图呵状态模式的类似，并且都是能够动态改变对象的行为。但是状态模式是通过状态转移来改变 Context 所组合的 State 对象，而策略模式是通过 Context 本身的决策来改变组合的 Strategy 对象。所谓的状态转移，是指 Context 在运行过程中由于一些条件发生改变而使得 State 对象发生改变，注意必须要是在运行过程中。
状态模式主要是用来解决状态转移的问题，当状态发生转移了，那么 Context 对象就会改变它的行为；而策略模式主要是用来封装一组可以互相替代的算法族，并且可以根据需要动态地去替换 Context 使用的算法。
/**
* 策略接口
*/
public interface Strategy {
public int doOperation(int num1, int num2);
}
实现接口的策略实体类们：
public class OperationAdd implements Strategy{
@Override
public int doOperation(int num1, int num2) {
return num1 + num2;
}
}
public class OperationSubtract implements Strategy{
@Override
public int doOperation(int num1, int num2) {
return num1 - num2;
}
}
public class OperationMultiply implements Strategy{
@Override
public int doOperation(int num1, int num2) {
return num1 * num2;
}
}
/**
* 上下文环境类，维护一个对Strategy对象的引用
*/
public class Context {
private Strategy strategy;
public Context(){
}
public SetStrategy(Strategy strategy){
this.strategy = strategy;
}
public int executeStrategy(int num1, int num2){
return strategy.doOperation(num1, num2);
}
}
public static void main(String[] args) {
Context context = new Context();
context.SetStrategy(new OperationAdd());
System.out.println("10 + 5 = " + context.executeStrategy(10, 5));
context.SetStrategy(new OperationSubtract());
System.out.println("10 - 5 = " + context.executeStrategy(10, 5));
context.SetStrategy(new OperationMultiply()); System.out.println("10 * 5 = " + context.executeStrategy(10, 5));
}
// 运行结果：
// 10 + 5 = 15
// 10 - 5 = 5
// 10 * 5 = 50
总结
意图：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。
主要解决：在有多种算法相似的情况下，使用 if...else 所带来的复杂和难以维护。
何时使用：一个系统有许多许多类，而区分它们的只是他们直接的行为。
如何解决：将这些算法封装成一个一个的类，任意地替换。
关键代码：实现同一个接口。
应用实例：
- 诸葛亮的锦囊妙计，每一个锦囊就是一个策略。
- 旅行的出游方式，选择骑自行车、坐汽车，每一种旅行方式都是一个策略。
- JAVA AWT 中的 LayoutManager。
优点：
- 算法可以自由切换。
- 避免使用多重条件判断。
- 扩展性良好。
缺点：
- 策略类会增多。
- 所有策略类都需要对外暴露。
使用场景：
- 如果在一个系统里面有许多类，它们之间的区别仅在于它们的行为，那么使用策略模式可以动态地让一个对象在许多行为中选择一种行为。
- 一个系统需要动态地在几种算法中选择一种。
- 如果一个对象有很多的行为，如果不用恰当的模式，这些行为就只好使用多重的条件选择语句来实现。
注意事项：如果一个系统的策略多于四个，就需要考虑使用混合模式，解决策略类膨胀的问题。
访问者模式
访问者模式俗称23大设计模式中最难的一个。除了结构复杂外，理解也比较难。在我们软件开发中我们可能会对同一个对象有不同的处理，如果我们都做分别的处理，将会产生灾难性的错误。对于这种问题，访问者模式提供了比较好的解决方案。
访问者模式即表示一个作用于某对象结构中的各元素的操作，它使我们可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
例如，你在朋友家做客，你是访问者，朋友接收你的访问，你通过朋友的描述，然后对朋友的描述做出一个判断，这就是访问者模式。
访问者模式的目的是封装一些施加于某种数据结构元素之上的操作，一旦这些操作需要修改的话，接受这个操作的数据结构可以保持不变。为不同类型的元素提供多种访问操作方式，且可以在不修改原有系统的情况下增加新的操作方式。同时我们还需要明确一点那就是访问者模式是适用于那些数据结构比较稳定的，因为他是将数据的操作与数据结构进行分离了，如果某个系统的数据结构相对稳定，但是操作算法易于变化的话，就比较适用适用访问者模式，因为访问者模式使得算法操作的增加变得比较简单了。
模式结构
访问者模式包含如下角色：
- Vistor: 抽象访问者
- ConcreteVisitor: 具体访问者
- Element: 抽象元素
- ConcreteElement: 具体元素
- ObjectStructure: 对象结构
/**
* 抽象访问者
*/
public abstract class Visitor {
public abstract void visitConcreteElementA(ConcreteElementA concreteElementA);
public abstract void visitConcreteElementB(ConcreteElementB concreteElementB);
}
/**
* 具体访问者
*/
public class ConcreteVisitor1 extends Visitor {
@Override
public void visitConcreteElementA(ConcreteElementA concreteElementA) {
System.out.println(concreteElementA.getClass().getName() + " 被 " + this.getClass().getName() + " 访问");
}
@Override
public void visitConcreteElementB(ConcreteElementB concreteElementB) {
System.out.println(concreteElementB.getClass().getName() + " 被 " + this.getClass().getName() + " 访问");
}
}
/**
* 抽象元素
* 用于声明接受哪一类访问者访问，程序上是通过accpet方法中的参数来定义的。
*/
public abstract class Element {
//抽象元素有两类方法，一是本身的业务逻辑，也就是元素作为一个业务处理单元必须完成的职责；
//另外一个是允许哪一个访问者来访问。这里只声明的第二类即accept方法。
public abstract void accept(Visitor visitor);
}
/**
* 具体元素
*/
public class ConcreteElementA extends Element {
@Override
public void accept(Visitor visitor) {
visitor.visitConcreteElementA(this);
}
//其它方法
public void operationA() {
}
}
/**
* 结构对象
* 元素生产者，一般容纳在多个不同类、不同接口的容器，
* 如List、Set、Map等，在项目中，一般很少抽象出这个角色。
*/
public class ObjectStructure {
private List<Element> elements = new LinkedList<>();
public void attach(Element element) {
elements.add(element);
}
public void detach(Element element) {
elements.remove(element);
}
public void accept(Visitor visitor) {
for (Element element : elements) {
element.accept(visitor);
}
}
}
/**
* Client客户端
*/
public class Client {
public static void main(String[] args) {
ObjectStructure objectStructure = new ObjectStructure();
objectStructure.attach(new ConcreteElementA());
objectStructure.attach(new ConcreteElementB());
ConcreteVisitor1 visitor1 = new ConcreteVisitor1();
ConcreteVisitor2 visitor2 = new ConcreteVisitor2();
objectStructure.accept(visitor1);
objectStructure.accept(visitor2);
}
// 执行结果：
// com.adamjwh.gof.visitor.ConcreteElementA 被 com.adamjwh.gof.visitor.Concretevisitor1 访问
// com.adamjwh.gof.visitor.ConcreteElementB 被 com.adamjwh.gof.visitor.Concretevisitor1 访问
// com.adamjwh.gof.visitor.ConcreteElementA 被 com.adamjwh.gof.visitor.Concretevisitor2 访问
// com.adamjwh.gof.visitor.ConcreteElementB 被 com.adamjwh.gof.visitor.ConcreteVisitor2 访问
}
总结
意图：主要将数据结构与数据操作分离。
主要解决：稳定的数据结构和易变的操作耦合问题。
何时使用：需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而需要避免让这些操作"污染"这些对象的类，使用访问者模式将这些封装到类中。
如何解决：在被访问的类里面加一个对外提供接待访问者的接口。
关键代码：在数据基础类里面有一个方法接受访问者，将自身引用传入访问者。
应用实例：您在朋友家做客，您是访问者，朋友接受您的访问，您通过朋友的描述，然后对朋友的描述做出一个判断，这就是访问者模式。
优点：
- 符合单一职责原则。
- 优秀的扩展性。
- 灵活性。
缺点：
- 具体元素对访问者公布细节，违反了迪米特原则。
- 具体元素变更比较困难。
- 违反了依赖倒置原则，依赖了具体类，没有依赖抽象。
使用场景：
- 对象结构中对象对应的类很少改变，但经常需要在此对象结构上定义新的操作。
- 需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而需要避免让这些操作"污染"这些对象的类，也不希望在增加新操作时修改这些类。
注意事项：访问者可以对功能进行统一，可以做报表、UI、拦截器与过滤器。
