工具篇-Java中的设计模式积累（二）

目录

行为型设计模式

1. 模版模式
2. 策略模式
3. 命令模式
4. 责任链模式
5. 状态模式
6. 观察者模式
7. 中介者模式 
8. 迭代者模式
9. 访问者模式
10. 备忘录模式
11. 解释器模式

 ------------------------------------------行为型设计模式

1. 模版模式

为什么有模版模式：

定义一个算法的骨架，而将一些步骤的实现延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中某些步骤的具体实现；

优点： 

• 模板方法模式通过把不变的行为搬到父类，去除了子类中的重复代码；
• 子类实现算法的某些细节，有助于算法的扩展；
• 父类调用子类实现的操作，通过子类扩展增加新的行为，符合“开放-封闭原则” 

缺点：

• 在模版模式中，子类执行的结果影响了父类的结果，会增加代码阅读的难度；

应用场景：

• 多个子类存在共有方法，且逻辑相同；　　　　
• 重要、复杂的算法，可以把核心算法设计为模板方法

实现：

模版模式中，基类方法的默认实现被退化为钩子Hooks的概念，他们被设计在子类中被重写，如果你期望一些方法在子类中不被重写，可以让他们为final。例如，

模版抽象类

public abstract class HouseTemplate {

    protected HouseTemplate(String name){
        this.name = name;
    }

    protected String name;

    protected abstract void buildDoor();

    protected abstract void buildWindow();

    protected abstract void buildWall();

    protected abstract void buildBase();

    protected abstract void buildToilet();

    //钩子方法
    protected boolean isBuildToilet(){
        return true;
    }

    //公共逻辑
    public final void buildHouse(){

        buildBase();
        buildWall();
        buildDoor();
        buildWindow();
        if(isBuildToilet()){ 
            buildToilet();
        }
    }

}

子类1

public class HouseOne extends HouseTemplate {

    HouseOne(String name){
        super(name);
    }

    HouseOne(String name, boolean isBuildToilet){
        this(name);
        this.isBuildToilet = isBuildToilet;
    }

    public boolean isBuildToilet;

    @Override
    protected void buildDoor() {
        System.out.println(name +"的门要采用防盗门");
    }

    @Override
    protected void buildWindow() {
        System.out.println(name + "的窗户要面向北方");
    }

    @Override
    protected void buildWall() {
        System.out.println(name + "的墙使用大理石建造");
    }

    @Override
    protected void buildBase() {
        System.out.println(name + "的地基使用钢铁地基");
    }

    @Override
    protected void buildToilet() {
        System.out.println(name + "的厕所建在东南角");
    }

    @Override
    protected boolean isBuildToilet(){
        return isBuildToilet;
    }

}

子类2

public class HouseTwo extends HouseTemplate {

    HouseTwo(String name){
        super(name);
    }

    @Override
    protected void buildDoor() {
        System.out.println(name + "的门采用木门");
    }

    @Override
    protected void buildWindow() {
        System.out.println(name + "的窗户要向南");
    }

    @Override
    protected void buildWall() {
        System.out.println(name + "的墙使用玻璃制造");
    }

    @Override
    protected void buildBase() {
        System.out.println(name + "的地基使用花岗岩");
    }

    @Override
    protected void buildToilet() {
        System.out.println(name + "的厕所建在西北角");
    }

}

客户端

public class Clienter {

    public static void main(String[] args){
        HouseTemplate houseOne = new HouseOne("房子1", false);
        HouseTemplate houseTwo = new HouseTwo("房子2");
        houseOne.buildHouse();
        houseTwo.buildHouse();
    }

}

可以看到，通过重写钩子方法自定义了房子1不需要建造厕所（fasle），另外可以参考这篇文章：设计模式学习笔记之九：模板方法模式。

2. 策略模式

为什么有策略模式：

Define a family of algorithms,encapsulate each one,and make them interchangeable.
定义一组算法（我觉得应该是一个行为的不同实现吧），将每个算法都封装起来，并且使它们之间可以互换。

通俗点讲是利用继承和多态机制，从而实现同一行为在不同场景下的不同实现吧。

优点： 

• 算法可以自由切换；
• 避免使用多重条件判断；
• 扩展性良好，策略类遵顼里氏替换原则，增加一个策略只需要实现一个接口就可以了。

缺点：

• 策略模式造成很多的策略类，每个具体策略类都会产生一个新类；
• 所有的策略类都需要对外暴露，客户端必须知道所有的策略类，并自行决定使用哪一个策略类，违反了迪米特法，可使用工厂方法模式、代理模式修整这个缺陷。

应用场景：

• 如果在一个系统里面有许多类，它们之间的区别仅在于它们的行为，在运行时动态选择具体要执行的行为；
• 在不同情况下使用不同的策略(算法)，或者策略还可能在未来用其它方式来实现；
• 对客户隐藏具体策略(算法)的实现细节，彼此完全独立。

实现：

策略模式有三种角色：

抽象策略角色这个是一个抽象的角色，通常使用接口或者抽象类去实现。比如Comparator接口；
具体策略角色包装了具体的算法和行为。就是实现了Comparator接口的实现一组实现类；
环境角色内部会持有一个抽象角色的引用，比如内部一定会有一个策略类的一个成员变量，这样在构建函数中就可以接收外部传递的具体的策略类。

例如，

    //抽象策略类 Strategy
    interface IStrategy {
        void algorithm();
    }

    //具体策略类 ConcreteStrategyA
    static class ConcreteStrategyA implements IStrategy {
        @Override
        public void algorithm() {
            System.out.println("Strategy A");
        }
    }

    //具体策略类 ConcreteStrategyB
    static class ConcreteStrategyB implements IStrategy {
        @Override
        public void algorithm() {
            System.out.println("Strategy B");
        }
    }

客户端，

    //上下文环境角色
    static class Context {
        private IStrategy mStrategy; // 引用

        public Context(IStrategy strategy) {
            this.mStrategy = strategy;
        }

        public void algorithm() {
            this.mStrategy.algorithm();
        }
    }

3. 命令模式

为什么有命令模式：

将一个请求封装成一个对象，从而使请求参数化。

优点： 

• 降低"行为请求者"与"行为实现者"的耦合；
• 新的命令可以很容易添加到系统中。

缺点：

• 可能会导致某些系统有过多的具体命令类。

应用场景：

在一些对行为进行"记录、撤销/重做、事务"等处理的场合，比如：线程池、工作队列、日志请求等

• 工作队列：

在某一端添加命令，另一端则是线程进行下面的动作：从队列中取出一个命令，调用它的execute()方法，等待这个调用完成，然后将此命令对象丢弃，再取出下一个命令......这里工作队列和命令对象之间是完全解耦的，线程可能此刻在进行财务运算，下一刻却在读取网络数据。工作队列对象不在乎到底做些什么，它们只知道取出命令对象，然后调用其execute()方法。类似地，它们只要实现命令模式的对象，就可以放入队列里，当线程可用时，就调用此对象的execute()方法。

• 日志请求

多用于数据库管理系统的实现，我们需要把一系列的操作记录下来（如写在硬盘上），在遇到系统故障时读出来以恢复数据，如何实现？利用对象的序列化把对象保存起来（记录日志），在需要的时候反序列化（恢复事务）。

注：这里的可撤销的操作就是：放弃该操作，回到未执行该操作前的状态。

有两种基本的思路来实现可撤销的操作：
① 一种是补偿式，又称反操作式
比如被撤销的操作是加的功能， 那撤消的实现就变成减的功能;比如被撤销的操作是打开的功能，那么撤销的实现就变成关闭的功能。
② 另外一种方式是存储恢复式
意思就是把操作前的状态记录下来，然后要撤销操作的时候就直接恢复回去就可以了。

实现：

该模式具有以下角色：

抽象命令接口Command：定义接口，声明执行的方法。
具体的命令对象ConcreteCommand：持有接受者对象，完成具体的命令。
接受者对象Receiver：接受者对象，真正执行命令的对象。
传递命令对象Invoker：调用者，要求命令对象执行请求。
客户端对象Client：创建具体命令对象并且设置接受者。

比如：顾客来到餐馆点一碗面（发出请求） -> 柜台服务员记录下来（创建命令） -> 服务员把订单扔给厨房 -> 厨师很快做好了一碗面（请求被执行）。顾客不知道将由谁来做这碗面，柜台服务员也不知道，厨师不知道是谁点了这碗面，其中，订单就起解耦的作用。

首先，写命令接口

public interface Command {
    public abstract void execute();//只需要定义一个统一的执行方法
}

然后是执行者

public abstract class Chef {
    //在此定义厨师的公共属性
    
    //定义烹饪方法
    public abstract void cook();
}

具体执行者，做面的厨师和做饼的厨师

public class NoodlesChef extends Chef{

    @Override
    public void cook() {
        System.out.println("做好了一碗美味的拉面");
    }
}

public class PieChef extends Chef{

    @Override
    public void cook() {
        System.out.println("做好了一块香喷喷的大饼");
    }
}

各种具体命令

public class NoodlesCommand implements Command{
    private NoodlesChef chef;//专业做面的厨师
    
    public NoodlesCommand(){
        chef = new NoodlesChef();
    }

    @Override
    public void execute() {
        chef.cook();
        //调用其它需要的方法
    }
}

public class PieCommand implements Command{
    private PieChef chef;//专业做饼的厨师
    
    public PieCommand(){
        chef = new PieChef();
    }

    @Override
    public void execute() {
        chef.cook();
        //调用其它需要的方法
    }
}

调用者invoker

public class Waiter {

    private Command command;

    // 设置具体的命令
    public void setCommand(Command command) {
        this.command = command;
    }

    // 执行命令
    public void doCommand() {
        command.execute();
    }
}

客户端，店馆开张了

public class Test {    
    public static void main(String[] args) {
        System.out.println("第一位客户X先生");
        System.out.println("X先生：你好，我需要一碗面，我饿极了");
        NoodlesCommand nCmd = new NoodlesCommand();
        System.out.println("柜台服务员：好的厨房~~,接单");
        Waiter.doCommand(); //安排厨师做
                
        System.out.println("第二位客户XX先生");
        System.out.println("XX先生：你好，我需要一块饼，20分钟后来取");
        PieCommand pCmd = new PieCommand();
        System.out.println("柜台服务员：好的厨房~~,接单");
        Waiter.doCommand(); // 安排厨师做
    }
}

4. 责任链模式

为什么有责任链模式：

搞一条对象链，这样请求不用知道具体执行的是哪一个对象，就实现了请求与对象之间的解耦。

优点： 

• 降低了对象之间的耦合度，上边已经说了；
• 增强了系统的可扩展性。可以根据需要增加删除请求处理类，满足开闭原则；
• 增强了给对象指派职责的灵活性。可以动态地改变链内的成员的次序；
• 责任分担。每个类只需要处理自己该处理的工作，符合类的单一职责原则。

缺点（针对不纯责任链模式）：

• 不能保证每个请求一定被处理。，请求可能一直传到链的末端都得不到处理；
• 对比较长的职责链，系统性能将受到一定影响；
• 职责链建立的合理性要靠客户端来保证，可能会造成循环调用。

应用场景：

我觉得好多if/else，switch/case操作可以考虑这个吧，还是能充分利用这种模式的优点呗，比如：

Netty 中的 Pipeline 和 ChannelHandler 通过责任链设计模式来组织代码逻辑
Spring Security 使用责任链模式，可以动态地添加或删除责任（处理 request 请求）
Spring AOP 通过责任链模式来管理 Advisor

实现（具体参考：责任链模式妙用）：

该模式具有以下角色：

抽象处理者（Handler）：定义一个处理请求的接口（或抽象类），包含抽象处理方法和一个后继连接。

具体处理者（Concrete Handler）：实现抽象处理者的处理方法，判断能否处理本次请求，如果可以则处理，否则将该请求转给它的后继者。

客户类（Client）：创建处理链，并向链头的具体处理者对象提交请求，它不关心处理细节和请求的传递过程。

抽象接口

public abstract class BaseCase { 
    // 为 true 表明自己可以处理该 case 
    private boolean isConsume; 
    public BaseCase(boolean isConsume) {   
        this.isConsume = isConsume; 
    }
     // 下一个责任节点
     private BaseCase nextCase; 
    public void setNextCase(BaseCase nextCase) {  
        this.nextCase = nextCase; 
    }     
    public void handleRequest() {  
        if (isConsume) {    
            // 如果当前节点可以处理，直接处理     
            doSomething();  
        } else {     
            // 如果当前节点不能处理，并且有下个节点，交由下个节点处理     
            if (null != nextCase) {     
                nextCase.handleRequest();    
            } 
        } 
    } 
    abstract protected void doSomething();
}

具体处理者，其中一个为例

public class OneCase extends BaseCase { 
    public OneCase(boolean isConsume) {   
        super(isConsume); 
    }
 
    @Override protected void doSomething() {   
    // TODO do something   
        System.out.println(getClass().getName()); 
    }
}

客户端

String input = "1";      
OneCase oneCase = new OneCase("1".equals(input));   
TwoCase twoCase = new TwoCase("2".equals(input)); 
DefaultCase defaultCase = new DefaultCase(true); 
oneCase.setNextCase(twoCase); 
twoCase.setNextCase(defaultCase);      
oneCase.handleRequest();

5. 状态模式

为什么有状态模式：

让一个对象在其内部状态改变的时候改变其行为

优点： 

• 将不同状态的行为分割开来，满足“单一职责原则”；
• 将不同的状态引入独立的对象中会使状态转换更加明确，减少对象间的相互依赖；
• 有利于扩展，通过定义新的子类很容易地增加新的状态和转换

缺点：

• 每一个状态都对应一个子类，当你的状态非常多的时候就会发生类膨胀。

应用场景：

行为随着状态的改变而改变的时候，例如权限设计，人员的状态不同即使执行相同的行为结果也会不同，在这种情况下需要考虑使用状态模式。

实现：

该模式具有以下角色

环境（Context）角色：也称为上下文，它将与状态相关的操作委托给当前状态对象来处理；
抽象状态（State）角色：接口，用来封装对象中的特定状态所对应的行为；
具体状态（Concrete State）角色：实现抽象状态所对应的行为。

比如：用户登录系统，同一个操作在不同状态下会有不同的操作，先定义一个用户状态的接口

public interface LoginState {  
    public void loadUser();
    public void loginIn();
    public void loginOut();
}

登录成功状态

public class LoginInState implements LoginState{

    @Override
    public void loadUser() {
        // TODO Auto-generated method stub
        System.out.println("用户数据载入成功");

    }

    @Override
    public void loginIn() {
        // TODO Auto-generated method stub
        System.out.println("已经登录成功了");
    }

    @Override
    public void loginOut() {
        // TODO Auto-generated method stub
        System.out.println("已经登录成功了,请按退出登录按钮");
    }

}

退出登录状态

public class LoginErrorState implements LoginState{
    @Override
    public void loadUser() {
        // TODO Auto-generated method stub
        System.out.println("已经退出,请按登录按钮");
    }

    @Override
    public void loginIn() {
        // TODO Auto-generated method stub
        System.out.println("已经退出,请先登录");
    }

    @Override
    public void loginOut() {
        // TODO Auto-generated method stub
        System.out.println("退出登录成功");
    }
}

用LoginContext管理这两个状态

/**
 * 登录环境上下文
 * @author ccj
 *
 */
public class LoginContext {
    private LoginState loginState=new LoginErrorState();

    /**
     * 可以根据需求,进行单例化,工厂化
     */
    public void loginIn(){
        loginState=new LoginInState();
        loginState.loginIn();
    }

    public void loginOut(){
        loginState=new LoginErrorState();
        loginState.loginOut();
    }
    
    public void loadUser(){
        loginState.loadUser();
    }
}

客户端按键

public class Test {
    /**
     * 将登录登出两个动作, 分别对应两个按钮
     * @param args
     */
    public static void main(String[] args) {
        LoginContext context =new LoginContext();
        System.out.println("=======点击登录按钮===>>=状态:登录=====>>选择加载用户数据===========");
        context.loginIn();
        context.loadUser();
    
        System.out.println("=====点击退出按钮>>======状态:退出=======>>选择加载用户数据=========");
        context.loginIn();
        context.loginOut();
        context.loadUser();
    }
}

测试结果

=======点击登录按钮===>>=状态:登录=====>>选择加载用户数据===========
已经登录成功了
用户数据载入成功
=====点击退出按钮>>======状态:退出=======>>选择加载用户数据=========
已经登录成功了
退出登录成功
已经退出,请按登录按钮

⚠️注意：在行为受状态约束的时候使用状态模式，而且状态不超过5个。

策略模式和状态模式对比：

策略模式需要客户端必须完全知晓所有的策略方法，才能够知道究竟哪一个策略是当前需要的。而状态模式客户端在使用的时候，可以不必关心有哪些状态，他只需要去调用环境的行为就可以了，在环境的内部维护了这些状态，就是策略模式服务的对象是不固定的，但是状态模式服务的对象是固定的，每次都是那一个。

6. 观察者模式

为什么有观察者模式：

主要是松解耦（对应Kafka依赖broker发布订阅的这种完全的解耦方式），对于对象间一对多的依赖关系，使得每当一个对象改变状态，则所有依赖它的对象都会得到通知并自动更新。 

优点： 

• 降低了目标与观察者之间的耦合关系；

• 目标与观察者之间建立了一套触发机制

缺点：

• 目标与观察者之间的依赖关系并没有完全解除，而且有可能出现循环引用。
• 当观察者对象很多时，通知的发布会花费很多时间。

应用场景：

• 对象间存在一对多关系，一个对象的状态改变会影响其他对象，而不知道具体有多少对象需要被改变；
• 当一个抽象模型有两个方面，其中一个方面依赖于另一方面时，可将这二者封装在独立的对象中以使它们可以各自独立地改变和复用

实现：

该模式具有以下角色

抽象主题（Subject）：提供一个用于保存观察者对象的聚集类和增加、删除观察者对象的方法，以及通知所有观察者的抽象方法；
具体主题（Concrete Subject）：在具体主题内部状态改变时，给所有登记过的观察者发出通知。
抽象观察者（Observer）：为所有的具体观察者定义一个接口，在得到主题更改通知时更新自己。
具体观察者（Concrete Observer）：实现抽象观察者中定义的抽象方法，以便在得到目标的更改通知时更新自身的状态。

让耦合的双方依赖于抽象，而不是依赖于具体，从而使各自的变化不会影响另一边的变化，这是依赖倒转原则的最佳体现。

首先是一个观察者接口

public interface Subscriber {
    int receive(String publisher, String articleName);
}

有一个具体的观察者（微信客户端），实现receive方法

public class WeChatClient implements Subscriber {
    private String username;

    public WeChatClient(String username) {
        this.username = username;
    }

    @Override
    public int receive(String publisher, String articleName) {
        // 接收到推送时的操作
        System.out.println(String.format("用户<%s> 接收到 <%s>微信公众号 的推送，文章标题为 <%s>", username, publisher, articleName));
        return 0;
    }
}

接着是一个抽象主题，该类维护了一个订阅者列表，实现了订阅、取消订阅、通知所有订阅者等功能

public class Publisher {
    private List<Subscriber> subscribers;
    private boolean pubStatus = false;

    public Publisher() {
        subscribers = new ArrayList<Subscriber>();
    }

    protected void subscribe(Subscriber subscriber) {
        this.subscribers.add(subscriber);
    }

    protected void unsubscribe(Subscriber subscriber) {
        if (this.subscribers.contains(subscriber)) {
            this.subscribers.remove(subscriber);
        }
    }

    protected void notifySubscribers(String publisher, String articleName) {
        if (this.pubStatus == false) {
            return;
        }
        for (Subscriber subscriber : this.subscribers) {
            subscriber.receive(publisher, articleName);
        }
        this.clearPubStatus();
    }

    protected void setPubStatus() {
        this.pubStatus = true;
    }

    protected void clearPubStatus() {
        this.pubStatus = false;
    }
}

最后是一个具体主题微信公众号类，该类提供了 publishArticles 方法，用于发布推送，当文章发布完毕时调用父类的通知所有订阅者方法

public class WeChatAccounts extends Publisher {
    private String name;

    public WeChatAccounts(String name) {
        this.name = name;
    }

    public void publishArticles(String articleName, String content) {
        System.out.println(String.format("\n<%s>微信公众号 发布了一篇推送，文章名称为 <%s>，内容为 <%s> ", this.name, articleName, content));
        setPubStatus();
        notifySubscribers(this.name, articleName);
    }
}

客户端使用

public class Test {
    public static void main(String[] args) {
        WeChatAccounts accounts = new WeChatAccounts("小旋锋");

        WeChatClient user1 = new WeChatClient("张三");
        WeChatClient user2 = new WeChatClient("李四");
        WeChatClient user3 = new WeChatClient("王五");

        accounts.subscribe(user1);
        accounts.subscribe(user2);
        accounts.subscribe(user3);

        accounts.publishArticles("设计模式 | 观察者模式及典型应用", "观察者模式的内容...");

        accounts.unsubscribe(user1);
        accounts.publishArticles("设计模式 | 单例模式及典型应用", "单例模式的内容....");
    }
}

输出，当公众号发布一篇推送时，订阅该公众号的用户可及时接收到推送的通知

<小旋锋>微信公众号 发布了一篇推送，文章名称为 <设计模式 | 观察者模式及典型应用>，内容为 <观察者模式的内容...> 
用户<张三> 接收到 <小旋锋>微信公众号 的推送，文章标题为 <设计模式 | 观察者模式及典型应用>
用户<李四> 接收到 <小旋锋>微信公众号 的推送，文章标题为 <设计模式 | 观察者模式及典型应用>
用户<王五> 接收到 <小旋锋>微信公众号 的推送，文章标题为 <设计模式 | 观察者模式及典型应用>

<小旋锋>微信公众号 发布了一篇推送，文章名称为 <设计模式 | 单例模式及典型应用>，内容为 <单例模式的内容....> 
用户<李四> 接收到 <小旋锋>微信公众号 的推送，文章标题为 <设计模式 | 单例模式及典型应用>
用户<王五> 接收到 <小旋锋>微信公众号 的推送，文章标题为 <设计模式 | 单例模式及典型应用>

7. 中介者模式

为什么有中介者模式：

把原来对象之间多对多的交互变成一对多的交互；减少各个对象之间的耦合，可以更方便的增加减少对象。 

优点： 

• 简化了对象之间的交互，将网状结构转换成相对简单的星型结构，一对多关系更容易理解、维护和扩展；

• 松耦合，可以独立的改变和复用每一个同事和中介者，增加新的中介者和新的同事类都比较方便，更好地符合 “开闭原则”

缺点：

• 具体中介者类中包含了大量同事之间的交互细节，会导致具体中介者类非常复杂，系统不好维护

应用场景：

• 一组定义良好的对象，现在要进行复杂的相互通信；
• 想通过一个中间类来封装多个类中的行为，而又不想生成太多的子类。
示例很多，比如

• MVC模式中，Controller 是中介者，根据View 层的请求来操作Model 层

• 比如组成原理中的主板，上边插了CPU、内存、网卡、声卡、硬盘各种东西

实现（参考https://blog.csdn.net/wwwdc1012/article/details/83389158）：

该模式具有以下角色

抽象中介者（Mediator）角色：它是中介者的接口，提供了同事对象注册与转发同事对象信息的抽象方法。

具体中介者（ConcreteMediator）角色：实现中介者接口，定义一个 List 来管理同事对象，协调各个同事角色之间的交互关系，因此它依赖于同事角色。

抽象同事类（Colleague）角色：定义同事类的接口，保存中介者对象，提供同事对象交互的抽象方法，实现所有相互影响的同事类的公共功能。

具体同事类（Concrete Colleague）角色：实现了在抽象同事类中声明的抽象方法，每个同事都知道中介者对象，要与同事通信则把通信告诉中介者。

比如，具体同事类，两个自己写的定时任务

public class MyOneTask extends TimerTask {
    private static int num = 0;
    @Override
    public void run() {
        System.out.println("I'm MyOneTask " + ++num);
    }
}

public class MyTwoTask extends TimerTask {
    private static int num = 1000;
    @Override
    public void run() {
        System.out.println("I'm MyTwoTask " + num--);
    }
}

客户端

public class TimerTest {
    public static void main(String[] args) {
        // 注意：多线程并行处理定时任务时，Timer运行多个TimeTask时，只要其中之一没有捕获抛出的异常，
        // 其它任务便会自动终止运行，使用ScheduledExecutorService则没有这个问题
        Timer timer = new Timer();
        timer.schedule(new MyOneTask(), 3000, 1000); // 3秒后开始运行，循环周期为 1秒
        timer.schedule(new MyTwoTask(), 3000, 1000);
    }
}

输出

I'm MyOneTask 1
I'm MyTwoTask 1000
I'm MyTwoTask 999
I'm MyOneTask 2
I'm MyOneTask 3
I'm MyTwoTask 998
I'm MyTwoTask 997
I'm MyOneTask 4
I'm MyOneTask 5
I'm MyTwoTask 996
I'm MyTwoTask 995
I'm MyOneTask 6
...

具体中介者Timer

public class Timer {
    private final TaskQueue queue = new TaskQueue();
    private final TimerThread thread = new TimerThread(queue);
    public void schedule(TimerTask task, long delay) {
        if (delay < 0)
            throw new IllegalArgumentException("Negative delay.");
        sched(task, System.currentTimeMillis()+delay, 0);
    }
    
    public void schedule(TimerTask task, Date time) {
        sched(task, time.getTime(), 0);
    }
    
    private void sched(TimerTask task, long time, long period) {
        if (time < 0)
            throw new IllegalArgumentException("Illegal execution time.");

        if (Math.abs(period) > (Long.MAX_VALUE >> 1))
            period >>= 1;

        // 获取任务队列的锁(同一个线程多次获取这个锁并不会被阻塞,不同线程获取时才可能被阻塞)
        synchronized(queue) {
            // 如果定时调度线程已经终止了,则抛出异常结束
            if (!thread.newTasksMayBeScheduled)
                throw new IllegalStateException("Timer already cancelled.");

            // 再获取定时任务对象的锁(为什么还要再加这个锁呢?想不清)
            synchronized(task.lock) {
                // 判断线程的状态,防止多线程同时调度到一个任务时多次被加入任务队列
                if (task.state != TimerTask.VIRGIN)
                    throw new IllegalStateException(
                        "Task already scheduled or cancelled");
                // 初始化定时任务的下次执行时间
                task.nextExecutionTime = time;
                // 重复执行的间隔时间
                task.period = period;
                // 将定时任务的状态由TimerTask.VIRGIN(一个定时任务的初始化状态)设置为TimerTask.SCHEDULED
                task.state = TimerTask.SCHEDULED;
            }
            
            // 将任务加入任务队列
            queue.add(task);
            // 如果当前加入的任务是需要第一个被执行的(也就是他的下一次执行时间离现在最近)
            // 则唤醒等待queue的线程(对应到上面提到的queue.wait())
            if (queue.getMin() == task)
                queue.notify();
        }
    }
    
    // cancel会等到所有定时任务执行完后立刻终止定时线程
    public void cancel() {
        synchronized(queue) {
            thread.newTasksMayBeScheduled = false;
            queue.clear();
            queue.notify();  // In case queue was already empty.
        }
    }
    // ...
}

Timer 中在 schedulexxx 方法中通过 TaskQueue 协调各种 TimerTask 定时任务，Timer 是中介者，TimerTask 是抽象同事类，而我们自己写的任务则是具体同事类

TimerThread 是 Timer 中定时调度线程类的定义，这个类会做为一个线程一直运行来执行 Timer 中任务队列中的任务。

Timer 这个中介者的功能就是定时调度我们写的各种任务，将任务添加到 TaskQueue 任务队列中，给 TimerThread 执行，让任务与执行线程解耦
注：

1. 实现过程中可能存在一些问题，比如如果中介者只有一个的话，而且预计中也没有扩展的要求，那么就可以不定义Mediator接口，把中介者对象设为单例；
2. 实现同事和中介者的通信：一种实现方式是在Mediator接口中定义一个通用的方法，让各个同事类来调用这个方法 ；另外一种实现方式是可以采用观察者模式，把Mediator实现成为观察者，而各个同事类实现成为Subject，这样同事类发生了改变，会通知Mediator。
3. 通常会去掉同事对象的父类，这样可以让任意的对象，只要需要相互交互就可以成为同事；
4. 中介者对象可以不把同事作为自己的属性，可以在处理方法中创建或者获取需要的同事对象；
5. 同事类需要知道中介者对象，在改变时通知它，但没必要作为属性这么强依赖，可以把中介对象做成单例，直接在同事类的方法里面去调用中介者对象。

8. 迭代器模式

为什么有迭代器模式：

将遍历和实现分开，顺序的访问集合内部的对象，而又不暴露集合内部的表示。 

优点： 

• 遍历由迭代器完成，简化了集合类；
• 支持以不同方式遍历一个集合，可以自定义迭代器的子类以支持新的遍历；
• 增加新的集合类和迭代器类都很方便，无须修改原有代码；
• 封装性良好，为遍历不同的集合结构提供一个统一的接口。

缺点：

• 增加类的个数，比如增加新的集合类需要增加新的具体迭代器

应用场景：

这个JDK已经提供了Iterator接口，我们直接使用就行，现在很少自己写迭代器了吧

实现

 该模式具有以下角色：

抽象迭代器（Iterator）：抽象迭代器负责定义访问和遍历元素的接口，而且基本上是有一些固定的方法：

• first()获得第一个元素
• next()访问下一个元素
• hasNext()是否已经访问到底部

具体迭代器（ConcreteIterator）：具体迭代器角色要实现迭代器接口，完成容器元素的遍历

抽象容器（Aggregate）：容器角色负责提供创建具体迭代器角色的接口，必然提供一个类似createIterator()这样的方法，在Java中一般是iterator()方法

具体容器（Concrete Aggregate）：具体容器实现容器接口定义的方法，创建出容纳迭代器的对象

比如，首先iterator，Iterator中最重要的两个方法就是next方法和hasNext方法，构成了遍历整个容器数据的两个方法。remove方法如果没有实现的话默认是会抛出一个不支持该操作的异常。

public interface Iterator<E> {
    boolean hasNext();
    E next();
    default void remove() {
        throw new UnsupportedOperationException();
    }
}

然后ConcreteIterator

private class Itr<E> implements Iterator<E> {
        private int position = -1;
        private Object[] data = elements;
        @Override
        public boolean hasNext() {
            return ++ position < data.length;
        }

        @Override
        public E next() {
            return (E) data[position];
        }
}

然后是aggregate

public interface Iterable<E> {
    Iterator<E> createIterator();
}

concrete aggregate

public class MyContainer<E> implements Iterable<E>{

    Object[] elements;
    public MyContainer() {
        elements = new Byte[10];
        for (int i =0; i < 10; i ++)
            elements[i] = (byte) i;
    }
    @Override
    public Iterator<E> createIterator() {
        return new Itr();
    }

}

客户端

iterator it = new MyContainer<Byte>().createIterator()；
while (elements.hasNext()) {
    System.out.println(elements.next());
}

注：为什么不让容器直接继承Iterator接口，还要整个Iterable接口？

为了提供容器内数据安全性。假设容器实现了Iterator接口，那么我们所有通过Iterator接口进行的数据访问修改操作都会直接影响容器内的数据，因为我们访问的数据和容器维护的数据是同一份数据。所以不如让Iterator接口访问数据副本来的安全。自己用自己的，互不影响。

9. 访问者模式

为什么有访问者模式：

将稳定的数据结构和易变的数据访问操作分离，满足开闭原则。 

优点： 

• 将有关元素对象的访问行为集中到一个访问者对象中，而不是分散在一个个的元素类中，符合单一职责原则；
• 可以通过接受新的访问者增加新的访问操作十分方便，对扩展开放，符合开闭原则。

缺点：

• 访问者模式中具体元素对访问者公布细节，破坏了对象的封装性，违反了迪米特原则；
• 每增加一个新的元素类，都要在每一个具体访问者类中增加相应的具体操作，违反了开闭原则；
• 违反了依赖倒置原则，依赖了具体类，没有依赖抽象

应用场景：

最复杂的设计模式，并且使用频率不高。一般场景如下：

 1、对象结构中对象对应的元素类很少改变，但经常需要在此对象结构上定义新的操作；

 2、需要对一个对象结构中的元素进行很多不同的并且不相关的操作，而需要避免让这些操作"污染"

实现：

抽象访问者（Vistor）：抽象访问者为对象结构中每一个具体元素类声明一个访问操作，从这个操作的名称或参数类型可以清楚知道需要访问的具体元素的类型，具体访问者需要实现这些操作方法，定义对这些元素的访问操作；
具体访问者（ConcreteVisitor）：具体访问者实现了每个由抽象访问者声明的操作； 
抽象元素（Element）：抽象元素一般是抽象类或者接口，它定义一个accept()方法，该方法通常以一个抽象访问者作为参数；
具体元素（ConcreteElement）：具体元素实现了accept()方法，在accept()方法中调用访问者的访问方法以便完成对一个元素的操作； 
对象结构（ObjectStructure）：对象结构是一个元素的集合，它用于存放元素对象，并且提供了遍历其内部元素的方法。

 它其实是对不同数据结构的访问封装，例如

// 抽象元素
public interface Element {
    void accept(Visitor visitor);
}
// 具体元素A 
public class ElementA implements Element {
    @Override
    public void accept(Visitor visitor) {
        visitor.visit(this);
    }
}
// 具体元素B 
public class ElementB implements Element {
    @Override
    public void accept(Visitor visitor) {
        visitor.visit(this);
    }
}
// 抽象访问者 
public abstract class Visitor {
    public abstract void visit(ElementA elementA);
    public abstract void visit(ElementB elementB);
}
// 具体访问者A 
public class VisitorA extends Visitor {
    @Override
    public void visit(ElementA elementA) {
        System.out.println(this + ":elementA");
    }
 
    @Override
    public void visit(ElementB elementB) {
        System.out.println(this + ":elementB");
    }
}
// 对象结构 
public class ObjectStructure {
    private List<Element> elementList;
 
    public ObjectStructure() {
        this.elementList = new ArrayList<>();
    }
 
    public void addElement(Element element) {
        elementList.add(element);
    }
 
    public void removeElement(Element element) {
        elementList.remove(element);
    }
 
    public void accept(Visitor visitor) {
        elementList.forEach(element -> element.accept(visitor));
    }
}
// 客户端 
@Test
public void VisitorTest() {
   ObjectStructure objectStructure = new ObjectStructure();
   objectStructure.addElement(new ElementA());
   objectStructure.addElement(new ElementB());
   objectStructure.accept(new VisitorA());
}

输出：

com.test.visitor.visitorA@33a10788:ElementA
com.test.visitor.visitorA@33a10788:ElementB

10. 备忘录模式

为什么有备忘录模式：

保存对象的状态，恢复对象的状态 

优点： 

• 给用户提供了一种可以恢复状态的机制，可以是用户能够方便的回到某个历史的状态；
• 简化了发起人类。发起人不需要管理和保存其内部状态的各个备份，所有状态信息都保存在备忘录中，并由管理者进行管理，符合单一职责原则

缺点：

• 资源消耗过大，如果需要保存的发起人类的成员变量太多，就不可避免需要占用大量的存储空间，每保存一次对象的状态都需要消耗一定的系统资源

应用场景：

JDK、Spring很少用备忘录的场景，一般常用于需要保存/恢复数据的相关状态场景，比如：

浏览器回退：当我们可以在浏览器左上角点击左箭头回退到上一次的页面，也可以点击右箭头重新回到当前页面

数据库备份与还原：备份当前已有的数据或者记录保留，还原已经保留的数据

编辑器撤销与重做：写错时可以按快捷键 Ctrl + z 撤销，撤销后可以按 Ctrl + y 重做（md 竟然现在才知道......）

虚拟机生成快照与恢复：虚拟机可以生成一个快照，当虚拟机发生错误时可以恢复到快照的样子

Git版本管理：Git是最常见的版本管理软件，每提交一个新版本，实际上Git就会把它们自动串成一条时间线，每个版本都有一个版本号，使用 git reset --hard 版本号 即可回到指定的版本

棋牌游戏悔棋：在棋牌游戏中可以悔棋，回退到上一步状态

实现：

该模式具有以下角色：

发起人角色（Originator）：当前时刻的内部状态信息，提供创建备忘录和恢复备忘录数据的功能，实现其他业务功能；

备忘录角色（Memento）：负责存储发起人的内部状态，在需要的时候提供这些内部状态给发起人。

管理者角色（Caretaker）：对备忘录进行管理，提供保存与获取备忘录的功能，但其不能对备忘录的内容进行访问与修改。

还需要注意下宽接口和窄接口：

窄接口：只允许它把备忘录对象传给其他的对象，针对的是负责人对象和其他除发起人对象之外的任何对象。

宽接口:  允许它读取所有的数据，以便根据这些数据恢复这个发起人对象的内部状态，针对发起人。 

// 备忘录类
public class Memento {
   private String state;
 
   public Memento(String state){
      this.state = state;
   }
 
   public String getState(){
      return state;
   }  
}

// 发起人类
public class Originator {
   private String state;
 
   public void setState(String state){
      this.state = state;
   }
 
   public String getState(){
      return state;
   }
 
   public Memento saveStateToMemento(){
      return new Memento(state);
   }
 
   public void getStateFromMemento(Memento Memento){
      state = Memento.getState();
   }
}

// 管理者类
import java.util.ArrayList;
import java.util.List;
 
public class CareTaker {
   private List<Memento> mementoList = new ArrayList<Memento>();
 
   public void add(Memento state){
      mementoList.add(state);
   }
 
   public Memento get(int index){
      return mementoList.get(index);
   }
}

// 客户端
public class MementoPatternDemo {
   public static void main(String[] args) {
      Originator originator = new Originator();
      CareTaker careTaker = new CareTaker();
      originator.setState("State #1");
      originator.setState("State #2");
      careTaker.add(originator.saveStateToMemento());
      originator.setState("State #3");
      careTaker.add(originator.saveStateToMemento());
      originator.setState("State #4");
 
      System.out.println("Current State: " + originator.getState());    
      originator.getStateFromMemento(careTaker.get(0));
      System.out.println("First saved State: " + originator.getState());
      originator.getStateFromMemento(careTaker.get(1));
      System.out.println("Second saved State: " + originator.getState());
   }
}

// 输出
Current State: State #4
First saved State: State #2
Second saved State: State #3

11. 解释器模式

为什么有解释器模式：

对于一些固定文法构建一个解释句子的解释器，其中文法是文法是用于描述语言语法结构的形式规则

优点： 

• 扩展性，修改语法规则只要修改相应的非终结符表达式就可以了；若扩展语法，则只要增加非终结符类就可以了

缺点：

• 执行效率较低。解释器模式中通常使用大量的循环和递归调用，当要解释的句子较复杂时，其运行速度很慢，且代码的调试过程也比较麻烦；
• 会引起类膨胀。解释器模式中的每条规则至少需要定义一个类，当包含的文法规则很多时，类的个数将急剧增加，导致系统难以管理与维护；
• 可应用的场景比较少。在软件开发中，需要定义语言文法的应用实例非常少，所以这种模式很少被使用到。

应用场景：

解释器模式在实际的软件开发中使用比较少，因为它会引起效率、性能以及维护等问题。如果碰到对表达式的解释，在JAVA 中可以用 Expression4J 或 Jep 等来设计。该模式主要应用在：

• 当语言的文法较为简单，且执行效率不是关键问题时；
• 当问题重复出现，且可以用一种简单的语言来进行表达时；
• 当一个语言需要解释执行，并且语言中的句子可以表示为一个抽象语法树的时候，如XML文档解释

实现：

该模式具有以下角色：

抽象解释器（AbstractExpression）：它包含了解释方法 interpret；
终结符表达式（TerminalExpression）：实现与文法中的元素相关联的解释操作，通常一个解释器模式中只有一个终结表达式，但对应不同的终结符，比如四则运算中的终结符就是运算元素；
非终结符表达式（NonterminalExpression）：文法中的每条规则对应于一个非终结表达式，比如四则运算中的加法运算、减法运算等
上下文（Context）: 上下文环境类,包含解释器之外的全局信息，一般是 HashMap

实现一个简单的计算器 

// 解释器接口
public interface Expression {
    int interpreter(Context context);//一定会有解释方法
}

// 终结符表达式（在这个例子，用来存放数字，或者代表数字的字符）
public class TerminalExpression implements Expression{

    String variable;
    public TerminalExpression(String variable){

        this.variable = variable;
    }
    @Override
    public int interpreter(Context context) {
        return context.lookup(this);
    }
}

// 抽象非终结符表达式
public abstract class NonTerminalExpression implements Expression{
    Expression e1,e2;
    public NonTerminalExpression(Expression e1, Expression e2){

        this.e1 = e1;
        this.e2 = e2;
    }
}

// 加法运算
public class PlusOperation extends NonTerminalExpression {

    public PlusOperation(Expression e1, Expression e2) {
        super(e1, e2);
    }

    //将两个表达式相加
    @Override
    public int interpreter(Context context) {
        return this.e1.interpreter(context) + this.e2.interpreter(context);
    }
}

// 减法表达式实现类
public class MinusOperation extends NonTerminalExpression {

    public MinusOperation(Expression e1, Expression e2) {
        super(e1, e2);
    }

 //将两个表达式相减
    @Override
    public int interpreter(Context context) {
        return this.e1.interpreter(context) - this.e2.interpreter(context);
    }
}


// 上下文类（这里主要用来将变量解析成数字【当然一开始要先定义】
public class Context {
    private Map<Expression, Integer> map = new HashMap<>();

    //定义变量
    public void add(Expression s, Integer value){
        map.put(s, value);
    }
    //将变量转换成数字
    public int lookup(Expression s){
        return map.get(s);
    }
}

// 测试类
public class Test {
    public static void main(String[] args) {

        Context context = new Context();
        TerminalExpression a = new TerminalExpression("a");
        TerminalExpression b = new TerminalExpression("b");
        TerminalExpression c = new TerminalExpression("c");
        context.add(a, 4);
        context.add(b, 8);
        context.add(c, 2);

        System.out.println(new MinusOperation(new PlusOperation(a,b), c).interpreter(context));
    }
}

运行结果如下
-----------------------------------
10