设计模式简介

从事软件开发的人应该没有没学过设计模式的，就算没学过，在常用的框架和类库中也随处可见其身影。在我看来，它是对一系列常用的抽象的规则化，也就是说，你完全理解或者仅仅是背下来，在软件开发过程中它对你的影响也是有迹可循的。不过看懂和掌握其实是两码事，很多人刚开始学习都会经历疑惑--恍然大悟--妙不可言--生搬硬套的阶段，有时候为自己完美的使用设计模式重构代码而欣喜，有时候又因为过于激动而设计过度。。。
有些设计模式已经融入到了JDK和各大框架之中，我们开发时使用的空间已经很小了（例如迭代子模式已经被实现到Iterator等迭代器中），所以本文只从我自己实践的一些经验来分享设计模式的实际操作以及简单区分。

工厂模式：

在面试中被问到最多的两个模式应该是单例模式和工厂模式，单例模式实在没什么可说的，实际编码过程中用到的场景也很多，在此就跳过。
工厂模式是常用的创建对象的模式。一般由一个抽象类或接口，一系列的对象（抽象的具体实现），以及一个工厂组成。工厂的返回类型总是一个接口，而具体接口是哪种类型的实现，逻辑只在工厂中提供，也就是常说的对客户端，对调用方屏蔽具体实现。调用方只需要传入需要的参数，拿到返回的接口实例并使用即可。在框架中这种模式也十分十分的常见，用常见的spring和dubbo两个框架的源码举个例子：
初始化一系列的HandlerMapping，是springmvc核心处理器DispatcherServlet初始化时的操作之一。HandlerMapping是用户传递的url和实际处理的方法的映射器，SpringMvc提供了很多种处理器，BeanFactoryUtils作为bean的工厂初始化HandlerMapping的所有实现，返回的Map中的类型都是HandlerMapping，也就是接口，在使用中不用关心HandlerMapping的类型到底是哪个子类。这种设计在spring中随处可见，正因为这样的抽象使得spring拥有了惊人的扩展性和生命力。

private void initHandlerMappings(ApplicationContext context) {
        this.handlerMappings = null;
        if (this.detectAllHandlerMappings) {
            Map<String, HandlerMapping> matchingBeans =
                    BeanFactoryUtils
     .beansOfTypeIncludingAncestors(context, HandlerMapping.class, 
     true, false);
            //...省略无关代码
        }
        else {
            //...
        }

        //...
    }

dubbo的服务暴露核心类ServiceBean，

策略模式：

策略模式在spring mvc中也很常见，在此举一个我的实际使用案例，业务场景更为简单，代码也更简单。
支付系统的对账模块中设置了一个定时任务，定时去银行下载交易明细文件用来对资金明细进行核对。任务发起和任务执行分别是两个系统，当任务执行系统接受到下载的请求，就会起一个线程去异步下载，下载的任务DownloadTask有两种，下载的国策灰姑娘大同小异，区别是一种在下载完成以后以dubbo形式通知任务的发起方，另一种是以mq的形式。两种任务都实现了Runnable接口，任务执行系统根据实际需要new一个task丢到线程池里执行。
这就是典型的策略模式，策略模式的定义是一组算法或问题的执行逻辑，封装到不同的类中，这些类可以相互替换，由客户端（或者说调用方）来决定使用哪一种策略。如上提到，两种Task对应了下载的两种策略，这两种策略没有优先级之分（有优先级就得是责任链模式了），可以互相替换，替换之后系统都不会出错。客户端可以自己决定使用哪种策略，或者将策略的执行封装到工厂中，客户端从工厂获取两个类的共同抽象----Runnable接口，然后丢到线程池中执行。结合工厂模式使用的好处是可以对客户端屏蔽策略的选择和实现，客户端不需要知晓所有的策略。
伪代码如下：

 //根据一定的条件从工厂挑选策略
 Runnable task = TaskFactory.get(xxx);
 //策略的共同抽象执行
 threadPoolTaskExecutor.execute(task);

责任链模式：

还是以策略模式中提到的场景为背景，某一天公司为了统一技术规范，要求系统之间的通知优先使用MQ，如果MQ消息发送失败或者topic不存在，才使用dubbo 接口的方式通知。此时由于任务的两种解决方案已经有了优先级，我们可以使用责任链模式了，顾名思义，就是责任的传递。
伪代码如下，客户端先调用优先级高的MQTask，并为其设置了责任的下一任传递者DubboTask，当MQTask执行失败时，将责任传递下去

//客户端
class client {
    public void main () {
        DubboTask dubboTask = new DubboTask();
        //dubboTask作为mqtask的责任下游
        MQTask mqTask = new MQTask(dubboTask);
        //先执行mqTask
        mqTask.run();
    }
}

class MQTask extends Task{
    Task next;

    public MQTask(Task next) {
        this.next = next;
    }
    
    public void run() {
        //...do something
        if (failed) {
            //失败了就交给下一任执行
            next.run();
        }
    }
    next.run();
}

class DubboTask extends Task {
    Task next;

    public DubboTask(Task next) {
        this.next = next;
    }

    public void run() {
        //do something
        if (failed) {
            next.run();
        }
    }
    next.run();
}

建造者模式：

建造者模式的场景有四个对象，Builder(真实的建造者)，ConcreteBuilder(builder的抽象)，product（最终build出的结果对象），Director（操作者）。建造者模式无需额外举例子，常见的StringBuilder就是一个经典的实现。一个对象的构建过程对客户端屏蔽，各个组件分别组合，最终组成需要的结果，在StringBuilder的使用中，最终的String对象就是product，而StringBuilder对象就是Builder的角色了，我们调用的过程就扮演了一个Director的角色。与工厂模式需要区分的是，工厂模式专注于单个对象的创建，而建造者模式专注于对象创建的过程。
从源码我们可以看到，append方法结束后返回this，以便客户端可以进行链式调用，直到整个对象全部建造完成。

@Override
    public StringBuilder append(String str) {
        super.append(str);
        return this;
    }

。。。待续