一、责任链模式
二、命令模式
在软件开发中，我们经常需要向某些对象发送请求(调用其中的某个或某些方法)，但是并不知道请求的接收者是谁，也不知道被请求的操作是哪个，此时，我们特别希望能够以一种松耦合的方式来设计软件，使得请求发送者与请求接收者能够消除彼此之间的耦合，让对象之间的调用关系更加灵活，可以灵活地指定请求接收者以及被请求的操作。命令模式为此类问题提供了一个较为完美的解决方案。命令模式可以将请求发送者和接收者完全解耦，发送者与接收者之间没有直接引用关系，发送请求的对象只需要知道如何发送请求，而不必知道如何完成请求。命令模式定义如下:
命令模式(Command Pattern):将一个请求封装为一个对象，从而让我们可用不同的请求对客户进行参数化;对请求排队或者记录请求日志，以及支持可撤销的操作。命令模式是一种对象行为型模式，其别名为动作(Action)模式或事务(Transaction)模式。
命令模式的定义比较复杂，提到了很多术语，例如“用不同的请求对客户进行参数化”、“对请求排队”、“记录请求日志”、“支持可撤销操作”等，在后面我们将对这些术语进行一一讲解。
命令模式的核心在于引入了命令类，通过命令类来降低发送者和接收者的耦合度，请求发送者只需指定一个命令对象，再通过命令对象来调用请求接收者的处理方法，其结构如图所示:
Command(抽象命令类):抽象命令类一般是一个抽象类或接口，在其中声明了用于执行请求的 execut e() 等方法，通过这些方法可以调用请求接收者的相关操作。
ConcreteCommand(具体命令类):具体命令类是抽象命令类的子类，实现了在抽象命令类中声明的方 法，它对应具体的接收者对象，将接收者对象的动作绑定其中。在实现 execute() 方法时，将调用接收者对 象的相关操作(Action)。
Invoker(调用者):调用者即请求发送者，它通过命令对象来执行请求。一个调用者并不需要在设计时确定 其接收者，因此它只与抽象命令类之间存在关联关系。在程序运行时可以将一个具体命令对象注入其中，再 调用具体命令对象的 execute() 方法，从而实现间接调用请求接收者的相关操作。
Receiver(接收者):接收者执行与请求相关的操作，它具体实现对请求的业务处理。
命令模式的本质是对请求进行封装，一个请求对应于一个命令，将发出命令的责任和执行命令的责任分割开。每 一个命令都是一个操作:请求的一方发出请求要求执行一个操作;接收的一方收到请求，并执行相应的操作。命令模式允许请求的一方和接收的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求如何被接收、操作是否被执行、何时被执行，以及是怎么被执行的。
命令模式的关键在于引入了抽象命令类，请求发送者针对抽象命令类编程，只有实现了抽象命令类的具体命令才 与请求接收者相关联。在最简单的抽象命令类中只包含了一个抽象的execute() 方法，每个具体命令类将一个Receiver 类型的对象作为一个实例变量进行存储，从而具体指定一个请求的接收者，不同的具体命令类提供了 execute() 方法的不同实现，并调用不同接收者的请求处理方法。
public class A {
//功能键设置窗口类
class FBSettingWindow {
private String title; //窗口标题
//定义一个ArrayList来存储所有功能键
private ArrayList<FunctionButton> functionButtons = new ArrayList<FunctionButton>();
public void addFunctionButton(FunctionButton fb) {
functionButtons.add(fb);
}
public void removeFunctionButton(FunctionButton fb) {
functionButtons.remove(fb);
}
//显示窗口及功能键
public void display() {
System.out.println("显示窗口:" + this.title);
System.out.println("显示功能键:");
for (Object obj : functionButtons) {
System.out.println(((FunctionButton) obj).getName());
}
System.out.println("------------------------------");
}
}
//功能键类:请求发送者
class FunctionButton {
private String name; //功能键名称
private Command command; //维持一个抽象命令对象的引用
public FunctionButton(String name) {
this.name = name;
}
public String getName() {
return this.name;
}
//为功能键注入命令
public void setCommand(Command command) {
this.command = command;
}
//发送请求的方法
public void onClick() {
System.out.print("点击功能键:");
command.execute();
}
}
//抽象命令类
abstract class Command {
public abstract void execute();
}
//帮助命令类:具体命令类
class HelpCommand extends Command {
private HelpHandler hhObj; //维持对请求接收者的引用
public HelpCommand() {
hhObj = new HelpHandler();
}
//命令执行方法，将调用请求接收者的业务方法
public void execute() {
hhObj.display();
}
}
//最小化命令类:具体命令类
class MinimizeCommand extends Command {
private WindowHanlder whObj; //维持对请求接收者的引用
public MinimizeCommand() {
whObj = new WindowHanlder();
}
//命令执行方法，将调用请求接收者的业务方法
public void execute() {
whObj.minimize();
}
}
//窗口处理类:请求接收者
class WindowHanlder {
public void minimize() {
System.out.println("将窗口最小化至托盘!");
}
}
//帮助文档处理类:请求接收者
class HelpHandler {
public void display() {
System.out.println("显示帮助文档!");
}
}
}
// 客户端调用
class Client {
public static void main(String args[]) {
FBSettingWindow fbsw = new FBSettingWindow("功能键设置");
FunctionButton fb1, fb2;
fb1 = new FunctionButton("功能键1");
fb2 = new FunctionButton("功能键1");
Command command1, command2; //通过读取配置文件和反射生成具体命令对象
command1 = (Command) XMLUtil.getBean(0);
command2 = (Command) XMLUtil.getBean(1);
//将命令对象注入功能键
fb1.setCommand(command1);
fb2.setCommand(command2);
fbsw.addFunctionButton(fb1);
fbsw.addFunctionButton(fb2);
fbsw.display();
//调用功能键的业务方法
fb1.onClick();
fb2.onClick();
}
}
如果需要修改功能键的功能，例如某个功能键可以实现“自动截屏”，只需要对应增加一个新的具体命令类，在该命令类与屏幕处理者(ScreenHandler)之间创建一个关联关系，然后将该具体命令类的对象通过配置文件注 入到某个功能键即可，原有代码无须修改，符合“开闭原则”。在此过程中，每一个具体命令类对应一个请求的 处理者(接收者)，通过向请求发送者注入不同的具体命令对象可以使得相同的发送者对应不同的接收者，从而 实现“将一个请求封装为一个对象，用不同的请求对客户进行参数化”，客户端只需要将具体命令对象作为参数 注入请求发送者，无须直接操作请求的接收者。
优点（我觉得我们肯定用不上）
(1) 降低系统的耦合度。由于请求者与接收者之间不存在直接引用，因此请求者与接收者之间实现完全解耦，相同 的请求者可以对应不同的接收者，同样，相同的接收者也可以供不同的请求者使用，两者之间具有良好的独立 性。
(2) 新的命令可以很容易地加入到系统中。由于增加新的具体命令类不会影响到其他类，因此增加新的具体命令类 很容易，无须修改原有系统源代码，甚至客户类代码，满足“开闭原则”的要求。
(3) 可以比较容易地设计一个命令队列或宏命令(组合命令)。
(4) 为请求的撤销(Undo)和恢复(Redo)操作提供了一种设计和实现方案。
缺点
使用命令模式可能会导致某些系统有过多的具体命令类。因为针对每一个对请求接收者的调用操作都需要设计一 个具体命令类，因此在某些系统中可能需要提供大量的具体命令类，这将影响命令模式的使用。
适用场景
(1) 系统需要将请求调用者和请求接收者解耦，使得调用者和接收者不直接交互。请求调用者无须知道接收者的存在，也无须知道接收者是谁，接收者也无须关心何时被调用。
(2) 系统需要在不同的时间指定请求、将请求排队和执行请求。一个命令对象和请求的初始调用者可以有不同的生 命期，换言之，最初的请求发出者可能已经不在了，而命令对象本身仍然是活动的，可以通过该命令对象去调用 请求接收者，而无须关心请求调用者的存在性，可以通过请求日志文件等机制来具体实现。
(3) 系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作。
(4) 系统需要将一组操作组合在一起形成宏命令。
三、迭代器模式
迭代器模式(Iterator Pattern):提供一种方法来访问聚合对象，而不用暴露这个对象的内部表示，其别名为游标(Cursor)。迭代器模式是一种对象行为型模式。
public class A {
interface Iterator {
void first(); //将游标指向第一个元素
void next(); //将游标指向下一个元素
boolean hasNext(); //判断是否存在下一个元素
Object currentItem(); //获取游标指向的当前元素
}
class ConcreteIterator implements Iterator {
private ConcreteAggregate objects; //维持一个对具体聚合对象的引用，以便于访问存储在聚合对象中的数据
private int cursor; //定义一个游标，用于记录当前访问位置
public ConcreteIterator(ConcreteAggregate objects) {
this.objects = objects;
}
public void first() { ......}
public void next() { ......}
public boolean hasNext() { ......}
public Object currentItem() { ......}
}
// 聚合类
interface Aggregate {
Iterator createIterator();
}
// 具体聚合类是抽象聚合类的子类，一方面负责存储数据，
// 另一方面实现了在抽象聚合类中声明的工厂方法 createIterator()，用于返回一个与该具体聚合类对应的具体迭代器对象
class ConcreteAggregate implements Aggregate {
......
public Iterator createIterator() {
return new ConcreteIterator(this);
}
......
}
}
优点
(1) 它支持以不同的方式遍历一个聚合对象，在同一个聚合对象上可以定义多种遍历方式。在迭代器模式中只需要用一个不同的迭代器来替换原有迭代器即可改变遍历算法，我们也可以自己定义迭代器的子类以支持新的遍历方式。
(2) 迭代器简化了聚合类。由于引入了迭代器，在原有的聚合对象中不需要再自行提供数据遍历等方法，这样可以简化聚合类的设计。
(3) 在迭代器模式中，由于引入了抽象层，增加新的聚合类和迭代器类都很方便，无须修改原有代码，满足“开闭原则”的要求。
缺点
(1) 由于迭代器模式将存储数据和遍历数据的职责分离，增加新的聚合类需要对应增加新的迭代器类，类的个数成 对增加，这在一定程度上增加了系统的复杂性。
(2) 抽象迭代器的设计难度较大，需要充分考虑到系统将来的扩展，例如 JDK 内置迭代器 Iterator 就无法实现逆向遍历，如果需要实现逆向遍历，只能通过其子类 ListIterator 等来实现，而 ListIterator 迭代器无法用于操作 Set 类型的聚合对象。在自定义迭代器时，创建一个考虑全面的抽象迭代器并不是件很容易的事情。
适用场景
(1) 访问一个聚合对象的内容而无须暴露它的内部表示。将聚合对象的访问与内部数据的存储分离，使得访问聚合 对象时无须了解其内部实现细节。
(2) 需要为一个聚合对象提供多种遍历方式。
(3) 为遍历不同的聚合结构提供一个统一的接口，在该接口的实现类中为不同的聚合结构提供不同的遍历方式，而客户端可以一致性地操作该接口。
四、观察者模式（对象间的联动）
观察者模式是使用频率最高的设计模式之一，它用于建立一种对象与对象之间的依赖关系，一个对象发生改变时将自动通知其他对象，其他对象将相应作出反应。在观察者模式中，发生改变的对象称为观察目标，而被通知的对象称为观察者，一个观察目标可以对应多个观察者，而且这些观察者之间可以没有任何相互联系，可以根据需要增加和删除观察者，使得系统更易于扩展。
观察者模式定义如下:
观察者模式(Observer Pattern):定义对象之间的一种一对多依赖关系，使得每当一个对象状态发生改变时，其相关依赖对象皆得到通知并被自动更新。观察者模式的别名包括发布-订阅(Publish/Subscribe)模式、模型-视图(Model/View)模式、源-监听器(Source/Listener)模式或从属者(Dependents)模 式。观察者模式是一种对象行为型模式。
观察者模式结构中通常包括观察目标和观察者两个继承层次结构，其结构如图所示:
- Subject(目标):目标又称为主题，它是指被观察的对象。在目标中定义了一个观察者集合，一个观察目标可以接受任意数量的观察者来观察，它提供一系列方法来增加和删除观察者对象，同时它定义了通知方法 notify()。目标类可以是接口，也可以是抽象类或具体类。
- ConcreteSubject(具体目标):具体目标是目标类的子类，通常它包含有经常发生改变的数据，当它的状态发生改变时，向它的各个观察者发出通知;同时它还实现了在目标类中定义的抽象业务逻辑方法(如果有的话)。如果无须扩展目标类，则具体目标类可以省略。
- Observer(观察者):观察者将对观察目标的改变做出反应，观察者一般定义为接口，该接口声明了更新数据的方法update()，因此又称为抽象观察者。
- ConcreteObserver(具体观察者):在具体观察者中维护一个指向具体目标对象的引用，它存储具体观察 者的有关状态，这些状态需要和具体目标的状态保持一致;它实现了在抽象观察者 Observer 中定义的 update() 方法。通常在实现时，可以调用具体目标类的 attach() 方法将自己添加到目标类的集合中或通过 detach() 方法将自己从目标类的集合中删除。
观察者模式描述了如何建立对象与对象之间的依赖关系，以及如何构造满足这种需求的系统。
观察者模式与责任链模式都是在内部存的对象的引用，通过调用方法的方式达到通知的目的，但是责任链是链式调用，一次只能通知一个观察者。
public class A {
//抽象观察类
interface Observer {
public String getName();
public void setName(String name);
public void help(); //声明支援盟友方法
public void beAttacked(AllyControlCenter acc); //声明遭受攻击方法
}
//战队成员类:具体观察者类
class Player implements Observer {
private String name;
public Player(String name) {
this.name = name;
}
public void setName(String name) {
this.name = name;
}
public String getName() {
return this.name;
}
//支援盟友方法的实现
public void help() {
System.out.println("坚持住，" + this.name + "来救你!");
}
//遭受攻击方法的实现，当遭受攻击时将调用战队控制中心类的通知方法notifyObserver()来通知盟友
public void beAttacked(AllyControlCenter acc) {
System.out.println(this.name + "被攻击!");
acc.notifyObserver(name);
}
}
//战队控制中心类:目标类
abstract class AllyControlCenter {
protected String allyName; //战队名称
protected ArrayList<Observer> players = new ArrayList<Observer>(); //定义一个集合用于存储战队成员
public void setAllyName(String allyName) {
this.allyName = allyName;
}
public String getAllyName() {
return this.allyName;
}
//注册方法
public void join(Observer obs) {
System.out.println(obs.getName() + "加入" + this.allyName + "战队!");
players.add(obs);
}
//注销方法
public void quit(Observer obs) {
System.out.println(obs.getName() + "退出" + this.allyName + "战队!");
players.remove(obs);
}
//声明抽象通知方法
public abstract void notifyObserver(String name);
}
//具体战队控制中心类:具体目标类
class ConcreteAllyControlCenter extends AllyControlCenter {
public ConcreteAllyControlCenter(String allyName) {
System.out.println(allyName + "战队组建成功!");
System.out.println("----------------------------");
this.allyName = allyName;
}
//实现通知方法
public void notifyObserver(String name) {
System.out.println(this.allyName + "战队紧急通知，盟友" + name + "遭受敌人攻击!"); //遍历观察者集合，调用每一个盟友(自己除外)的支援方法
for (Observer obs : players) {
if (!obs.getName().equalsIgnoreCase(name)) {
obs.help();
}
}
}
}
}
客户端类
class Client {
public static void main(String args[]) {
//定义观察目标对象
AllyControlCenter acc = new ConcreteAllyControlCenter("金庸群侠");
//定义四个观察者对象
Observer player1, player2, player3, player4;
player1 = new Player("杨过");
acc.join(player1);
player2 = new Player("令狐冲");
acc.join(player2);
player3 = new Player("张无忌");
acc.join(player3);
player4 = new Player("段誉");
acc.join(player4);
//某成员遭受攻击（通知其它成员）
player1.beAttacked(acc);
}
}
JDK 对观察者模式的支持
观察者模式在 Java 语言中的地位非常重要。在 JDK 的 java.util 包中，提供了 Observable 类以及 Observer 接口，它们构成了 JDK 对观察者模式的支持。
优点
(1) 观察者模式可以实现表示层和数据逻辑层的分离，定义了稳定的消息更新传递机制，并抽象了更新接口，使得可以有各种各样不同的表示层充当具体观察者角色。
(2) 观察者模式在观察目标和观察者之间建立一个抽象的耦合。观察目标只需要维持一个抽象观察者的集合，无须 了解其具体观察者。由于观察目标和观察者没有紧密地耦合在一起，因此它们可以属于不同的抽象化层次。
(3) 观察者模式支持广播通信，观察目标会向所有已注册的观察者对象发送通知，简化了一对多系统设计的难度。
(4) 观察者模式满足“开闭原则”的要求，增加新的具体观察者无须修改原有系统代码，在具体观察者与观察目标 之间不存在关联关系的情况下，增加新的观察目标也很方便。
缺点
(1) 如果一个观察目标对象有很多直接和间接观察者，将所有的观察者都通知到会花费很多时间。
(2) 如果在观察者和观察目标之间存在循环依赖，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。
(3) 观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生 了变化。
适用场景
(1) 一个抽象模型有两个方面，其中一个方面依赖于另一个方面，将这两个方面封装在独立的对象中使它们可以各 自独立地改变和复用。
(2) 一个对象的改变将导致一个或多个其他对象也发生改变，而并不知道具体有多少对象将发生改变，也不知道这 些对象是谁。
(3) 需要在系统中创建一个触发链，A 对象的行为将影响B对象，B 对象的行为将影响 C 对象......，可以使用观察者模式创建一种链式触发机制。
观察者模式与责任链模式区别
在底层的实现上差不多，观察者模式内部存的是一个List<Observer>，责任链模式内部存的是this对象的引用
观察者模式是为了解决对象间的一种一对多依赖关系，使得每当一个对象改变状态，则其相关依赖对象皆得到通知并被自动更新。（不一定是同一个东西，只是一个触发器）
责任链模式是为了解决多个处理耦合在一起（为了单一原则），从而拆分成多个类进行处理（处理同一个东西）
学习设计模式有什么用
设计模式是围绕着那6大原则设计的，最主要的是“开闭原则”，为了方便大型系统的扩展，学习设计模式的时候一定要了解这些设计模式的存在是为了解决什么问题的。