工程师精讲：设计模式的九种模式（上）

Posted 2021-04-25 嵌入式ARM

一

模版方法模式

简述

模版方法模式是很比较简单的一种模式，也是非常常用的一种设计模式, 相信大家工作过程中直接或间接用到过很多。

下面我们看下对应的UML图和相应的代码

图例

代码

现在我们臆想一个业务场景,比如对接不同的支付渠道(大部分都是基于官方提供的sdk集成),假设我们步骤如下:

1. 签名鉴权
2. 统一下单
3. 返回支付信息

对接支付宝支付的代码:

package design.pattern;

public class AliPay {

    /**
     * start
     */
    public void start() {
        System.out.println("某种操作,我现在只是一个范例");

    }

    /**
     * 接口鉴权
     */
    public void auth() {
        System.out.println("支付宝--生成sign校验是否合法");
    }

    /**
     * 向第三方下订单
     */
    public void thirdOrder() {
        System.out.println("支付宝--下订单接口");
    }

    /**
     * 获取支付平台信息
     */
    public void getPayInfo() {
        System.out.println("支付宝--获取支付平台信息");
    }

}

对接微信支付的代码

package design.pattern;

public class WxPay {

    /**
     * start
     */
    public void start() {
        System.out.println("某种操作,我现在只是一个范例");

    }

    /**
     * 接口鉴权
     */
    public void auth() {
        System.out.println("微信支付--生成sign校验是否合法");
    }

    /**
     * 向第三方下订单
     */
    public void thirdOrder() {
        System.out.println("微信支付--下订单接口");
    }

    /**
     * 获取支付平台信息
     */
    public void getPayInfo() {
        System.out.println("微信支付--获取支付平台信息");
    }
}

客户端调用:

//支付宝支付
AliPay aliPay = new AliPay();
aliPay.start();
aliPay.auth();
aliPay.thirdOrder();
aliPay.getPayInfo();

//微信支付
WxPay wxPay = new WxPay();
wxPay.start();
wxPay.auth();
wxPay.thirdOrder();
wxPay.getPayInfo();

通过上面的例子我们发现了这两个类的代码其实有很多相似的地方,他们之间存在着重复性代码,如start方法。是先鉴权还是先下订单，这种完全依靠业务方的调用顺序。

我们用模版方法模式来优化下.

首先我们想到,先把一部分公用方法的供不同支付平台共享,把调用顺序的细节封装起来。

公共基础类(算法类):

package design.pattern;

public abstract class Pay {

    /**
     * start
     */
    public void start() {
        System.out.println("某种操作,我现在只是一个范例");

    }

    abstract void auth();

    abstract void thirdOrder();

    abstract void getPayInfo();

    //实现调度顺序
    public void templateMethod() {
        //step1
        start();
        //step2
        auth();
        //step3
        thirdOrder();
        //step4
        getPayInfo();
    }
}

对应的具体支付类:

package design.pattern;

public class AliPay extends Pay {

    /**
     * 接口鉴权
     */
    public void auth() {
        System.out.println("支付宝--生成sign校验是否合法");
    }

    /**
     * 向第三方下订单
     */
    public void thirdOrder() {
        System.out.println("支付宝--下订单接口");
    }

    /**
     * 获取支付平台信息
     */
    public void getPayInfo() {
        System.out.println("支付宝--获取支付平台信息");
    }

}

业务方调用者:

AliPay aliPay = new AliPay();
aliPay.templateMethod();

WxPay wxPay = new WxPay();
wxPay.templateMethod();

output:

某种操作,我现在只是一个范例
支付宝--生成sign校验是否合法
支付宝--下订单接口
支付宝--获取支付平台信息

某种操作,我现在只是一个范例
微信支付--生成sign校验是否合法
微信支付--下订单接口
微信支付--获取支付平台信息

经过简单的改造,pay基础类只需要关注公共部分和调用顺序就可以了,更加方便修改。而其余的业务细节由子类来实现。

但是可能还有其他的情况,比如我想对某个流程做一些开关怎么办,那就需要用到了Hook.

支付基础类

package design.pattern;

public abstract class Pay {

    /**
     * start
     */
    public void start() {
        System.out.println("某种操作,我现在只是一个范例");

    }

    abstract void auth();

    abstract void thirdOrder();

    abstract void getPayInfo();

    public void templateMethod() {
        //step1
        start();
        //step2
        auth();
        //step3
        if (isOrderOpen()) {
            thirdOrder();
        }
        //step4
        getPayInfo();
    }

    /**
     * 是否开启订单方式
     *
     * @return
     */
    protected boolean isOrderOpen() {
        return true;
    }
}

默认是开启向第三方下订单的,比如某个平台不需要这个操作,就可以覆盖isOrderOpen方法就可以了。

package design.pattern;

public class AliPay extends Pay {

    /**
     * 接口鉴权
     */
    public void auth() {
        System.out.println("支付宝--生成sign校验是否合法");
    }

    /**
     * 向第三方下订单
     */
    public void thirdOrder() {
        System.out.println("支付宝--下订单接口");
    }

    /**
     * 获取支付平台信息
     */
    public void getPayInfo() {
        System.out.println("支付宝--获取支付平台信息");
    }

    protected boolean isOrderOpen() {
        //todo
        return false;
    }
}

---

衍生出来的好莱坞原则:

这句话很霸道。。。

其实意思高层组件允许低层组件挂钩到系统上,但是高层组件决定什么和如何去使用这些低层组件.换句话说: 高层组件对待低层组件的方式就是“别调用我们,我们会调用你”。

总结: 上面提出的例子不一定适合这个模式,希望能够理解模版方法模式的意思就好了。

简要来说: 模版方法模式是通过把不变行为搬到了超类,去除了子类中的重复代码。

相似模式: 策略模式

二

策略模式

简介

策略模式属于用处很多并且很简单的一种设计模式

在策略模式（Strategy Pattern）中，一个类的行为或其算法可以在运行时更改。这种类型的设计模式属于行为型模式。

策略模式中定义了算法家族,分别封装起来,让他们之间可以相互替换,此模式让算法的变化,不会影响到使用算法的客户。

场景描述

我们再来假设一个场景,根据不同的下订单入口对用户进行积分奖励

app下单用户	web下单用户	小程序下单用户
奖励100积分	奖励20积分	奖励50积分

坏代码

package design.pattern.reward;

public class Reward {

    /**
     * 下单平台 0 web  1 小程序 2 app
     */
    private int platform = 0;

    public Reward(int platform) {
        this.platform = platform;
    }

    /**
     * 给用户送积分
     */
    public void giveScore() {

        int score = 0;

        switch (platform) {
            case 0: //web
                //todo
                score = 20;
                break;
            case 1: //小程序
                //todo
                score = 50;
                break;
            case 2: //app
                //todo
                score = 100;
                break;
        }

        System.out.println("送给用户" + score + "分");
    }
}

业务调用:

package design.pattern.reward;

public class PayNotify {

    public static void main(String[] args) {

        Reward reward = new Reward(2);
        reward.giveScore();
    }
}

当我们的算法越来越多,越来越复杂的时候,并且当某个算法发生变化,将对所有其他计算方式都会产生影响,不能有效的弹性、清晰的拓展,所以这个时候我们的策略模式就上场了。

策略模式UML图(画图工具不工作了)

策略模式实现

1.首先接口声明-抽象策略

package design.pattern.reward.score;

public interface InterfaceScore {

    /**
     * 送积分
     */
    public void giveScore();
}

2.我们实现接口的giveScore方法-实现具体策略算法

app端积分

package design.pattern.reward.score;

public class AppScore implements InterfaceScore {

    private int score = 100;

    /**
     * 送积分
     */
    public void giveScore() {
        //todo 具体算法逻辑
        System.out.println("送你积分" + score);
    }
}

web端积分:

package design.pattern.reward.score;

public class WebScore implements InterfaceScore {

    private int score = 20;

    /**
     * 送积分
     */
    public void giveScore() {
        //todo 具体算法逻辑
        System.out.println("送你积分" + score);
    }
}

3. 不同策略算法调度类

package design.pattern.reward;

import design.pattern.reward.score.InterfaceScore;

public class Context {

    private InterfaceScore scoreObj;

    public Context(InterfaceScore algorithmObj) {
        this.scoreObj = algorithmObj;
    }

    public void giveScore() {
        this.scoreObj.giveScore();
    }

}

4. 客户端调用

Context context1 = new Context(new AppScore());
context1.giveScore();

Context context2 = new Context(new WebScore());
context2.giveScore();

output：

送你积分100
送你积分20

好像跟我们刚开始的调用方法不一样，约定好的是传一个type值来确定计算的方法,现在直接将计算规则方法暴露给了调用方

继续改造 策略模式+简单工厂

package design.pattern.reward;

import design.pattern.reward.score.AppScore;
import design.pattern.reward.score.InterfaceScore;
import design.pattern.reward.score.WebScore;

public class Context {

    private InterfaceScore scoreObj;

    public Context(int platform) {
        switch (platform) {
            case 0: //web
                this.scoreObj = new WebScore();
                break;
            case 1: //小程序
                //todo
                break;
            case 2: //app
                this.scoreObj = new AppScore();
                break;
        }

    }

    public void giveScore() {
        this.scoreObj.giveScore();
    }
}

调用:

Context context1 = new Context(0);
context1.giveScore();

Context context2 = new Context(2);
context2.giveScore();

是不是很简单。。。

总结:

策略模式是一种定义一系列算法的方法,从概念上来看,所有这些算法完成的都是相同的工作,只是实现不同,他可以以相同的方式调用所有的算法.减少了算法与使用算法之间的耦合.

策略模式是用来封装算法的，但在实践中我们可以用它来封装几乎任何类型的规则, 只要在分析过程中需要在不同时间应用不同的业务规则,就可以考虑使用策略模式处理这种变化的可能性。

和上次讲到的模版方法模式差异

模版方法模式使用了继承方式实现算法,而策略模式使用了组合方式
模版方法模式对于算法拥有绝对的控制,而策略模式不对算法控制
模版方法的依赖程度要比策略模式高
。。。。。

参考资料: 《大话设计模式》

三

装饰者模式

简介

装饰模式也算一种比较常见的设计模式,工作过程中很少刻意的去实现这种模式，因为这种模式也会带来一些问题。

比如小类太多,组织起来比较麻烦,对客户端完全可见,如果不了解各个类的功能会很乱等等

当然也有很多优点: 可以动态的给类增加一些职责,增加功能更加灵活，比起继承来说也更加具有弹性

下面我们来看看它究竟是什么样子的

场景设置

以买车业务模型为例(本人未买过车,业务场景纯属臆想)

车里面还有很多装备可以选择,根据不同的选择装饰决定最后到手的价格:

商品	价格
裸车	100000
加热座椅(可选)	4000
真皮内饰(可选)	8000
蹦迪音响(可选)	5000

第一版本实现(我们在一个类里面完成)

package car;

public class Car {

    //总价
    private int allPrice = 0;

    //裸车价格 --实际数值从数据库查询,此处略
    private int nakedPrice = 100000;

    //加热座椅
    private int heatedSeat = 4000;

    //真皮内饰
    private int dermalInteriors = 8000;

    //蹦迪音响
    private int bengdiSound = 5000;


    public Car() {
        this.allPrice += this.nakedPrice;
    }

    /**
     * 添加真皮座椅
     */
    public void addHeatedSeat() {
        this.allPrice += this.heatedSeat;
    }

    /**
     * 添加真皮内饰
     */
    public void addDermalInteriors() {
        this.allPrice += this.dermalInteriors;
    }

    /**
     * 添加蹦迪音响
     */
    public void addBengdiSound() {
        this.allPrice += this.bengdiSound;
    }

    /**
     * 获取总价
     *
     * @return
     */
    public int cost() {
        return this.allPrice;
    }

}

客户端调用:

package car;

public class Main {

    public static void main(String[] args) {

        Car car = new Car();

        car.addBengdiSound();
        System.out.println("总花费价格:" + car.cost());

    }

}

output：

花费价格105000

看起来很简洁呢，并且也很好的实现了功能

首先这是我们的场景足够的简单,所涉及的配套组件也比较少,实际中可能针对某个方法可能有很复杂的获取和计算逻辑,组件也会有很多种选择,会造成类爆炸,无法继续维护下去

如果我们使用装饰模式,会带来什么改变呢，会给我们带来什么样的体验呢

设计:

实现:

声明抽象类(被装饰者和装饰者继承此类,目的对实现方法进行规正)

package car;

public abstract class Car {

    public String name;

    public abstract String cost();
}

主角:被装饰者类－裸车

package car;

/**
 * 被装饰的类 -> 裸车
 */
public class NakeCar extends Car {

    //裸车价格 --实际数值从数据库查询,此处略
    private int nakedPrice = 100000;


    public NakeCar() {
        this.name = "裸车";
    }

    /**
     * 获取总价
     *
     * @return
     */
    public String cost() {
        return this.name + ":" + this.nakedPrice;
    }
}

具体装饰类:

加热座椅

package car;

/**
 * 装饰组件
 */
public class HeatedSeat extends Car {

    //加热座椅
    private int heatedSeat = 4000;

    //汽车对象
    private Car car;

    public HeatedSeat(Car car) {
        this.name = "加热座椅";
        this.car = car;
    }

    /**
     * 获取价格
     *
     * @return
     */
    public String cost() {
        //todo
        return this.car.cost() + "||" + this.name + ":" + this.heatedSeat;
    }

}

真皮内饰

package car;

public class DermalInteriors extends Car {

    //真皮内饰
    private int dermalInteriors = 8000;

    //汽车对象
    private Car car;

    public DermalInteriors(Car car) {
        this.name = "真皮内饰";
        this.car = car;
    }

    /**
     * 获取价格
     *
     * @return
     */
    public String cost() {
        //todo
        return this.car.cost() + "||" + this.name + ":" + this.dermalInteriors;
    }

}

蹦迪音响

package car;

public class BengdiSound extends Car {

    //蹦迪音响
    private int bengdiSound = 5000;

    //汽车对象
    private Car car;

    public BengdiSound(Car car) {
        this.name = "蹦迪音响";
        this.car = car;
    }

    /**
     * 获取价格
     *
     * @return
     */
    public String cost() {
        //todo
        return this.car.cost() + "||" + this.name + ":" + this.bengdiSound;
    }
}

客户端调用:

package car;

public class Main {

    public static void main(String[] args) {

        NakeCar car = new NakeCar();

        HeatedSeat heatedSeat = new HeatedSeat(car);
        BengdiSound bengdiSound = new BengdiSound(heatedSeat);
        System.out.println("总花费价格:" + bengdiSound.cost());
    }
}

output:

总花费价格:裸车:100000||加热座椅:4000||蹦迪音响:5000

总结

• 装饰模式的优点:
  可以为已有的功能(被装饰对象)动态的添加功能,简化原有类。在我们的例子中, 裸车是主类,相当于业务中的核心,而一些动态的组件可以根据实际情况使用，也就相当于我们业务线中的附属拓展功能。

  主逻辑和拓展逻辑的区分会使我们的代码更具拓展性。

• 装饰模式的缺点:
  我们可以看到装饰模式的引入会增多类的数量,以及客户端的使用会有复杂度上升。装饰模式的类依赖特定的类型,需要严格遵守规约(抽象类的约束)

四

命令模式

简介

今天我们介绍又一个行为模式《命令模式》.

将一个请求封装为一个对象,从而使你可用不同的请求对客户端参数化；对请求排队或记录请求日志,以及支持可撤销的操作.

命令模式最初来源于图形化用户界面设计,但现在广泛应用于企业应用设计,特别促进了控制器(请求和分发处理)和领域模型(应用逻辑)的分离.说的更简单一点,命令模式有助于系统更好的进行组织,并易于拓展。

模式共包含: 请求者（INVOKER）、接收者（RECEIVER）、命令(COMMAND)接口、 具体命令（CONCRETE COMMAND)

场景设置

如果您在做点餐工具的研发,如何设计这个点餐系统呢(传统型餐厅)

涉及角色	职责
顾客	点餐、用餐、买单
服务员	下单
厨房	接单、成单

第一版本实现

我们看下order类实现

package design.pattern;

import java.util.Map;

public class Order {


    private Map<String, Object> params = null;

    public Order(Map<String, Object> params) {
        this.params = params;
    }

    /**
     * 创建订单
     */
    public void createOrder() {
        System.out.println("桌号" + params.get("桌号") + "创建订单");
    }

    /**
     * 生产订单
     */
    public void orderUp() {
        stirFryUp();
        stapleFoodUp();
    }

    /**
     * 炒菜组
     */
    private void stirFryUp() {
        Object stirFryUp = this.params.get("炒菜");
        if (stirFryUp != null) {
            for (Object val : (Object[]) stirFryUp) {
                System.out.println("生产炒菜:" + val);
            }
        }

    }

    /**
     * 主食组
     */
    private void stapleFoodUp() {
        Object stapleFood = this.params.get("主食");
        if (stapleFood != null) {
            for (Object val : (Object[]) stapleFood) {
                System.out.println("生产主食:" + val);
            }
        }
    }

}

我们看到这个类实现了订单创建到菜品输出

调用者:

 String[] stirFry = {"鱼香肉丝", "茄子"};
        String[] stapleFood = {"米饭"};

        Map<String, Object> params = new HashMap<String, Object>();
        params.put("桌号", 88);
        params.put("炒菜", stirFry);
        params.put("主食", stapleFood);

        Order order = new Order(params);
        //提交菜单
        order.createOrder();

        //生产菜单
        order.orderUp();

从点单到提交菜单 生产菜单流程

output:

桌号88创建订单
生产炒菜:鱼香肉丝
生产炒菜:茄子
生产主食:米饭

如果对于简单的需求来说,这个还是更加简单清晰的. 但是如果我们拓展更多的种类菜品,可能对于我们的类来说会越来越复杂.

我们用命令模式实现下

命令模式实现

• Receiver接受者角色：该角色就是干活的角色，命令传递到这里是应该被执行的

• Command命令角色：需要执行的所有命令都在这里声明

• Invoker调用者角色：接收到命令，并执行命令

具体工作流程图:

Receiver接受者角色(具体执行任务者)

package design.pattern.Receiver;

public abstract class Receiver {
    public abstract void doSomething();
}

炒菜具体工作实现

package design.pattern.Receiver;

/**
 * 炒菜组
 */
public class StirFryUpReceiver extends Receiver {

    private String[] menuList;

    public StirFryUpReceiver(String[] menuList) {
        this.menuList = menuList;
    }

    public void doSomething() {
        for (String v : menuList) {
            System.out.println("生产炒菜" + v);
        }
    }
}

主食组具体实现

package design.pattern.Receiver;

public class StapleFoodUpReceiver extends Receiver {

    private String[] menuList;

    public StapleFoodUpReceiver(String[] menuList) {
        this.menuList = menuList;
    }

    public void doSomething() {
        for (String v : menuList) {
            System.out.println("生产主食" + v);
        }
    }
}

Command命令角色(具体调用具体任务执行者,相当于饭店的柜台)

package design.pattern.Command;

/**
 * 命令抽象类
 */
public abstract class Command {
    abstract public void execute();
}

炒菜组命令接收类

package design.pattern.Command;

import design.pattern.Receiver.Receiver;

/**
 * 炒菜组Command
 */
public class StirFryUpCommand extends Command {

    private Receiver receiver;

    /**
     * 设置真正的处理者
     *
     * @param
     */
    public StirFryUpCommand(Receiver _receiver) {
        this.receiver = _receiver;
    }

    /**
     * 生产菜单
     */
    public void execute() {

        //对于炒菜设置其他事项
        //todo

        receiver.doSomething();
    }
}

主食组命令接收类

package design.pattern.Command;

import design.pattern.Receiver.Receiver;

/**
 * 主食组Command
 */
public class StapleFoodUpCommand extends Command {

    private Receiver receiver;

    /**
     * 设置真正的处理者
     *
     * @param
     */
    public StapleFoodUpCommand(Receiver _receiver) {
        this.receiver = _receiver;
    }

    /**
     * 生产菜单
     */
    public void execute() {
        receiver.doSomething();
    }
}

为什么要有命令类存在,直接调用实现不就可以了么.原因在于更加的灵活性,针对不同的实现,我们还可以在execute中完成不同任务的其他和具体炒菜、主食功能无关的相应操作.增强了功能实现的灵活性

命令调用者(服务员实现类,此类还可以实现在生产前取消命令)

package design.pattern;

import design.pattern.Command.Command;

import java.util.ArrayList;

/**
 * 服务员
 */
public class Waiter {

    private ArrayList<Command> commands =  new ArrayList<>();

    public void addCommand(Command _command) {
        this.commands.add(_command);
    }

    public void production() {
        for (Command command : commands) {
            command.execute();
        }
    }
}

这里我们使用了集合,目的在于我们可以添加命令,在执行production之前,还可以撤销命令。

客户端调用

String[] stirFry = {"鱼香肉丝", "茄子"};
String[] stapleFood = {"米饭"};

//炒菜小组
//命令具体实现者
StirFryUpReceiver stirFryUpReceiver = new StirFryUpReceiver(stirFry);
//命令绑定
StirFryUpCommand stirFryUpCommand = new StirFryUpCommand(stirFryUpReceiver);

//加份米饭
StapleFoodUpReceiver stapleFoodUpReceiver = new StapleFoodUpReceiver(stapleFood);
StapleFoodUpCommand stapleFoodUpCommand = new StapleFoodUpCommand(stapleFoodUpReceiver);

//服务员
Waiter waiter = new Waiter();
waiter.addCommand(stirFryUpCommand);
waiter.addCommand(stapleFoodUpCommand);
waiter.production();

客户端代码执行步骤:

1. 将具体菜单内容传递给执行者(厨师)

2. 将此执行者对象绑定到Command(柜台)中

3. 服务员类添加命令

4. 服务员执行下单，调用production()开始生产

output:

生产炒菜鱼香肉丝
生产炒菜茄子
生产主食米饭

关系图:

目录结构:

订单柜台模型

厨房类模型

服务员类

UML图

此图来源于网络, Invoker相当于我们的服务员类

疑问探讨:

问：接收者一定要存在吗,为什么命令对象不直接实现execute方法的细节?

答:上面已经回答了 “为什么要有命令类存在” 的问题, 核心还是看实际业务,主要在于项目复杂度和解耦的程度.

注意: 不是确定要用使用,最好不要在项目使用此模式,更多建议在优化阶段使用。

工作中大部分直接实现了请求,而不是像我们将工作委托给了接受者(Command->Receiver)

五

适配器模式

简介

适配器模式 将一个类的接口,转换成客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间

存在两种适配器: “对象适配器” 和 “类”适配器 (因为大部分语言不支持多重继承,所以此处指的是对象适配器)

y适配器模式包含一下三个角色：

　　1：Target(目标抽象类)：目标抽象类定义客户所需的接口，可以是一个抽象类或接口，也可以是具体类。在类适配器中，由于java、php语言不支持多重继承，所以它只能是接口。

　　2：Adapter(适配器类)：它可以调用另一个接口，作为一个转换器，对Adaptee和Target进行适配。它是适配器模式的核心。

　　3：Adaptee(适配者类)：适配者即被适配的角色，它定义了一个已经存在的接口，这个接口需要适配，适配者类包好了客户希望的业务方法。

图例:

场景设置

系统已经在之前实现了订单服务,在一个类里面实现的(坑爹的万能类),这个代码很复杂你们不想再冒风险去改动,并且有外部相关服务正在持续使用它。

就在这个时候,欠扁的产品给你提了一个需求,要你针对我们的后台改造下某个共用的接口,在这个基础上增加些字段,比如下单人的姓名.

我们用简单的适配器模式实现下 

代码实现

Order.php 相当于Adaptee需要适配的类

<?php

class Order
{
    /**
     * 根据订单号查询信息
     *
     * @param $orderNo
     * @return array
     */
    public function getInfoByOrderNo($orderNo)
    {
        //todo 数据资源操作
        return [
            'order' => [
                'orderId' => '2018050320423042',
                'title'   => '冬天大棉袄',
                'price'   => '68000',
            ],
        ];
    }
}

客户期望实现的接口类

<?php

interface OrderBackstage
{
    public function getUserOrderByOrderNo(int $orderNo): string;
}

OrderAdepter 适配类(把源接口转换成目标接口)

<?php

class OrderAdepter implements OrderBackstage
{
    private $orderService = null;

    public function __construct()
    {
        $this->orderService = new Order();
    }

    /**
     * 根据订单号获取用户userid
     */
    public function getUserOrderByOrderNo(int $orderNo): string
    {
        $order = $this->orderService->getInfoByOrderNo($orderNo);
        if (!empty($order)) {
            //todo 其它查询拼装
            $order['user'] = [
                'uid'    => 24,
                'name'   => '小明',
                'avatar' => 'http://xxx.com/xx.png'
            ];
        } else {
            $order = [];
        }

        return json_encode($order);
    }

}

调用:

$order  = new OrderAdepter();
$result = $order->getUserOrderByOrderNo(123);
echo $result;

output：

{"order":{"orderId":"2018050320423042","title":"\u51ac\u5929\u5927\u68c9\u8884","price":"68000"},"user":{"uid":24,"name":"\u5c0f\u660e","avatar":"http:\/\/xxx.com\/xx.png"}}

具体UML图:

总结

适配器模式比较简单,代码均采用php语言实现。

适配器模式主要应用于希望复用一些现存的类,但是接口要求又与复用环境要求不一致的情况。

使用适配器可最小化的影响旧有的业务系统,来增加新的功能。

通过适配器模式,我们下次可以看看外观模式究竟和有什么区别..

下篇见今日推送第二篇文章

授权转载自呆呆熊的技术路，其他媒体转载请授权