外观模式

概述

设计模式一书中对于 “外观模式” 的意图描述如下：

为子系统中的u一组接口提供一个一致的界面，外观模式定义了一个高层的接口，这个接口使得这一子系统更加容易使用

具体实例

以计算浮动利率为例，由于利率可能会发生变化，并且不同的产品期次对应的浮动利率检测配置并不一样，比如每月固定日期、每个季度的第几月份的固定日期等，一般来讲，只有恰好匹配到了对应的日期才会需要涉及到浮动利率的重新测算以及对应还本付息计划（还钱的本金和利息）的修改。

假设现在我们定义了一个检测当前日期是否为生效日期的服务类 WorkDateService：

public interface WorkDateService {
    boolean validWorkdDate(); // 今天是否需要执行浮动利率的测算
}

当需要进行浮动利率测算时，会根据一个参数模型根据相关的公式测算对应的浮动利率，假设现在我们也设计了利率的测算服务 RateCalService：

import java.math.BigDecimal;

public interface RateCalService {
    /**
    	通过指定的利率测算参数测算最新的有效浮动利率，具体的测算参数可能需要
    	访问数据库，但是在这里略过这部分的服务接口
    */
    BigDecimal calFloatRate(RateModel param);
}

当得到最新的浮动利率时，这就直接涉及到换本付息计划的具体数额，因此需要重新测算，假设这部分我们也已经存在了对应的测算服务 RepayScheduleService：

public interface RepayScheduleService {
    /**
    	通过模型参数和最新的利率测算对应的换本付息计划
    */
    List<RepayRow> calRepaySchedule(ModelParam param, BigDecimal rate);
}

目前这三个服务类都是独立的，在系统的调用端可以组合这三个接口来完成相关数据的测算，但是这可能会比较麻烦，可能大部分的客户端只需要一个直接能够检测浮动利率并完成相关数据测算的接口，因此可以单独将它们组合到一个服务类中，提供统一的方法：

public interface FloatRateService {
    void floatRateCalcluate();
}

这样客户端就只需要直接访问 FloatRateService 而不需要访问其它的子服务类，降低了系统中服务调用的难度

总结

一般来讲，“外观模式” 的主要作用在于简化接口，降低系统的耦合性

参考：

^[1] 《设计模式—可复用面向对象基础》