当前位置：首页 > news >正文

设计模式——行为型模式

news 来源：原创 2024/5/20 15:46:51

模板方法模式

行为型模式用于描述程序在运行时复杂的流程控制，即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，它涉及算法与对象间职责的分配。

行为型模式分为类行为模式和对象行为模式，前者采用继承机制来在类间分派行为，后者采用组合或聚合在对象间分配行为。由于组合关系或聚合关系比继承关系耦合度低，满足“合成复用原则”，所以对象行为模式比类行为模式具有更大的灵活性。

模板方法模式
- 1. 概述
- 2. 结构
- 3. 案例实现
- 4. 优缺点
- 5. 适用场景
- 6. JDK源码解析
策略模式
- 1. 结构
- 2. 案例实现
- 3. 优缺点
- 4. 使用场景
- 5. JDK源码解析
命令模式
- 1. 结构
- 2. 案例实现
- 3. 优缺点
- 4. 使用场景
- 5. JDK源码解析
责任链模式
- 1. 结构
- 2. 案例实现
- 3. 优缺点
- 4. 使用场景
- 5. 源码解析
状态模式
- 1. 结构
- 2. 案例实现
- - 不适用状态模式
  - 使用状态模式
- 3. 优缺点
- 4. 一些常见使用场景
观察者模式
- 1. 定义
- 2. 结构
- 3. 案例实现
- 4. 优缺点
- 5. 使用场景
- 6. JDK中提供的实现
中介者模式
- 1. 概述
- 2. 结构
- 3. 案例实现
- 4. 优缺点
- 5. 一些常见的中介者模式应用场
迭代器模式
- - 6.8.1 定义
  - 6.8.2 结构
  - 6.8.3 案例实现
  - 6.8.4 优缺点
  - 6.8.5 使用场景
  - 6.8.6 JDK源码解析
访问者模式
- 1. 定义
- 2. 结构
- 3. 案例实现
- 4. 优缺点
- 5. 使用场景
- 6. 扩展——双分派
备忘录模式
- 1. 定义
- 2. 结构
- 3. 案例实现
- - 3.1.“白箱”备忘录模式——破坏封装性
  - 3.2.“黑箱”备忘录模式——推荐
- 4. 优缺点
- 5. 使用场景
解释器模式
- 1. 定义
- 2. 结构
- 3. 案例实现
- 4. 优缺点
- 5. 使用场景

1. 概述

在面向对象程序设计过程中，程序员常常会遇到这种情况：设计一个系统时知道了算法所需的关键步骤，而且确定了这些步骤的执行顺序，但某些步骤的具体实现还未知，或者说某些步骤的实现与具体的环境相关。

例如，去银行办理业务一般要经过以下4个流程：取号、排队、办理具体业务、对银行工作人员进行评分等，其中取号、排队和对银行工作人员进行评分的业务对每个客户是一样的，可以在父类中实现，但是办理具体业务却因人而异，它可能是存款、取款或者转账等，可以延迟到子类中实现。

定义：

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

2. 结构

模板方法（Template Method）模式包含以下主要角色：

抽象类（Abstract Class）： 负责给出一个算法的轮廓和骨架。它由一个模板方法和若干个基本方法构成。
- 模板方法： 定义了算法的骨架，按某种顺序调用其包含的基本方法。
- 基本方法： 是实现算法各个步骤的方法，是模板方法的组成部分。基本方法又可以分为三种：
  - 抽象方法(Abstract Method) ： 一个抽象方法由抽象类声明、由其具体子类实现。
  - 具体方法(Concrete Method) ： 一个具体方法由一个抽象类或具体类声明并实现，其子类可以进行覆盖也可以直接继承。
  - 钩子方法(Hook Method) ： 在抽象类中已经实现，包括用于判断的逻辑方法和需要子类重写的空方法两种。
    一般钩子方法是用于判断的逻辑方法，这类方法名一般为isXxx，返回值类型为boolean类型。
具体子类（Concrete Class）： 实现抽象类中所定义的抽象方法和钩子方法，它们是一个顶级逻辑的组成步骤。

3. 案例实现

【例】炒菜

炒菜的步骤是固定的，分为倒油、热油、倒蔬菜、倒调料品、翻炒等步骤。现通过模板方法模式来用代码模拟。类图如下：

在这里插入图片描述

代码如下：

public abstract class AbstractClass {public final void cookProcess() {//第一步：倒油this.pourOil();//第二步：热油this.heatOil();//第三步：倒蔬菜this.pourVegetable();//第四步：倒调味料this.pourSauce();//第五步：翻炒this.fry();}public void pourOil() {System.out.println("倒油");}//第二步：热油是一样的，所以直接实现public void heatOil() {System.out.println("热油");}//第三步：倒蔬菜是不一样的（一个下包菜，一个是下菜心）public abstract void pourVegetable();//第四步：倒调味料是不一样public abstract void pourSauce();//第五步：翻炒是一样的，所以直接实现public void fry(){System.out.println("炒啊炒啊炒到熟啊");}
}public class ConcreteClass_BaoCai extends AbstractClass {@Overridepublic void pourVegetable() {System.out.println("下锅的蔬菜是包菜");}@Overridepublic void pourSauce() {System.out.println("下锅的酱料是辣椒");}
}public class ConcreteClass_CaiXin extends AbstractClass {@Overridepublic void pourVegetable() {System.out.println("下锅的蔬菜是菜心");}@Overridepublic void pourSauce() {System.out.println("下锅的酱料是蒜蓉");}
}public class Client {public static void main(String[] args) {//炒手撕包菜ConcreteClass_BaoCai baoCai = new ConcreteClass_BaoCai();baoCai.cookProcess();//炒蒜蓉菜心ConcreteClass_CaiXin caiXin = new ConcreteClass_CaiXin();caiXin.cookProcess();}
}

注意：为防止恶意操作，一般模板方法都加上 final 关键词。

4. 优缺点

优点：

提高代码复用性
将相同部分的代码放在抽象的父类中，而将不同的代码放入不同的子类中。
实现了反向控制
通过一个父类调用其子类的操作，通过对子类的具体实现扩展不同的行为，实现了反向控制，并符合“开闭原则”。

缺点：

对每个不同的实现都需要定义一个子类，这会导致类的个数增加，系统更加庞大，设计也更加抽象。
父类中的抽象方法由子类实现，子类执行的结果会影响父类的结果，这导致一种反向的控制结构，它提高了代码阅读的难度。

5. 适用场景

算法的整体步骤很固定，但其中个别部分易变时，这时候可以使用模板方法模式，将容易变的部分抽象出来，供子类实现。
需要通过子类来决定父类算法中某个步骤是否执行，实现子类对父类的反向控制。

6. JDK源码解析

InputStream类就使用了模板方法模式。在InputStream类中定义了多个 read() 方法，如下：

public abstract class InputStream implements Closeable {//抽象方法，要求子类必须重写public abstract int read() throws IOException;public int read(byte b[]) throws IOException {return read(b, 0, b.length);}public int read(byte b[], int off, int len) throws IOException {if (b == null) {throw new NullPointerException();} else if (off < 0 || len < 0 || len > b.length - off) {throw new IndexOutOfBoundsException();} else if (len == 0) {return 0;}int c = read(); //调用了无参的read方法，该方法是每次读取一个字节数据if (c == -1) {return -1;}b[off] = (byte)c;int i = 1;try {for (; i < len ; i++) {c = read();if (c == -1) {break;}b[off + i] = (byte)c;}} catch (IOException ee) {}return i;}
}

从上面代码可以看到，无参的 read() 方法是抽象方法，要求子类必须实现。而 read(byte b[]) 方法调用了 read(byte b[], int off, int len) 方法，所以在此处重点看的方法是带三个参数的方法。

在该方法中第18行、27行，可以看到调用了无参的抽象的 read() 方法。

总结如下：在InputStream父类中已经定义好了读取一个字节数组数据的方法是每次读取一个字节，并将其存储到数组的第一个索引位置，读取len个字节数据。具体如何读取一个字节数据呢？由子类实现。

策略模式

该模式定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的变化不会影响使用算法的客户。策略模式属于对象行为模式，它通过对算法进行封装，把使用算法的责任和算法的实现分割开来，并委派给不同的对象对这些算法进行管理。

1. 结构

策略模式的主要角色如下：

抽象策略（Strategy）类： 这是一个抽象角色，通常由一个接口或抽象类实现。此角色给出所有的具体策略类所需的接口。
具体策略（Concrete Strategy）类： 实现了抽象策略定义的接口，提供具体的算法实现或行为。
环境（Context）类： 持有一个策略类的引用，最终给客户端调用。

2. 案例实现

【例】促销活动

一家百货公司在定年度的促销活动。针对不同的节日（春节、中秋节、圣诞节）推出不同的促销活动，由促销员将促销活动展示给客户。类图如下：

在这里插入图片描述

代码如下：

定义百货公司所有促销活动的共同接口

public interface Strategy {void show();
}

定义具体策略角色（Concrete Strategy）：每个节日具体的促销活动

//为春节准备的促销活动A
public class StrategyA implements Strategy {public void show() {System.out.println("买一送一");}
}//为中秋准备的促销活动B
public class StrategyB implements Strategy {public void show() {System.out.println("满200元减50元");}
}//为圣诞准备的促销活动C
public class StrategyC implements Strategy {public void show() {System.out.println("满1000元加一元换购任意200元以下商品");}
}

定义环境角色（Context）：用于连接上下文，即把促销活动推销给客户，这里可以理解为销售员

public class SalesMan {                        //持有抽象策略角色的引用                              private Strategy strategy;                 public SalesMan(Strategy strategy) {       this.strategy = strategy;              }                                          //向客户展示促销活动                                public void salesManShow(){                strategy.show();                       }                                          
}

3. 优缺点

1，优点：

策略类之间可以自由切换
由于策略类都实现同一个接口，所以使它们之间可以自由切换。
易于扩展
增加一个新的策略只需要添加一个具体的策略类即可，基本不需要改变原有的代码，符合“开闭原则“
避免使用多重条件选择语句（if else），充分体现面向对象设计思想。

2，缺点：

客户端必须知道所有的策略类，并自行决定使用哪一个策略类。
策略模式将造成产生很多策略类，可以通过使用享元模式在一定程度上减少对象的数量。

4. 使用场景

一个系统需要动态地在几种算法中选择一种时，可将每个算法封装到策略类中。
一个类定义了多种行为，并且这些行为在这个类的操作中以多个条件语句的形式出现，可将每个条件分支移入它们各自的策略类中以代替这些条件语句。
系统中各算法彼此完全独立，且要求对客户隐藏具体算法的实现细节时。
系统要求使用算法的客户不应该知道其操作的数据时，可使用策略模式来隐藏与算法相关的数据结构。
多个类只区别在表现行为不同，可以使用策略模式，在运行时动态选择具体要执行的行为。

5. JDK源码解析

Comparator 中的策略模式。在Arrays类中有一个 sort() 方法，如下：

public class Arrays{public static <T> void sort(T[] a, Comparator<? super T> c) {if (c == null) {sort(a);} else {if (LegacyMergeSort.userRequested)legacyMergeSort(a, c);elseTimSort.sort(a, 0, a.length, c, null, 0, 0);}}
}

Arrays就是一个环境角色类，这个sort方法可以传一个新策略让Arrays根据这个策略来进行排序。就比如下面的测试类。

public class demo {public static void main(String[] args) {Integer[] data = {12, 2, 3, 2, 4, 5, 1};// 实现降序排序Arrays.sort(data, new Comparator<Integer>() {public int compare(Integer o1, Integer o2) {return o2 - o1;}});System.out.println(Arrays.toString(data)); //[12, 5, 4, 3, 2, 2, 1]}
}

这里我们在调用Arrays的sort方法时，第二个参数传递的是Comparator接口的子实现类对象。所以Comparator充当的是抽象策略角色，而具体的子实现类充当的是具体策略角色。环境角色类（Arrays）应该持有抽象策略的引用来调用。那么，Arrays类的sort方法到底有没有使用Comparator子实现类中的 compare() 方法吗？让我们继续查看TimSort类的 sort() 方法，代码如下：

class TimSort<T> {static <T> void sort(T[] a, int lo, int hi, Comparator<? super T> c,T[] work, int workBase, int workLen) {assert c != null && a != null && lo >= 0 && lo <= hi && hi <= a.length;int nRemaining  = hi - lo;if (nRemaining < 2)return;  // Arrays of size 0 and 1 are always sorted// If array is small, do a "mini-TimSort" with no mergesif (nRemaining < MIN_MERGE) {int initRunLen = countRunAndMakeAscending(a, lo, hi, c);binarySort(a, lo, hi, lo + initRunLen, c);return;}...}   private static <T> int countRunAndMakeAscending(T[] a, int lo, int hi,Comparator<? super T> c) {assert lo < hi;int runHi = lo + 1;if (runHi == hi)return 1;// Find end of run, and reverse range if descendingif (c.compare(a[runHi++], a[lo]) < 0) { // Descendingwhile (runHi < hi && c.compare(a[runHi], a[runHi - 1]) < 0)runHi++;reverseRange(a, lo, runHi);} else {                              // Ascendingwhile (runHi < hi && c.compare(a[runHi], a[runHi - 1]) >= 0)runHi++;}return runHi - lo;}
}

上面的代码中最终会跑到 countRunAndMakeAscending() 这个方法中。我们可以看见，只用了compare方法，所以在调用Arrays.sort方法只传具体compare重写方法的类对象就行，这也是Comparator接口中必须要子类实现的一个方法。

命令模式

一般执行命令是命令发起者直接调用命令接受者执行命令，而命令模式则是将命令封装为一个个类对象，命令发起者创建这些命令对象，然后命令对象再经过传递到达命令接受者再执行，这样两者间实现通过命令对象进行沟通，也方便将命令对象进行存储、传递、调用、增加与管理。

1. 结构

命令模式包含以下主要角色：

抽象命令类（Command）角色： 定义命令的接口，声明执行的方法。
具体命令（Concrete Command）角色： 具体的命令，实现命令接口；通常会持有接收者，并调用接收者的功能来完成命令要执行的操作。
实现者/接收者（Receiver）角色： 接收者，真正执行命令的对象。任何类都可能成为一个接收者，只要它能够实现命令要求实现的相应功能。
调用者/请求者（Invoker）角色： 要求命令对象执行请求，通常会持有命令对象，可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方，也就是说相当于使用命令对象的入口。

2. 案例实现

将上面的案例用代码实现，那我们就需要分析命令模式的角色在该案例中由谁来充当。

服务员： 就是调用者角色，由她来发起命令。

资深大厨： 就是接收者角色，真正命令执行的对象。

订单： 命令中包含订单。

类图如下：

在这里插入图片描述

代码如下：

//抽象命令类
public interface Command {void execute();//只需要定义一个统一的执行方法
}//具体命令类
public class OrderCommand implements Command {//持有接受者对象private SeniorChef receiver;private Order order;public OrderCommand(SeniorChef receiver, Order order){this.receiver = receiver;this.order = order;}public void execute()  {System.out.println(order.getDiningTable() + "桌的订单：");Set<String> keys = order.getFoodDic().keySet();for (String key : keys) {receiver.makeFood(order.getFoodDic().get(key),key);}try {Thread.sleep(100);//停顿一下 模拟做饭的过程} catch (InterruptedException e) {e.printStackTrace();}System.out.println(order.getDiningTable() + "桌的饭弄好了");}
}//普通类：订单
public class Order {// 餐桌号码private int diningTable;// 用来存储餐名并记录份数private Map<String, Integer> foodDic = new HashMap<String, Integer>();public int getDiningTable() {return diningTable;}public void setDiningTable(int diningTable) {this.diningTable = diningTable;}public Map<String, Integer> getFoodDic() {return foodDic;}public void setFoodDic(String name, int num) {foodDic.put(name,num);}
}//命令接受者
public class SeniorChef {public void makeFood(int num,String foodName) {System.out.println(num + "份" + foodName);}
}//命令发起者
public class Waitor {private ArrayList<Command> commands;//可以持有很多的命令对象public Waitor() {commands = new ArrayList();}public void setCommand(Command cmd){commands.add(cmd);}public void orderUp() {System.out.println("美女服务员：叮咚，大厨，新订单来了.......");for (int i = 0; i < commands.size(); i++) {Command cmd = commands.get(i);if (cmd != null) {cmd.execute();}}}
}public class Client {public static void main(String[] args) {//创建2个orderOrder order1 = new Order();order1.setDiningTable(1);order1.getFoodDic().put("西红柿鸡蛋面",1);order1.getFoodDic().put("小杯可乐",2);Order order2 = new Order();order2.setDiningTable(3);order2.getFoodDic().put("尖椒肉丝盖饭",1);order2.getFoodDic().put("小杯雪碧",1);//创建接收者 ReceiverSeniorChef receiver=new SeniorChef();//将订单和接收者封装成命令对象OrderCommand cmd1 = new OrderCommand(receiver, order1);OrderCommand cmd2 = new OrderCommand(receiver, order2);//创建调用者 WaitorWaitor invoker = new Waitor();invoker.setCommand(cmd1);invoker.setCommand(cmd2);//调用命令invoker.orderUp();}
}

3. 优缺点

1，优点：

降低系统的耦合度。命令模式能将调用操作的对象与实现该操作的对象解耦。
增加或删除命令非常方便。采用命令模式增加与删除命令不会影响其他类，它满足“开闭原则”，对扩展比较灵活。
可以实现宏命令。命令模式可以与组合模式结合，将多个命令装配成一个组合命令，即宏命令。
方便实现 Undo 和 Redo 操作。命令模式可以与后面介绍的备忘录模式结合，实现命令的撤销与恢复。

2，缺点：

使用命令模式可能会导致某些系统有过多的具体命令类。
系统结构更加复杂。

4. 使用场景

系统需要将请求调用者和请求接收者解耦，使得调用者和接收者不直接交互。
系统需要在不同的时间指定请求、将请求排队和执行请求。
系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作。

5. JDK源码解析

Runable是一个典型命令模式，Runnable担当命令的角色，Thread充当的是调用者，start方法就是其执行方法

//命令接口(抽象命令角色)
public interface Runnable {public abstract void run();
}/*** 具体命令*/
public class TurnOffThread implements Runnable{private Receiver receiver; //接收者是对程序员开放的，可以自己定义接收者public TurnOffThread(Receiver receiver) {this.receiver = receiver;}public void run() {receiver.turnOFF();}
}//调用者
public class Thread implements Runnable {private Runnable target;public synchronized void start() {if (threadStatus != 0)throw new IllegalThreadStateException();group.add(this);boolean started = false;try {start0();//start0()会调用一个native方法，即调用系统方法，开启一个线程started = true;} finally {try {if (!started) {group.threadStartFailed(this);}} catch (Throwable ignore) {}}}private native void start0();
}

/*** 测试类*/
public class Demo {public static void main(String[] args) {Receiver receiver = new Receiver();//命令接收者TurnOffThread turnOffThread = new TurnOffThread(receiver);//创建命令对象Thread thread = new Thread(turnOffThread);//命令发起者thread.start();//调用命令}
}

责任链模式

为了避免请求发送者与多个请求处理者耦合在一起，将所有请求的处理者通过前一对象记住其下一个对象的引用而连成一条链；当有请求发生时，可将请求沿着这条链传递，直到有对象处理它为止。

1. 结构

职责链模式主要包含以下角色:

抽象处理者（Handler）角色：定义一个处理请求的接口，包含抽象处理方法和一个后继连接。
具体处理者（Concrete Handler）角色：实现抽象处理者的处理方法，判断能否处理本次请求，如果可以处理请求则处理，否则将该请求转给它的后继者。
客户类（Client）角色：创建处理链，并向链头的具体处理者对象提交请求，它不关心处理细节和请求的传递过程。

2. 案例实现

现需要开发一个请假流程控制系统。请假一天以下的假只需要小组长同意即可；请假1天到3天的假还需要部门经理同意；请求3天到7天还需要总经理同意才行。

类图如下：

在这里插入图片描述

代码如下：

//请假条
public class LeaveRequest {private String name;//姓名private int num;//请假天数private String content;//请假内容public LeaveRequest(String name, int num, String content) {this.name = name;this.num = num;this.content = content;}public String getName() {return name;}public int getNum() {return num;}public String getContent() {return content;}
}//处理者抽象类
public abstract class Handler {protected final static int NUM_ONE = 1;protected final static int NUM_THREE = 3;protected final static int NUM_SEVEN = 7;//该领导处理的请假天数区间private int numStart;private int numEnd;//领导上面还有领导private Handler nextHandler;//设置请假天数范围 上不封顶public Handler(int numStart) {this.numStart = numStart;}//设置请假天数范围public Handler(int numStart, int numEnd) {this.numStart = numStart;this.numEnd = numEnd;}//设置上级领导public void setNextHandler(Handler nextHandler){this.nextHandler = nextHandler;}//提交请假条public final void submit(LeaveRequest leave){if(0 == this.numStart){return;}//如果请假天数达到该领导者的处理要求if(leave.getNum() >= this.numStart){this.handleLeave(leave);//如果还有上级 并且请假天数超过了当前领导的处理范围if(null != this.nextHandler && leave.getNum() > numEnd){this.nextHandler.submit(leave);//继续提交} else {System.out.println("流程结束");}}}//各级领导处理请假条方法protected abstract void handleLeave(LeaveRequest leave);
}//小组长
public class GroupLeader extends Handler {public GroupLeader() {//小组长处理1-3天的请假super(Handler.NUM_ONE, Handler.NUM_THREE);}@Overrideprotected void handleLeave(LeaveRequest leave) {System.out.println(leave.getName() + "请假" + leave.getNum() + "天," + leave.getContent() + "。");System.out.println("小组长审批：同意。");}
}//部门经理
public class Manager extends Handler {public Manager() {//部门经理处理3-7天的请假super(Handler.NUM_THREE, Handler.NUM_SEVEN);}@Overrideprotected void handleLeave(LeaveRequest leave) {System.out.println(leave.getName() + "请假" + leave.getNum() + "天," + leave.getContent() + "。");System.out.println("部门经理审批：同意。");}
}//总经理
public class GeneralManager extends Handler {public GeneralManager() {//部门经理处理7天以上的请假super(Handler.NUM_SEVEN);}@Overrideprotected void handleLeave(LeaveRequest leave) {System.out.println(leave.getName() + "请假" + leave.getNum() + "天," + leave.getContent() + "。");System.out.println("总经理审批：同意。");}
}//测试类
public class Client {public static void main(String[] args) {//请假条来一张LeaveRequest leave = new LeaveRequest("小花",5,"身体不适");//各位领导GroupLeader groupLeader = new GroupLeader();Manager manager = new Manager();GeneralManager generalManager = new GeneralManager();groupLeader.setNextHandler(manager);//小组长的领导是部门经理manager.setNextHandler(generalManager);//部门经理的领导是总经理//之所以在这里设置上级领导，是因为可以根据实际需求来更改设置，如果实战中上级领导人都是固定的，则可以移到领导实现类中。//提交申请groupLeader.submit(leave);}
}

3. 优缺点

1，优点：

降低了对象之间的耦合度

该模式降低了请求发送者和接收者的耦合度。
增强了系统的可扩展性

可以根据需要增加新的请求处理类，满足开闭原则。
增强了给对象指派职责的灵活性

当工作流程发生变化，可以动态地改变链内的成员或者修改它们的次序，也可动态地新增或者删除责任。
责任链简化了对象之间的连接

一个对象只需保持一个指向其后继者的引用，不需保持其他所有处理者的引用，这避免了使用众多的 if 或者 if···else 语句。
责任分担

每个类只需要处理自己该处理的工作，不能处理的传递给下一个对象完成，明确各类的责任范围，符合类的单一职责原则。

2，缺点：

不能保证每个请求一定被处理。由于一个请求没有明确的接收者，所以不能保证它一定会被处理，该请求可能一直传到链的末端都得不到处理。
对比较长的职责链，请求的处理可能涉及多个处理对象，系统性能将受到一定影响。
职责链建立的合理性要靠客户端来保证，增加了客户端的复杂性，可能会由于职责链的错误设置而导致系统出错，如可能会造成循环调用。

4. 使用场景

一个请求不清楚哪个处理者可以处理，如果每个处理者都手动调用一遍太繁琐，这时就可以用责任链模式，将所有请求的处理者通过前一对象记住其下一个对象的引用而连成一条链；当有请求发生时，可将请求沿着这条链传递，直到有对象处理它为止。
当请求必须按顺序执行被多个处理者处理时，可以使用该模式

5. 源码解析

在javaWeb应用开发中，FilterChain是职责链（过滤器）模式的典型应用，以下是Filter的模拟实现分析:

模拟web请求Request以及web响应Response

public interface Request{}public interface Response{}

模拟web过滤器Filter

 public interface Filter {public void doFilter(Request req,Response res,FilterChain c);}

模拟实现具体过滤器

public class FirstFilter implements Filter {@Overridepublic void doFilter(Request request, Response response, FilterChain chain) {System.out.println("过滤器1 前置处理");// 先执行所有request再倒序执行所有responsechain.doFilter(request, response);System.out.println("过滤器1 后置处理");}
}public class SecondFilter  implements Filter {@Overridepublic void doFilter(Request request, Response response, FilterChain chain) {System.out.println("过滤器2 前置处理");// 先执行所有request再倒序执行所有responsechain.doFilter(request, response);System.out.println("过滤器2 后置处理");}
}

模拟实现过滤器链FilterChain

public class FilterChain {private List<Filter> filters = new ArrayList<Filter>();private int index = 0;// 链式调用public FilterChain addFilter(Filter filter) {this.filters.add(filter);return this;}public void doFilter(Request request, Response response) {if (index == filters.size()) {return;}Filter filter = filters.get(index);index++;filter.doFilter(request, response, this);}
}

测试类

public class Client {public static void main(String[] args) {Request  req = null;Response res = null ;FilterChain filterChain = new FilterChain();filterChain.addFilter(new FirstFilter()).addFilter(new SecondFilter());filterChain.doFilter(req,res);}
}

状态模式

1. 结构

状态模式包含以下主要角色。

环境（Context）角色： 也称为上下文，它定义了客户程序需要的接口，维护一个当前状态，并将与状态相关的操作委托给当前状态对象来处理。
抽象状态（State）角色： 定义一个接口，用以封装环境对象中的特定状态所对应的行为。
具体状态（Concrete State）角色： 实现抽象状态所对应的行为。

2. 案例实现

【例】 通过按钮来控制一个电梯的状态，一个电梯有开门状态，关门状态，停止状态，运行状态。每一种状态改变，都有可能要根据其他状态来更新处理。例如，如果电梯门现在处于运行时状态，就不能进行开门操作，而如果电梯门是停止状态，就可以执行开门操作。

不适用状态模式

代码如下：

public interface ILift {//电梯的4个状态//开门状态public final static int OPENING_STATE = 1;//关门状态public final static int CLOSING_STATE = 2;//运行状态public final static int RUNNING_STATE = 3;//停止状态public final static int STOPPING_STATE = 4;//设置电梯的状态public void setState(int state);//电梯的动作public void open();public void close();public void run();public void stop();
}public class Lift implements ILift {private int state;@Overridepublic void setState(int state) {this.state = state;}//执行关门动作@Overridepublic void close() {switch (this.state) {case OPENING_STATE:System.out.println("电梯关门了。。。");//只有开门状态可以关闭电梯门，可以对应电梯状态表来看this.setState(CLOSING_STATE);//关门之后电梯就是关闭状态了break;case CLOSING_STATE://do nothing //已经是关门状态，不能关门break;case RUNNING_STATE://do nothing //运行时电梯门是关着的，不能关门break;case STOPPING_STATE://do nothing //停止时电梯也是关着的，不能关门break;}}//执行开门动作@Overridepublic void open() {switch (this.state) {case OPENING_STATE://门已经开了，不能再开门了//do nothingbreak;case CLOSING_STATE://关门状态，门打开:System.out.println("电梯门打开了。。。");this.setState(OPENING_STATE);break;case RUNNING_STATE://do nothing 运行时电梯不能开门break;case STOPPING_STATE:System.out.println("电梯门开了。。。");//电梯停了，可以开门了this.setState(OPENING_STATE);break;}}//执行运行动作@Overridepublic void run() {switch (this.state) {case OPENING_STATE://电梯不能开着门就走//do nothingbreak;case CLOSING_STATE://门关了，可以运行了System.out.println("电梯开始运行了。。。");this.setState(RUNNING_STATE);//现在是运行状态break;case RUNNING_STATE://do nothing 已经是运行状态了break;case STOPPING_STATE:System.out.println("电梯开始运行了。。。");this.setState(RUNNING_STATE);break;}}//执行停止动作@Overridepublic void stop() {switch (this.state) {case OPENING_STATE: //开门的电梯已经是是停止的了(正常情况下)//do nothingbreak;case CLOSING_STATE://关门时才可以停止System.out.println("电梯停止了。。。");this.setState(STOPPING_STATE);break;case RUNNING_STATE://运行时当然可以停止了System.out.println("电梯停止了。。。");this.setState(STOPPING_STATE);break;case STOPPING_STATE://do nothingbreak;}}
}public class Client {public static void main(String[] args) {Lift lift = new Lift();lift.setState(ILift.STOPPING_STATE);//电梯是停止的lift.open();//开门lift.close();//关门lift.run();//运行lift.stop();//停止}
}

问题分析：

使用了大量的switch…case这样的判断（if…else也是一样)，使程序的可阅读性变差。
扩展性很差。如果新加了断电的状态，我们需要修改上面判断逻辑

使用状态模式

对上述电梯的案例使用状态模式进行改进。类图如下：

在这里插入图片描述

代码如下：

//环境角色
public class Context {//定义出所有的电梯状态public final static OpenningState openningState = new OpenningState();//开门状态，这时候电梯只能关闭public final static ClosingState closeingState = new ClosingState();//关闭状态，这时候电梯可以运行、停止和开门public final static RunningState runningState = new RunningState();//运行状态，这时候电梯只能停止public final static StoppingState stoppingState = new StoppingState();//停止状态，这时候电梯可以开门、运行//定义一个当前电梯状态private LiftState liftState;public LiftState getLiftState() {return this.liftState;}public void setLiftState(LiftState liftState) {//当前环境改变this.liftState = liftState;//把当前的环境通知到各个实现类中this.liftState.setContext(this);}public void open() {this.liftState.open();}public void close() {this.liftState.close();}public void run() {this.liftState.run();}public void stop() {this.liftState.stop();}
}//抽象状态类
public abstract class LiftState {//定义一个环境角色，也就是封装状态的变化引起的功能变化protected Context context;public void setContext(Context context) {this.context = context;}//电梯开门动作public abstract void open();//电梯关门动作public abstract void close();//电梯运行动作public abstract void run();//电梯停止动作public abstract void stop();
}//开启状态
public class OpenningState extends LiftState {//开启当然可以关闭了，我就想测试一下电梯门开关功能@Overridepublic void open() {System.out.println("电梯门开启...");}@Overridepublic void close() {//状态修改super.context.setLiftState(Context.closeingState);//动作委托为CloseState来执行，也就是委托给了ClosingState子类执行这个动作super.context.close();}//电梯门不能开着就跑，这里什么也不做@Overridepublic void run() {//do nothing}//开门状态已经是停止的了@Overridepublic void stop() {//do nothing}
}//运行状态
public class RunningState extends LiftState {//运行的时候开电梯门？你疯了！电梯不会给你开的@Overridepublic void open() {//do nothing}//电梯门关闭？这是肯定了@Overridepublic void close() {//虽然可以关门，但这个动作不归我执行//do nothing}//这是在运行状态下要实现的方法@Overridepublic void run() {System.out.println("电梯正在运行...");}//这个事绝对是合理的，光运行不停止还有谁敢做这个电梯？！估计只有上帝了@Overridepublic void stop() {super.context.setLiftState(Context.stoppingState);super.context.stop();}
}//停止状态
public class StoppingState extends LiftState {//停止状态，开门，那是要的！@Overridepublic void open() {//状态修改super.context.setLiftState(Context.openningState);//动作委托为CloseState来执行，也就是委托给了ClosingState子类执行这个动作super.context.open();}@Overridepublic void close() {//虽然可以关门，但这个动作不归我执行//状态修改super.context.setLiftState(Context.closeingState);//动作委托为CloseState来执行，也就是委托给了ClosingState子类执行这个动作super.context.close();}//停止状态再跑起来，正常的很@Overridepublic void run() {//状态修改super.context.setLiftState(Context.runningState);//动作委托为CloseState来执行，也就是委托给了ClosingState子类执行这个动作super.context.run();}//停止状态是怎么发生的呢？当然是停止方法执行了@Overridepublic void stop() {System.out.println("电梯停止了...");}
}//关闭状态
public class ClosingState extends LiftState {@Override//电梯门关闭，这是关闭状态要实现的动作public void close() {System.out.println("电梯门关闭...");}//电梯门关了再打开，逗你玩呢，那这个允许呀@Overridepublic void open() {super.context.setLiftState(Context.openningState);super.context.open();}//电梯门关了就跑，这是再正常不过了@Overridepublic void run() {super.context.setLiftState(Context.runningState);super.context.run();}//电梯门关着，我就不按楼层@Overridepublic void stop() {super.context.setLiftState(Context.stoppingState);super.context.stop();}
}//测试类
public class Client {public static void main(String[] args) {Context context = new Context();context.setLiftState(new ClosingState());context.open();context.close();context.run();context.stop();}
}

3. 优缺点

1，优点：

将所有与某个状态有关的行为放到一个类中，并且可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为。
允许状态转换逻辑与状态对象合成一体，而不是某一个巨大的条件语句块。

2，缺点：

状态模式的使用必然会增加系统类和对象的个数。
状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱。
状态模式对"开闭原则"的支持并不太好。

4. 一些常见使用场景

在游戏开发中，角色的不同状态（如跑动，跳跃，攻击等）常常使用状态模式进行处理，角色在不同的状态下表现出不同的行为。
工作流或者订单处理中的各种状态，不同的状态下有不同的操作。
在开发工具或软件应用程序中，文档或者工具在不同模式下可能有不同的行为，例如图像编辑器的不同工具，或者文本编辑器的插入模式和命令模式。
复杂系统的开发中，系统可能处于多种复杂状态，对事件的处理可能会因为状态的不同而有所不同，例如电梯的运行状态，ATM机的各种状态等。

观察者模式

1. 定义

又被称为发布-订阅（Publish/Subscribe）模式，它定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态变化时，会通知所有的观察者对象，使他们能够自动更新自己。

2. 结构

在观察者模式中有如下角色：

Subject： 抽象主题（抽象被观察者），抽象主题角色把所有观察者对象保存在一个集合里，每个主题都可以有任意数量的观察者，抽象主题提供一个接口，可以增加和删除观察者对象。
ConcreteSubject： 具体主题（具体被观察者），该角色将有关状态存入具体观察者对象，在具体主题的内部状态发生改变时，给所有注册过的观察者发送通知。
Observer： 抽象观察者，是观察者的抽象类，它定义了一个更新接口，使得在得到主题更改通知时更新自己。
ConcrereObserver： 具体观察者，实现抽象观察者定义的更新接口，以便在得到主题更改通知时更新自身的状态。

3. 案例实现

【例】微信公众号

在使用微信公众号时，大家都会有这样的体验，当你关注的公众号中有新内容更新的话，它就会推送给关注公众号的微信用户端。我们使用观察者模式来模拟这样的场景，微信用户就是观察者，微信公众号是被观察者，有多个的微信用户关注了程序猿这个公众号。

类图如下：

在这里插入图片描述

代码如下：

定义，里面定义一个更新的方法

//抽象观察者类
public interface Observer {void update(String message);
}//具体观察者类
public class WeixinUser implements Observer {// 微信用户名private String name;public WeixinUser(String name,Subject subject) {this.name = name;subject.attach(this);}@Overridepublic void update(String message) {System.out.println(name + "-" + message);}
}//抽象主题类
public interface Subject {//增加订阅者public void attach(Observer observer);//删除订阅者public void detach(Observer observer);//通知订阅者更新消息public void notify(String message);
}//具体主题（具体被观察者）
public class SubscriptionSubject implements Subject {//储存订阅公众号的微信用户private List<Observer> weixinUserlist = new ArrayList<Observer>();@Overridepublic void attach(Observer observer) {weixinUserlist.add(observer);}@Overridepublic void detach(Observer observer) {weixinUserlist.remove(observer);}@Overridepublic void notify(String message) {for (Observer observer : weixinUserlist) {observer.update(message);}}
}//**客户端程序**
public class Client {public static void main(String[] args) {SubscriptionSubject mSubscriptionSubject=new SubscriptionSubject();//创建微信用户WeixinUser user1=new WeixinUser("孙悟空",mSubscriptionSubject);WeixinUser user2=new WeixinUser("猪悟能",mSubscriptionSubject);WeixinUser user3=new WeixinUser("沙悟净",mSubscriptionSubject);//公众号更新发出消息给订阅的微信用户mSubscriptionSubject.notify("传智黑马的专栏更新了");}
}

4. 优缺点

1，优点：

被观察者和观察者之间是抽象耦合的；耦合度较低，两者之间的关联仅仅在于消息的通知；被观察者⽆需关⼼他的观察者
被观察者发送通知，所有注册的观察者都会收到信息【可以实现广播机制】

2，缺点：

观察者只知道被观察对象发⽣了变化，但不知变化的过程和缘由；
观察者同时也可能是被观察者，消息传递的链路可能会过⻓ ，完成所有通知花费时间较多；
如果观察者和被观察者之间产⽣循环依赖，或者消息传递链路形成闭环，会导致⽆限循环；

5. 使用场景

对象间存在一对多关系，一个对象的状态发生改变要通知其他对象。
如：在⽀付场景下，⽤户购买⼀件商品，当⽀付成功之后三⽅会回调⾃身，在这个时候系统可能会有很多需要执⾏的逻辑（如：更新订单状态，发送邮件通知，赠送礼品…），这些逻辑之间并没有强耦合，因此天然适合使⽤观察者模式去实现这些功能，当有更多的操作时，只需要添加新的观察者就能实现，完美实现了对修改关闭，对扩展开放的开闭原则。

6. JDK中提供的实现

在 Java 中，通过 java.util.Observable 类和 java.util.Observer 接口定义了观察者模式，只要实现它们的子类就可以编写观察者模式实例。

1，Observable类

Observable 类是抽象目标类（被观察者），它有一个 Vector 集合成员变量，用于保存所有要通知的观察者对象，下面来介绍它最重要的 3 个方法。

void addObserver(Observer o) 方法： 用于将新的观察者对象添加到集合中。
void notifyObservers(Object arg) 方法： 调用集合中的所有观察者对象的 update方法，通知它们数据发生改变。通常越晚加入集合的观察者越先得到通知。
void setChange() 方法： 用来设置一个 boolean 类型的内部标志，注明目标对象发生了变化。当它为true时，notifyObservers() 才会通知观察者。

2，Observer 接口

Observer 接口是抽象观察者，它监视目标对象的变化，当目标对象发生变化时，观察者得到通知，并调用 update 方法，进行相应的工作。

【例】警察抓小偷

警察抓小偷也可以使用观察者模式来实现，警察是观察者，小偷是被观察者。

代码如下：

小偷是一个被观察者，所以需要继承Observable类

public class Thief extends Observable {private String name;public Thief(String name) {this.name = name;}public void setName(String name) {this.name = name;}public String getName() {return name;}public void steal() {System.out.println("小偷：我偷东西了，有没有人来抓我！！！");super.setChanged(); //changed  = truesuper.notifyObservers();}
}

警察是一个观察者，所以需要让其实现Observer接口

public class Policemen implements Observer {private String name;public Policemen(String name) {this.name = name;}public void setName(String name) {this.name = name;}public String getName() {return name;}@Overridepublic void update(Observable o, Object arg) {System.out.println("警察：" + ((Thief) o).getName() + "，我已经盯你很久了，你可以保持沉默，但你所说的将成为呈堂证供！！！");}
}

客户端代码

public class Client {public static void main(String[] args) {//创建小偷对象Thief t = new Thief("隔壁老王");//创建警察对象Policemen p = new Policemen("小李");//让警察盯着小偷t.addObserver(p);//小偷偷东西t.steal();}
}

中介者模式

1. 概述

一般来说，同事类之间的关系是比较复杂的，多个同事类之间互相关联时，他们之间的关系会呈现为复杂的网状结构，这是一种过度耦合的架构，即不利于类的复用，也不稳定。例如在下左图中，有六个同事类对象，假如对象1发生变化，那么将会有4个对象受到影响。如果对象2发生变化，那么将会有5个对象受到影响。也就是说，同事类之间直接关联的设计是不好的。

如果引入中介者模式，那么同事类之间的关系将变为星型结构，从下右图中可以看到，任何一个类的变动，只会影响的类本身，以及中介者，这样就减小了系统的耦合。一个好的设计，必定不会把所有的对象关系处理逻辑封装在本类中，而是使用一个专门的类来管理那些不属于自己的行为。

在这里插入图片描述

定义：

又叫调停模式，定义一个中介角色来封装一系列对象之间的交互，使原有对象之间的耦合松散，且可以独立地改变它们之间的交互。

2. 结构

中介者模式包含以下主要角色：

抽象中介者（Mediator）角色： 它是中介者的接口，提供了同事对象注册与转发同事对象信息的抽象方法。
具体中介者（ConcreteMediator）角色： 实现中介者接口，定义一个 List 来管理同事对象，协调各个同事角色之间的交互关系，因此它依赖于同事角色。
抽象同事类（Colleague）角色： 定义同事类的接口，保存中介者对象，提供同事对象交互的抽象方法，实现所有相互影响的同事类的公共功能。
具体同事类（Concrete Colleague）角色： 是抽象同事类的实现者，当需要与其他同事对象交互时，由中介者对象负责后续的交互。

3. 案例实现

【例】租房

现在租房基本都是通过房屋中介，房主将房屋托管给房屋中介，而租房者从房屋中介获取房屋信息。房屋中介充当租房者与房屋所有者之间的中介者。

类图如下：

在这里插入图片描述

代码如下：

//抽象中介者
public abstract class Mediator {//申明一个联络方法public abstract void constact(String message,Person person);
}//具体中介者——中介机构
public class MediatorStructure extends Mediator {//首先中介结构必须知道所有房主和租房者的信息private HouseOwner houseOwner;private Tenant tenant;public HouseOwner getHouseOwner() {return houseOwner;}public void setHouseOwner(HouseOwner houseOwner) {this.houseOwner = houseOwner;}public Tenant getTenant() {return tenant;}public void setTenant(Tenant tenant) {this.tenant = tenant;}public void constact(String message, Person person) {if (person == houseOwner) {          //如果是房主，则租房者获得信息tenant.getMessage(message);} else {       //反正则是房主获得信息houseOwner.getMessage(message);}}
}//抽象同事类
public abstract class Person {protected String name;protected Mediator mediator;public Person(String name,Mediator mediator){this.name = name;this.mediator = mediator;}
}//具体同事类——房屋拥有者
public class HouseOwner extends Person {public HouseOwner(String name, Mediator mediator) {super(name, mediator);mediator.setHouseOwner(this);}//与中介者联系public void constact(String message){mediator.constact(message, this);}//获取信息public void getMessage(String message){System.out.println("房主" + name +"获取到的信息：" + message);}
}//具体同事类——承租人
public class Tenant extends Person {public Tenant(String name, Mediator mediator) {super(name, mediator);mediator.setTenant(this);}//与中介者联系public void constact(String message){mediator.constact(message, this);}//获取信息public void getMessage(String message){System.out.println("租房者" + name +"获取到的信息：" + message);}
}//测试类
public class Client {public static void main(String[] args) {//一个房主、一个租房者、一个中介机构MediatorStructure mediator = new MediatorStructure();//房主和租房者只需要知道中介机构即可HouseOwner houseOwner = new HouseOwner("张三", mediator);Tenant tenant = new Tenant("李四", mediator);tenant.constact("需要租三室的房子");houseOwner.constact("我这有三室的房子，你需要租吗？");}
}

4. 优缺点

1，优点：

松散耦合
中介者模式通过把多个同事对象之间的交互封装到中介者对象里面，从而使得同事对象之间松散耦合，基本上可以做到互补依赖。这样一来，同事对象就可以独立地变化和复用，而不再像以前那样“牵一处而动全身”了。
集中控制交互
多个同事对象的交互，被封装在中介者对象里面集中管理，使得这些交互行为发生变化的时候，只需要修改中介者对象就可以了，当然如果是已经做好的系统，那么就扩展中介者对象，而各个同事类不需要做修改。
一对多关联转变为一对一的关联
没有使用中介者模式的时候，同事对象之间的关系通常是一对多的，引入中介者对象以后，中介者对象和同事对象的关系通常变成双向的一对一，这会让对象的关系更容易理解和实现。

2，缺点：

当同事类太多时，中介者的职责将很大，它会变得复杂而庞大，以至于系统难以维护。

5. 一些常见的中介者模式应用场

聊天室：在聊天室应用中，如果每个用户都直接与其他所有用户通信，那么系统将变得复杂且难以维护。使用中介者模式后，每个用户只需要和中介者通信，然后由中介者将消息传递给其他用户，降低了用户之间的通信复杂性。
各种GUI控件间的交互：例如在一个复杂的界面中，可能有多个按钮，文本框，列表等控件，他们之间可能存在互相影响的行为，如果他们直接耦合，将会极度复杂且难以维护。使用中介者模式，所有的控件只需与中介者通信，由中介者调控各个控件之间的关系。
地方航空交通控制台：在该系统中，飞机不直接与其他飞机通信，而是通过航空交通管制塔（中介者）进行通信。管制塔会跟踪每架飞机的动态并且指导飞机在何时降落、起飞、飞行路线等。
MVC（Model-View-Controller）架构中的控制器：在MVC架构中，控制器就充当了一个中介者的角色，模型和视图不直接进行通信，都是通过控制器来进行的，这样就降低了模型和视图之间的耦合度。

迭代器模式

6.8.1 定义

提供一个对象来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。

6.8.2 结构

迭代器模式主要包含以下角色：

抽象聚合（Aggregate）角色： 定义存储、添加、删除聚合元素以及创建迭代器对象的接口。
具体聚合（ConcreteAggregate）角色： 实现抽象聚合类，返回一个具体迭代器的实例。
抽象迭代器（Iterator）角色： 定义访问和遍历聚合元素的接口，通常包含 hasNext()、next() 等方法。
具体迭代器（Concretelterator）角色： 实现抽象迭代器接口中所定义的方法，完成对聚合对象的遍历，记录遍历的当前位置。

6.8.3 案例实现

【例】定义一个可以存储学生对象的容器对象，将遍历该容器的功能交由迭代器实现：

代码如下：

//定义迭代器接口
public interface StudentIterator {boolean hasNext();Student next();
}//定义具体的迭代器类
public class StudentIteratorImpl implements StudentIterator {private List<Student> list;private int position = 0;public StudentIteratorImpl(List<Student> list) {this.list = list;}@Overridepublic boolean hasNext() {return position < list.size();}@Overridepublic Student next() {Student currentStudent = list.get(position);position ++;return currentStudent;}
}//定义抽象容器类
public interface StudentAggregate {void addStudent(Student student);void removeStudent(Student student);StudentIterator getStudentIterator();
}//定义具体的容器类
public class StudentAggregateImpl implements StudentAggregate {private List<Student> list = new ArrayList<Student>();  // 学生列表@Overridepublic void addStudent(Student student) {this.list.add(student);}@Overridepublic void removeStudent(Student student) {this.list.remove(student);}@Overridepublic StudentIterator getStudentIterator() {return new StudentIteratorImpl(list);}
}

6.8.4 优缺点

1，优点：

它支持以不同的方式遍历一个聚合对象，在同一个聚合对象上可以定义多种遍历方式。在迭代器模式中只需要用一个不同的迭代器来替换原有迭代器即可改变遍历算法，我们也可以自己定义迭代器的子类以支持新的遍历方式。
迭代器简化了聚合类。由于引入了迭代器，在原有的聚合对象中不需要再自行提供数据遍历等方法，这样可以简化聚合类的设计。
在迭代器模式中，由于引入了抽象层，增加新的聚合类和迭代器类都很方便，无须修改原有代码，满足 “开闭原则” 的要求。

2，缺点：

增加了类的个数，这在一定程度上增加了系统的复杂性。

6.8.5 使用场景

当需要为聚合对象提供多种遍历方式时
当需要为遍历不同的聚合结构提供一个统一的接口时。
当访问一个聚合对象的内容而无须暴露其内部细节的表示时。

6.8.6 JDK源码解析

迭代器模式在JAVA的很多集合类中被广泛应用，接下来看看JAVA源码中是如何使用迭代器模式的。

List<String> list = new ArrayList<>();
Iterator<String> iterator = list.iterator(); //list.iterator()方法返回的肯定是Iterator接口的子实现类对象
while (iterator.hasNext()) {System.out.println(iterator.next());
}

看完这段代码是不是很熟悉，与我们上面代码基本类似。单列集合都使用到了迭代器，我们以ArrayList举例来说明

List： 抽象聚合类
ArrayList： 具体的聚合类
Iterator： 抽象迭代器
list.iterator()： 返回的是实现了 Iterator 接口的具体迭代器对象

具体的来看看 ArrayList的代码实现

public class ArrayList<E> extends AbstractList<E>implements List<E>, RandomAccess, Cloneable, java.io.Serializable {public Iterator<E> iterator() {return new Itr();}private class Itr implements Iterator<E> {int cursor;       // 下一个要返回元素的索引int lastRet = -1; // 上一个返回元素的索引int expectedModCount = modCount;Itr() {}//判断是否还有元素public boolean hasNext() {return cursor != size;}//获取下一个元素public E next() {checkForComodification();int i = cursor;if (i >= size)throw new NoSuchElementException();Object[] elementData = ArrayList.this.elementData;if (i >= elementData.length)throw new ConcurrentModificationException();cursor = i + 1;return (E) elementData[lastRet = i];}...
}

这部分代码还是比较简单，大致就是在 iterator 方法中返回了一个实例化的 Iterator 对象。Itr是一个内部类，它实现了 Iterator 接口并重写了其中的抽象方法。

注意：当我们在使用JAVA开发的时候，想使用迭代器模式的话，只要让我们自己定义的容器类实现java.util.Iterable并实现其中的iterator()方法使其返回一个 java.util.Iterator 的实现类就可以了。

访问者模式

1. 定义

封装一些作用于某种数据结构中的各元素的操作，它可以在不改变这个对象结构的前提下定义作用于这些元素的新的操作。

2. 结构

访问者模式包含以下主要角色:

抽象访问者（Visitor）角色定义了对每一个元素（Element）访问的行为，它的参数就是可以访问的元素，它的方法个数理论上来讲与元素类个数（Element的实现类个数）是一样的，从这点不难看出，访问者模式要求元素类的个数不能改变。
具体访问者（ConcreteVisitor）角色： 给出对每一个元素类访问时所产生的具体行为。
抽象元素（Element）角色： 定义了一个接受访问者的方法（accept），其意义是指，每一个元素都要可以被访问者访问。
具体元素（ConcreteElement）角色： 提供接受访问方法的具体实现，而这个具体的实现，通常情况下是使用访问者提供的访问该元素类的方法。
对象结构（Object Structure）角色： 定义当中所提到的对象结构，对象结构是一个抽象表述，具体点可以理解为一个具有容器性质或者复合对象特性的类，它会含有一组元素（Element），并且可以迭代这些元素，供访问者访问。

3. 案例实现

【例】给宠物喂食

现在养宠物的人特别多，我们就以这个为例，当然宠物还分为狗，猫等，要给宠物喂食的话，主人可以喂，其他人也可以喂食。

访问者角色： 给宠物喂食的人
具体访问者角色： 主人、其他人
抽象元素角色： 动物抽象类
具体元素角色： 宠物狗、宠物猫
结构对象角色： 主人家

类图如下：

在这里插入图片描述

代码如下：

//抽象访问者（定义了对每一个元素`（Element）`访问的行为）
public interface Person {void feed(Cat cat);void feed(Dog dog);
}//具体访问者
public class Owner implements Person {@Overridepublic void feed(Cat cat) {System.out.println("主人喂食猫");}@Overridepublic void feed(Dog dog) {System.out.println("主人喂食狗");}
}
//具体访问者
public class Someone implements Person {@Overridepublic void feed(Cat cat) {System.out.println("其他人喂食猫");}@Overridepublic void feed(Dog dog) {System.out.println("其他人喂食狗");}
}//抽象元素（定义了一个接受访问者的方法（`accept`））
public interface Animal {void accept(Person person);
}//具体元素（使用访问者提供的访问该元素类的方法）
public class Dog implements Animal {@Overridepublic void accept(Person person) {person.feed(this);//方法实现通常情况下是使用访问者提供的访问该元素类的方法System.out.println("好好吃，汪汪汪！！！");}
}
//具体元素
public class Cat implements Animal {@Overridepublic void accept(Person person) {person.feed(this);System.out.println("好好吃，喵喵喵！！！");}
}//对象结构（一个具有容器性质或者复合对象特性的类，它会含有一组元素（`Element`），并且可以迭代这些元素，供访问者访问）
public class Home {private List<Animal> nodeList = new ArrayList<Animal>();public void action(Person person) {for (Animal node : nodeList) {node.accept(person);}}//添加操作public void add(Animal animal) {nodeList.add(animal);}
}//测试类
public class Client {public static void main(String[] args) {//创建对象结构Home home = new Home();//添加元素home.add(new Dog());home.add(new Cat());Owner owner = new Owner();home.action(owner);Someone someone = new Someone();home.action(someone);}
}

4. 优缺点

1，优点：

扩展性好
在不修改对象结构中的元素的情况下，为对象结构中的元素添加新的功能。
复用性好
通过访问者来定义整个对象结构通用的功能，从而提高复用程度。
分离无关行为
通过访问者来分离无关的行为，把相关的行为封装在一起，构成一个访问者，这样每一个访问者的功能都比较单一。

2，缺点：

对象结构变化很困难
在访问者模式中，每增加一个新的元素类，都要在每一个具体访问者类中增加相应的具体操作，这违背了“开闭原则”。
违反了依赖倒置原则
访问者模式依赖了具体类，而没有依赖抽象类。

5. 使用场景

对象结构相对稳定，但其操作算法经常变化的程序。
对象结构中的对象需要提供多种不同且不相关的操作，而且要避免让这些操作的变化影响对象的结构。

举个例子1：假设你有一个对象结构，它包含了一个计算器的各种部件的集合，比如键盘，鼠标，显示器等。你可能需要实现很多不同的操作，
比如:

计数器访问者，它的任务是计数这个集合中的每种类型的元素数量。
渲染访问者，它的任务是渲染出每个部件的视觉表现。
生命周期管理访问者，它的任务是定期检查是否需要清理或替换这些部件。

在上述这些操作中，每种操作都和其他操作没有直接的关系，也就是说这些操作是不相关的。并且，每种操作可能都会很复杂，包括很多步骤。但是通过使用访问者模式，我们可以避免让这些复杂的操作逻辑侵入对象结构中，使得代码更加清晰，可读性更高。

举个例子2：有个人物对象包含老师和学生两种身份。有两个角度需要访问这两种元素，

家长访问者：关心学生的成绩和老师的能力
校长访问者：关心学生人数和老师任课科目

这些访问操作不同也不相干，并且都需要对每个元素进行访问

6. 扩展——双分派

访问者模式用到了一种双分派的技术。

1，分派：

变量被声明时的类型叫做变量的静态类型，有些人又把静态类型叫做明显类型；而变量所引用的对象的真实类型又叫做变量的实际类型。比如 Map map = new HashMap() ，map变量的静态类型是 Map ，实际类型是 HashMap 。根据对象的类型而对方法进行的选择，就是分派(Dispatch)，分派(Dispatch)又分为两种，即静态分派和动态分派。

静态分派(Static Dispatch) 发生在编译时期，分派根据静态类型信息发生。静态分派对于我们来说并不陌生，方法重载就是静态分派。
动态分派(Dynamic Dispatch) 发生在运行时期，动态分派动态地置换掉某个方法。Java通过方法的重写支持动态分派。

2，动态分派：

通过方法的重写支持动态分派。

public class Animal {public void execute() {System.out.println("Animal");}
}public class Dog extends Animal {@Overridepublic void execute() {System.out.println("dog");}
}public class Cat extends Animal {@Overridepublic void execute() {System.out.println("cat");}
}public class Client {public static void main(String[] args) {Animal a = new Dog();a.execute();Animal a1 = new Cat();a1.execute();}
}

上面代码的结果大家应该直接可以说出来，这不就是多态吗！运行执行的是子类中的方法。

Java编译器在编译时期并不总是知道哪些代码会被执行，因为编译器仅仅知道对象的静态类型，而不知道对象的真实类型；而方法的调用则是根据对象的真实类型，而不是静态类型。

3，静态分派：

通过方法重载支持静态分派。

public class Animal {
}public class Dog extends Animal {
}public class Cat extends Animal {
}public class Execute {public void execute(Animal a) {System.out.println("Animal");}public void execute(Dog d) {System.out.println("dog");}public void execute(Cat c) {System.out.println("cat");}
}public class Client {public static void main(String[] args) {Animal a = new Animal();Animal a1 = new Dog();Animal a2 = new Cat();Execute exe = new Execute();exe.execute(a);exe.execute(a1);exe.execute(a2);}
}

运行结果：

这个结果可能出乎一些人的意料了，为什么呢？

重载方法的分派是根据静态类型进行的，这个分派过程在编译时期就完成了。

4，双分派——访问者模式：

所谓双分派技术就是在选择一个方法的时候，不仅仅要根据消息接收者（receiver）的运行时区别，还要根据参数的运行时区别。

public class Animal {public void accept(Execute exe) {exe.execute(this);}
}public class Dog extends Animal {public void accept(Execute exe) {exe.execute(this);}
}public class Cat extends Animal {public void accept(Execute exe) {exe.execute(this);}
}public class Execute {public void execute(Animal a) {System.out.println("animal");}public void execute(Dog d) {System.out.println("dog");}public void execute(Cat c) {System.out.println("cat");}
}public class Client {public static void main(String[] args) {Animal a = new Animal();Animal d = new Dog();Animal c = new Cat();Execute exe = new Execute();a.accept(exe);d.accept(exe);c.accept(exe);}
}

运行结果如下：

在这里插入图片描述

分析：在上面代码中，客户端将Execute对象做为参数传递给Animal类型的变量调用的方法，这里完成第一次分派，这里是方法重写，所以是动态分派，执行的事子类方法；接着子类accept 将自己this作为参数传递进去，这里就完成了第二次分派，这里是方法重载，为静态分配，但是传递的是 this 具体的实际类型对象，所以输出为想要的结果。

备忘录模式

1. 定义

又叫快照模式，在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，以便以后当需要时能将该对象恢复到原先保存的状态。

2. 结构

备忘录模式的主要角色如下：

发起人（Originator）角色：记录当前时刻的内部状态信息，提供创建备忘录和恢复备忘录数据的功能，实现其他业务功能，它可以访问备忘录里的所有信息。
备忘录（Memento）角色：负责存储发起人的内部状态，在需要的时候提供这些内部状态给发起人。
管理者（Caretaker）角色：对备忘录进行管理，提供保存与获取备忘录的功能，但其不能对备忘录的内容进行访问与修改。

备忘录有两个等效的接口：

窄接口：管理者(Caretaker)对象（和其他发起人对象之外的任何对象）看到的是备忘录的窄接口(narror Interface)，这个窄接口只允许他把备忘录对象传给其他的对象。
宽接口：与管理者看到的窄接口相反，发起人对象可以看到一个宽接口(wide Interface)，这个宽接口允许它读取所有的数据，以便根据这些数据恢复这个发起人对象的内部状态。

3. 案例实现

【例】游戏挑战BOSS

游戏中的某个场景，一游戏角色有生命力、攻击力、防御力等数据，在打Boss前和后一定会不一样的，我们允许玩家如果感觉与Boss决斗的效果不理想可以让游戏恢复到决斗之前的状态。

3.1.“白箱”备忘录模式——破坏封装性

备忘录角色对任何对象都提供一个接口，即宽接口，备忘录角色的内部所存储的状态就对所有对象公开，即任何对象都可以获取修改改备忘录角色

代码如下：

//游戏状态存储类(备忘录类)
public class RoleStateMemento {private int vit;private int atk;private int def;public RoleStateMemento(int vit, int atk, int def) {this.vit = vit;this.atk = atk;this.def = def;}public int getVit() {return vit;}public void setVit(int vit) {this.vit = vit;}public int getAtk() {return atk;}public void setAtk(int atk) {this.atk = atk;}public int getDef() {return def;}public void setDef(int def) {this.def = def;}
}//游戏角色类
public class GameRole {private int vit; //生命力private int atk; //攻击力private int def; //防御力//初始化状态public void initState() {this.vit = 100;this.atk = 100;this.def = 100;}//战斗public void fight() {this.vit = 0;this.atk = 0;this.def = 0;}//保存角色状态public RoleStateMemento saveState() {return new RoleStateMemento(vit, atk, def);}//回复角色状态public void recoverState(RoleStateMemento roleStateMemento) {this.vit = roleStateMemento.getVit();this.atk = roleStateMemento.getAtk();this.def = roleStateMemento.getDef();}public void stateDisplay() {System.out.println("角色生命力：" + vit);System.out.println("角色攻击力：" + atk);System.out.println("角色防御力：" + def);}public int getVit() {return vit;}public void setVit(int vit) {this.vit = vit;}public int getAtk() {return atk;}public void setAtk(int atk) {this.atk = atk;}public int getDef() {return def;}public void setDef(int def) {this.def = def;}
}//角色状态管理者类
public class RoleStateCaretaker {private RoleStateMemento roleStateMemento;public RoleStateMemento getRoleStateMemento() {return roleStateMemento;}public void setRoleStateMemento(RoleStateMemento roleStateMemento) {this.roleStateMemento = roleStateMemento;}
}//测试类
public class Client {public static void main(String[] args) {System.out.println("------------大战Boss前------------");//大战Boss前GameRole gameRole = new GameRole();gameRole.initState();gameRole.stateDisplay();//保存进度RoleStateCaretaker roleStateCaretaker = new RoleStateCaretaker();roleStateCaretaker.setRoleStateMemento(gameRole.saveState());System.out.println("------------大战Boss后------------");//大战Boss时，损耗严重gameRole.fight();gameRole.stateDisplay();System.out.println("------------恢复之前状态------------");//恢复之前状态gameRole.recoverState(roleStateCaretaker.getRoleStateMemento());gameRole.stateDisplay();}
}

分析：白箱备忘录模式是破坏封装性的（保存后还可以随意更改状态）。但是通过程序员自律，同样可以在一定程度上实现模式的大部分用意。

3.2.“黑箱”备忘录模式——推荐

备忘录角色对发起人对象提供一个宽接口，而为其他对象提供一个窄接口。在Java语言中，实现双重接口的办法就是将备忘录类设计成发起人类的内部成员类。

将 RoleStateMemento 设为 GameRole 的内部类，从而将 RoleStateMemento 对象封装在 GameRole 里面；在外面提供一个标识接口 Memento 给 RoleStateCaretaker 及其他对象使用。这样 GameRole 类看到的是 RoleStateMemento 所有的接口，而RoleStateCaretaker 及其他对象看到的仅仅是标识接口 Memento 所暴露出来的接口，从而维护了封装型。

代码如下：

窄接口Memento，这是一个，因此没有定义出任何的方法

//标识接口，不定义出任何的方法（窄接口）
public interface Memento {
}/游戏角色类
public class GameRole {private int vit; //生命力private int atk; //攻击力private int def; //防御力//初始化状态public void initState() {this.vit = 100;this.atk = 100;this.def = 100;}//战斗public void fight() {this.vit = 0;this.atk = 0;this.def = 0;}//保存角色状态public Memento saveState() {return new RoleStateMemento(vit, atk, def);}//回复角色状态public void recoverState(Memento memento) {RoleStateMemento roleStateMemento = (RoleStateMemento) memento;this.vit = roleStateMemento.getVit();this.atk = roleStateMemento.getAtk();this.def = roleStateMemento.getDef();}public void stateDisplay() {System.out.println("角色生命力：" + vit);System.out.println("角色攻击力：" + atk);System.out.println("角色防御力：" + def);}public int getVit() {return vit;}public void setVit(int vit) {this.vit = vit;}public int getAtk() {return atk;}public void setAtk(int atk) {this.atk = atk;}public int getDef() {return def;}public void setDef(int def) {this.def = def;}//定义在角色内部（该内部类设置为私有的）private class RoleStateMemento implements Memento {private int vit;private int atk;private int def;public RoleStateMemento(int vit, int atk, int def) {this.vit = vit;this.atk = atk;this.def = def;}public int getVit() {return vit;}public void setVit(int vit) {this.vit = vit;}public int getAtk() {return atk;}public void setAtk(int atk) {this.atk = atk;}public int getDef() {return def;}public void setDef(int def) {this.def = def;}}
}//角色状态管理者类（获取备忘录对象接口，起到标识作用）
//由于这个接口仅仅是一个标识接口，因此负责人角色不可能改变这个备忘录对象的内容（起到保护密封内部类作用）
public class RoleStateCaretaker {private Memento memento;public Memento getMemento() {return memento;}public void setMemento(Memento memento) {this.memento = memento;}
}//客户端测试类
public class Client {public static void main(String[] args) {System.out.println("------------大战Boss前------------");//大战Boss前GameRole gameRole = new GameRole();gameRole.initState();gameRole.stateDisplay();//保存进度RoleStateCaretaker roleStateCaretaker = new RoleStateCaretaker();roleStateCaretaker.setMemento(gameRole.saveState());System.out.println("------------大战Boss后------------");//大战Boss时，损耗严重gameRole.fight();gameRole.stateDisplay();System.out.println("------------恢复之前状态------------");//恢复之前状态gameRole.recoverState(roleStateCaretaker.getMemento());gameRole.stateDisplay();}
}

4. 优缺点

1，优点：

提供了一种可以恢复状态的机制。当用户需要时能够比较方便地将数据恢复到某个历史的状态。
实现了内部状态的封装。除了创建它的发起人之外，其他对象都不能够访问这些状态信息。
简化了发起人的类。发起人不需要管理和保存其内部状态的各个备份，所有状态信息都保存在备忘录中，并由管理者进行管理，这符合单一职责原则。

2，缺点：

资源消耗大。如果要保存的内部状态信息过多或者特别频繁，将会占用比较大的内存资源。

5. 使用场景

需要保存与恢复数据的场景，如玩游戏时的中间结果的存档功能。
需要提供一个可回滚操作的场景，如 Word、记事本、Photoshop，idea等软件在编辑时按 Ctrl+Z 组合键，还有数据库中事务操作。

解释器模式

1. 定义

给定一个语言，定义它的文法表示，并定义一个解释器，这个解释器使用该标识来解释语言中的句子。

2. 结构

解释器模式包含以下主要角色。

抽象表达式（Abstract Expression）角色： 定义解释器的接口，约定解释器的解释操作，主要包含解释方法 interpret()。
终结符表达式（Terminal Expression）角色： 是抽象表达式的子类，用来实现文法中与终结符相关的操作，文法中的每一个终结符都有一个具体终结表达式与之相对应。
非终结符表达式（Nonterminal Expression）角色： 也是抽象表达式的子类，用来实现文法中与非终结符相关的操作，文法中的每条规则都对应于一个非终结符表达式。
环境（Context）角色： 通常包含各个解释器需要的数据或是公共的功能，一般用来传递被所有解释器共享的数据，后面的解释器可以从这里获取这些值。
客户端（Client）： 主要任务是将需要分析的句子或表达式转换成使用解释器对象描述的抽象语法树，然后调用解释器的解释方法，当然也可以通过环境角色间接访问解释器的解释方法。

3. 案例实现

【例】设计实现加减法的软件

在这里插入图片描述

代码如下：

//抽象角色
public abstract class AbstractExpression {public abstract int interpret(Context context);
}//终结符表达式角色
public class Value extends AbstractExpression {private int value;public Value(int value) {this.value = value;}@Overridepublic int interpret(Context context) {return value;}@Overridepublic String toString() {return new Integer(value).toString();}
}//非终结符表达式角色——加法表达式
public class Plus extends AbstractExpression {private AbstractExpression left;private AbstractExpression right;public Plus(AbstractExpression left, AbstractExpression right) {this.left = left;this.right = right;}@Overridepublic int interpret(Context context) {return left.interpret(context) + right.interpret(context);}@Overridepublic String toString() {return "(" + left.toString() + " + " + right.toString() + ")";}
}///非终结符表达式角色——减法表达式
public class Minus extends AbstractExpression {private AbstractExpression left;private AbstractExpression right;public Minus(AbstractExpression left, AbstractExpression right) {this.left = left;this.right = right;}@Overridepublic int interpret(Context context) {return left.interpret(context) - right.interpret(context);}@Overridepublic String toString() {return "(" + left.toString() + " - " + right.toString() + ")";}
}//终结符表达式角色——变量表达式
public class Variable extends AbstractExpression {private String name;public Variable(String name) {this.name = name;}@Overridepublic int interpret(Context ctx) {return ctx.getValue(this);}@Overridepublic String toString() {return name;}
}//环境类
public class Context {private Map<Variable, Integer> map = new HashMap<Variable, Integer>();public void assign(Variable var, Integer value) {map.put(var, value);}public int getValue(Variable var) {Integer value = map.get(var);return value;}
}//测试类
public class Client {public static void main(String[] args) {Context context = new Context();Variable a = new Variable("a");Variable b = new Variable("b");Variable c = new Variable("c");Variable d = new Variable("d");Variable e = new Variable("e");//Value v = new Value(1);context.assign(a, 1);context.assign(b, 2);context.assign(c, 3);context.assign(d, 4);context.assign(e, 5);AbstractExpression expression = new Minus(new Plus(new Plus(new Plus(a, b), c), d), e);System.out.println(expression + "= " + expression.interpret(context));}
}

4. 优缺点

1，优点：

易于改变和扩展文法。
由于在解释器模式中使用类来表示语言的文法规则，因此可以通过继承等机制来改变或扩展文法。每一条文法规则都可以表示为一个类，因此可以方便地实现一个简单的语言。
实现文法较为容易。
在抽象语法树中每一个表达式节点类的实现方式都是相似的，这些类的代码编写都不会特别复杂。
增加新的解释表达式较为方便。
如果用户需要增加新的解释表达式只需要对应增加一个新的终结符表达式或非终结符表达式类，原有表达式类代码无须修改，符合 “开闭原则”。

2，缺点：