原创

设计模式基础(九)——门面模式

门面模式(Facade Design Pattern),也叫外观模式,是一种结构型模式。门面模式为子系统提供一组统一的接口,定义一组高层接口让子系统更易用。

假设有一个系统 A,提供了 a、b、c、d 四个接口。系统 B 完成某个业务功能,需要调用 A 系统的 a、b、d 接口。利用门面模式,我们提供一个包裹 a、b、d 接口调用的门面接口 x,给系统 B 直接使用。

一、应用场景

在 GoF 给出的定义中提到,“门面模式让子系统更加易用”,实际上,它除了解决易用性问题之外,还能解决其他很多方面的问题。

1.1 解决易用性问题

门面模式可以用来封装系统的底层实现,隐藏系统的复杂性,提供一组更加简单易用、更高层的接口。实际上,从隐藏实现复杂性,提供更易用接口这个意图来看,门面模式有点类似于面向对象编程思想中的迪米特法则(最少知识原则)和接口隔离原则:两个有交互的系统,只暴露有限的必要的接口。

1.2 解决性能问题

利用门面模式,我们可以将多个接口调用替换为一个门面接口调用,减少网络通信成本,提高 App 客户端的响应速度。那么,从代码实现的角度来看,该如何组织门面接口和非门面接口?

如果门面接口不多,我们完全可以将它跟非门面接口放到一块,也不需要特殊标记,当作普通接口来用即可。如果门面接口很多,我们可以在已有的接口之上,再重新抽象出一层,专门放置门面接口,从类、包的命名上跟原来的接口层做区分。如果门面接口特别多,并且很多都是跨多个子系统的,我们可以将门面接口放到一个新的子系统中。

二、总结

门面模式,其实没什么特别好说的。我们在进行系统的接口设计时,要控制接口的粒度,太大会导致接口不可复用,太小会导致接口不易用。在实际的开发中,接口的可复用性和易用性需要“微妙”的权衡。针对这个问题,我的一个基本的处理原则是:尽量保持接口的可复用性,但针对特殊情况,允许提供冗余的门面接口,来提供更易用的接口。

另外,门面模式与适配器模式有些相像,但是适配器模式是做接口转换,解决的是原接口和目标接口不匹配的问题而门面模式则做接口整合,解决的是多接口调用带来的问题。

正文到此结束
本文目录