外观模式又叫门面模式？

定义

又叫门面模式，提供了一个统一的接口，用来访问系统中的一群接口
外观模式定义了一个高层的接口，让子系统更容易使用

类型

结构型

使用场景

子系统越来越复杂，增加外观模式提供简单调用接口
构建多层系统结构，利用外观对象作为每层的入口，简化层间调用

优点

简化了调用过程，无须了解深入子系统，防止带来风险
减少系统依赖、松散耦合
更好的划分访问层次
符合迪米特法则，即最少知道原则

缺点

增加子系统、扩展子系统行为容易引入风险
不符合开闭原则

coding

迪米特原则是最少知道原则，外观模式是迪米特法则的非常典型的例子，降低我们应用层client和子系统之间的耦合度。
我们看一下积分兑换礼物的功能代码
积分礼物

/*** 积分礼物**/
public class PointGift {private String name;public PointGift(String name) {this.name = name;}public String getName() {return name;}public void setName(String name) {this.name = name;}
}

礼物兑换校验子系统

/*** 礼物兑换校验子系统**/
public class QualifyService {public boolean isAvailable(PointGift pointGift){System.out.println("校验"+pointGift.getName()+" 积分资格通过，库存通过");return true;}
}

积分支付的系统

/*** 积分支付的系统**/
public class PointPaymentService {public boolean pay(PointGift pointGift){//扣减积分System.out.println("支付"+pointGift.getName()+" 积分成功");return true;}
}

物流系统

/*** 物流系统**/
public class ShippingService {/*** 返回物流单号* @param pointGift* @return*/public String shipGift(PointGift pointGift){//物流系统的对接逻辑System.out.println(pointGift.getName()+"进入物流系统");String shippingOrderNo="666";return shippingOrderNo;}
}

现在三个子系统礼物兑换校验子系统、积分支付的系统、物流系统都已经有了，我们应用层在对接的时候我要关注这3个子系统，要挨个进行交互，首先交互资格校验、然后支付积分、最后调用物流系统运输礼物。例如说说一旦服务拆分后，作为rpc服务，对外提供这3个接口，要求对接者来实现这3个接口，同时还要保证他们的顺序，包括怎么使用都要写一个说明，那其实对方只关心的是礼物兑换逻辑，这3个服务呢完全可以封装到内部，对外只提供一个外观类，对方不需要知道这么多子系统，包括他们之间什么顺序，里面什么逻辑，这些子系统的逻辑都不需要知道。其实可以想想迪米特法则，对方不需要知道的都不知道，那外观模式可以很好的体现迪米特法则，不该知道的就不知道。
我们现在需要应用层知道什么呢？

礼物兑换的服务

/*** 礼物兑换的服务**/
public class GiftExchangeService {//注入服务private QualifyService qualifyService;private PointPaymentService pointPaymentService;private ShippingService shippingService;//注入public void setQualifyService(QualifyService qualifyService) {this.qualifyService = qualifyService;}public void setPointPaymentService(PointPaymentService pointPaymentService) {this.pointPaymentService = pointPaymentService;}public void setShippingService(ShippingService shippingService) {this.shippingService = shippingService;}/*** 礼物兑换* @param pointGift*/public void giftExchange(PointGift pointGift){if(qualifyService.isAvailable(pointGift)){//资格校验通过if(pointPaymentService.pay(pointGift)){//如果积分支付成功String ShippingOrderNo= shippingService.shipGift(pointGift);System.out.println("物流系统下单成功，订单号是："+ShippingOrderNo);}}}
}

看下类图

看到一个礼物兑换的外观类对外提供一个giftExchange方法，下面有3个子系统，分别是资格校验、物流、支付，并且是1:1的菱形关系，也即是组合关系，对外只和外观类交互，所有的子系统是不需要关心的，这个图就很好诠释了外观类的UML类图

应用层

public class Test {public static void main(String[] args) {PointGift pointGift=new PointGift("T恤");GiftExchangeService giftExchangeService=new GiftExchangeService();//注入giftExchangeService.setQualifyService(new QualifyService());giftExchangeService.setPointPaymentService(new PointPaymentService());giftExchangeService.setShippingService(new ShippingService());giftExchangeService.giftExchange(pointGift);}
}

运行结果

校验T恤 积分资格通过，库存通过
支付T恤 积分成功
T恤进入物流系统
物流系统下单成功，订单号是：666

运行结果没有问题，再看下现在的类图

看类图，Test是不需要关心子系统的，可是上图中和子系统发生关系了，Test创建了子系统，那实际在使用的时候只要保证Test和外观类这条黄线就是ok的，但是这里面为什么还有线呢？因为在Test里我们通过new来创建了子系统，现在我们更符合实际一点，假设外观类里的子系统已经通过spring注入了

/*** 礼物兑换的服务**/
public class GiftExchangeService {//注入服务private QualifyService qualifyService=new QualifyService();private PointPaymentService pointPaymentService=new PointPaymentService();private ShippingService shippingService=new ShippingService();/*** 礼物兑换* @param pointGift*/public void giftExchange(PointGift pointGift){if(qualifyService.isAvailable(pointGift)){//资格校验通过if(pointPaymentService.pay(pointGift)){//如果积分支付成功String ShippingOrderNo= shippingService.shipGift(pointGift);System.out.println("物流系统下单成功，订单号是："+ShippingOrderNo);}}}
}

应用层

public class Test {public static void main(String[] args) {PointGift pointGift=new PointGift("T恤");GiftExchangeService giftExchangeService=new GiftExchangeService();giftExchangeService.giftExchange(pointGift);}
}

运行结果肯定还是一样的，我们再看看uml类图

看到Test和子系统的关系已经消失了，子系统只和外观类通信，应用层只和外观类通信。所以我们日常在开发工作的时候，也要注意我们应用层到底和没和子系统发生关系，这里也是检验外观模式使用正确与否的一个因素。
上面的示例中，我们使用的是实体外观类，在UML类图中也看到，它完美的支持了迪米特法则，但是新增一个子系统的话，我们还要修改实体外观类，从这个角度出发，这并不符合开闭原则，再扩展下，如果我们这个外观类使用抽象外观类的话，也就是说我们上面还有个接口外观类，通过这个外观类来实现上面的抽象外观接口，这也是一个扩展的方式。但是具体我们是使用实体外观类还是抽象外观外观类来实现业务场景呢？还是要看具体的业务场景要求，和对它扩展的一个预期，如果这个外观类不需要经常变化，或者以后的业务扩展非常有限的话，我们直接使用实体外观类也是可以的，可以减少复杂度；那如果预期每一两周就要新增一个子系统，那我们就要使用抽象外观类了。

例如说下面uml中有个抽象外观类的实现类，在左边又一个抽象外观类的实现类，如果左边的实现变化比较大的话，再通过应用层Test关联左边的框，即使用新的抽象外观类的实现类，这样右边老的是不需要变化的，对于版本控制，例如说一个app不同的版本，里面的逻辑可能是不一样的，在版本控制上也可以找到使用的场景，打个比方我们可以通过app获取具体使用的版本，然后调用对应版本的外观类实现。

源码解析

spring-jdbc中的JdbcUtils

closeConnection对Connection 做了封装

public static void closeConnection(Connection con) {if (con != null) {try {con.close();}catch (SQLException ex) {logger.debug("Could not close JDBC Connection", ex);}catch (Throwable ex) {// We don't trust the JDBC driver: It might throw RuntimeException or Error.logger.debug("Unexpected exception on closing JDBC Connection", ex);}}}

public static void closeStatement(Statement stmt) {if (stmt != null) {try {stmt.close();}catch (SQLException ex) {logger.trace("Could not close JDBC Statement", ex);}catch (Throwable ex) {// We don't trust the JDBC driver: It might throw RuntimeException or Error.logger.trace("Unexpected exception on closing JDBC Statement", ex);}}}

public static void closeResultSet(ResultSet rs) {if (rs != null) {try {rs.close();}catch (SQLException ex) {logger.trace("Could not close JDBC ResultSet", ex);}catch (Throwable ex) {// We don't trust the JDBC driver: It might throw RuntimeException or Error.logger.trace("Unexpected exception on closing JDBC ResultSet", ex);}}}

public static Object getResultSetValue(ResultSet rs, int index) throws SQLException {。。。

public static Object extractDatabaseMetaData(DataSource dataSource, DatabaseMetaDataCallback action)throws MetaDataAccessException {。。。

mybatis中的configuration

public MetaObject newMetaObject(Object object) {return MetaObject.forObject(object, this.objectFactory, this.objectWrapperFactory, this.reflectorFactory);}

public ParameterHandler newParameterHandler(MappedStatement mappedStatement, Object parameterObject, BoundSql boundSql) {ParameterHandler parameterHandler = mappedStatement.getLang().createParameterHandler(mappedStatement, parameterObject, boundSql);parameterHandler = (ParameterHandler)this.interceptorChain.pluginAll(parameterHandler);return parameterHandler;}

tomcat源码中RequestFacade

看名字就知道是一个Request的外观类，正是一个HttpServletRequest的外观类

public class RequestFacade implements HttpServletRequest {。。。

里面封装了很多方法，有像我们熟悉的getParameter等等。再来看看Request对象

package org.apache.catalina.connector;public class Requestimplements HttpServletRequest {。。。

那Request和RequestFacade是什么关系呢？它们两个都实现了HttpServletRequest接口，并且Request里有Facade，里面操作都是通过Facade来操作的

 /*** The facade associated with this request.*/protected RequestFacade facade = null;/*** Return the <code>ServletRequest</code> for which this object* is the facade.  This method must be implemented by a subclass.*/public HttpServletRequest getRequest() {if (facade == null) {facade = new RequestFacade(this);}return facade;}

tomcat中的ResponseFacade

跟RequestFacade一样

tomcat中的StandardSessionFacade

是处理Session的外观类

public class StandardSessionFacadeimplements HttpSession {

tomcat还有很多都是使用外观模式的，我们可以搜facade