一. 工厂模式

需求：设计一个咖啡店点餐系统。

设计一个咖啡类（Coffee），并定义其两个子类（美式咖啡【AmericanCoffee】和拿铁咖啡【LatteCoffee】）；再设计一个咖啡店类（CoffeeStore），咖啡店具有点咖啡的功能。

在java中，万物皆对象，这些对象都需要创建，如果创建的时候直接new该对象，就会对该对象耦合严重，假如我们要更换对象，所有new对象的地方都需要修改一遍，这显然违背了软件设计的开闭原则。如果我们使用工厂来生产对象，我们就只和工厂打交道就可以了，彻底和对象解耦，如果要更换对象，直接在工厂里更换该对象即可，达到了与对象解耦的目的；所以说，工厂模式最大的优点就是：解耦。

开闭原则：对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。

三种工厂

• 简单工厂模式

• 工厂方法模式

• 抽象工厂模式

1.1 简单工厂模式

简单工厂包含如下角色：

• 抽象产品 ：定义了产品的规范，描述了产品的主要特性和功能。

• 具体产品 ：实现或者继承抽象产品的子类

• 具体工厂 ：提供了创建产品的方法，调用者通过该方法来获取产品。

优点：

        封装了创建对象的过程，可以通过参数直接获取对象。把对象的创建和业务逻辑层分开，这样以后就避免了修改客户代码，如果要实现新产品直接修改工厂类，而不需要在原代码中修改，这样就降低了客户代码修改的可能性，更加容易扩展。

缺点：

        增加新产品时还是需要修改工厂类的代码，违背了“开闭原则”。

1.2 工厂方法模式

工厂方法模式的主要角色：

• 抽象工厂（Abstract Factory）：提供了创建产品的接口，调用者通过它访问具体工厂的工厂方法来创建产品。

• 具体工厂（ConcreteFactory）：主要是实现抽象工厂中的抽象方法，完成具体产品的创建。

• 抽象产品（Product）：定义了产品的规范，描述了产品的主要特性和功能。

• 具体产品（ConcreteProduct）：实现了抽象产品角色所定义的接口，由具体工厂来创建，它同具体工厂之间一一对应。

调用关系如下：

优点：

• 用户只需要知道具体工厂的名称就可得到所要的产品，无须知道产品的具体创建过程；

• 在系统增加新的产品时只需要添加具体产品类和对应的具体工厂类，无须对原工厂进行任何修改，满足开闭原则；

缺点：

• 每增加一个产品就要增加一个具体产品类和一个对应的具体工厂类，这增加了系统的复杂度。

1.3 抽象工厂模式

        工厂模式只考虑生产同等级的产品，抽象工厂可以处理多等级产品的生产。

        抽象工厂模式是工厂方法模式的升级版本，工厂方法模式只生产一个等级的产品，而抽象工厂模式可生产多个等级的产品。

        一个超级工厂创建其他工厂，该超级工厂又称为其他工厂的工厂

• 产品族：一个品牌下面的所有产品；例如华为下面的电脑、手机称为华为的产品族；

• 产品等级：多个品牌下面的同种产品；例如华为和小米都有手机电脑为一个产品等级；

实现

现咖啡店业务发生改变，不仅要生产咖啡还要生产甜点

• 同一个产品等级（产品分类）

  • 咖啡：拿铁咖啡、美式咖啡

  • 甜点：提拉米苏、抹茶慕斯

• 同一个风味，就是同一个产品族（相当于同一个品牌）

  • 美式风味：美式咖啡、抹茶慕斯

  • 意大利风味：拿铁咖啡、提拉米苏

要是按照工厂方法模式，需要定义提拉米苏类、抹茶慕斯类、提拉米苏工厂、抹茶慕斯工厂、甜点工厂类，很容易发生类爆炸情况。

调用关系

优点：

        当一个产品族中的多个对象被设计成一起工作时，它能保证客户端始终只使用同一个产品族中的对象。

缺点：

        当产品族中需要增加一个新的产品时，所有的工厂类都需要进行修改。

总结

1. 简单工厂

• 所有的产品都共有一个工厂，如果新增产品，则需要修改代码，违反开闭原则
• 是一种编程习惯，可以借鉴这种编程思路

2. 工厂方法模式

• 给每个产品都提供了一个工厂，让工厂专门负责对应的产品的生产，遵循开闭原则
• 项目中用的最多

3. 抽象工厂方法模式

• 如果有多个维度的产品需要配合生产时，优先建议采用抽象工厂（工厂的工厂）
• 一般的企业开发中的较少

二. 策略模式

2.1 概述

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

优点：

• 策略类之间可以自由切换
• 易于扩展
• 避免使用多重条件选择语句（if else，充分体现面向对象设计思想）

缺点：

• 客户端必须知道所有的策略类，并自行决定使用哪一个策略类
• 策略模式将造成产生很多策略类

总结

三. 责任链设计模式

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

        比较常见的springmvc中的拦截器，web开发中的filter过滤器

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

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

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

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

案例

代码：

抽象处理者

package com.itheima.designpattern.chain;

/**
 * 抽象处理者
 */
public abstract class Handler {

    protected Handler handler;

    public void setNext(Handler handler) {
        this.handler = handler;
    }

    /**
     * 处理过程
     * 需要子类进行实现
     */
    public abstract void process(OrderInfo order);
}

订单信息类：

package com.itheima.designpattern.chain;


import java.math.BigDecimal;

public class OrderInfo {

    private String productId;
    private String userId;

    private BigDecimal amount;

    public String getProductId() {
        return productId;
    }

    public void setProductId(String productId) {
        this.productId = productId;
    }

    public String getUserId() {
        return userId;
    }

    public void setUserId(String userId) {
        this.userId = userId;
    }

    public BigDecimal getAmount() {
        return amount;
    }

    public void setAmount(BigDecimal amount) {
        this.amount = amount;
    }
}

具体处理者：

/**
 * 订单校验
 */
public class OrderValidition extends Handler {

    @Override
    public void process(OrderInfo order) {
        System.out.println("校验订单基本信息");
        //校验
        handler.process(order);
    }

}

/**
 * 补充订单信息
 */
public class OrderFill extends Handler {
    @Override
    public void process(OrderInfo order) {
        System.out.println("补充订单信息");
        handler.process(order);
    }

}

/**
 * 计算金额
 */
public class OrderAmountCalcuate extends Handler {
    @Override
    public void process(OrderInfo order) {
        System.out.println("计算金额-优惠券、VIP、活动打折");
        handler.process(order);
    }

}

/**
 * 订单入库
 */
public class OrderCreate extends Handler {
    @Override
    public void process(OrderInfo order) {
        System.out.println("订单入库");
    }
}

客户类：

public class Application {

    public static void main(String[] args) {
        //检验订单
        Handler orderValidition = new OrderValidition();
        //补充订单信息
        Handler orderFill = new OrderFill();
        //订单算价
        Handler orderAmountCalcuate = new OrderAmountCalcuate();
        //订单落库
        Handler orderCreate = new OrderCreate();

        //设置责任链路
        orderValidition.setNext(orderFill);
        orderFill.setNext(orderAmountCalcuate);
        orderAmountCalcuate.setNext(orderCreate);

        //开始执行
        orderValidition.process(new OrderInfo());
    }

}

优点

• 降低了对象之间的耦合度

• 该模式降低了请求发送者和接收者的耦合度。

• 增强了系统的可扩展性

• 可以根据需要增加新的请求处理类，满足开闭原则。

• 增强了给对象指派职责的灵活性

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

• 责任链简化了对象之间的连接

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

• 责任分担

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

缺点：

• 不能保证每个请求一定被处理。由于一个请求没有明确的接收者，所以不能保证它一定会被处理，该请求可能一直传到链的末端都得不到处理。

• 对比较长的职责链，请求的处理可能涉及多个处理对象，系统性能将受到一定影响。

• 职责链建立的合理性要靠客户端来保证，增加了客户端的复杂性，可能会由于职责链的错误设置而导致系统出错，如可能会造成循环调用。