之前在自己写的博客《归一化、CDN容错与异常监控》中，有提到一个归一化的概念，当时那是我胡乱总结的，毕竟语文学的不咋地。今天我猛的发现，原来他是有个高大上的名字的，就是门面模式，又称外观模式，原来自己的一点小思考，早就有人替你想到了，而且还取了个厉害的名字。哈哈
阿里规范
之前时间阿里开源的《阿里巴巴Java开发手册》中有一条，内容如下
【强制】应用中不可直接使用日志系统（Log4j、Logback）中的API，而应依赖使用日志框架SLF4J中的API，使用门面模式的日志框架，有利于维护和各个类的日志处理方式统一
有没有思考过，为何规范要这么规定呢？我现在发现，其实和我提到的归一化概念是一样的。
简单来说就是为了减少日后提后替换日志系统的成本。
定义：门面模式（Facade Pattern），也称之为外观模式，其核心为：外部与一个子系统的通信必须通过一个统一的外观对象进行，使得子系统更易于使用。
如果直接使用日志框架， 而不做一层抽象，由于每一种日志框架都有自己单独的API，要使用对应的框架就要使用其对应的API，这就大大的增加应用程序代码对于日志框架的耦合性。
为了解决这个问题，就是在日志框架和应用程序之间架设一个沟通的桥梁，对于应用程序来说，无论底层的日志框架如何变，都不需要有任何感知。只要门面服务做的足够好，随意换另外一个日志框架，应用程序不需要修改任意一行代码，就可以直接上线。
在软件开发领域有这样一句话：计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决。而门面模式就是对于这句话的典型实践。
映射前端
正如我之前文章中提到的，前端框架不再是大而全的，而是专注于小而精，npm包管理器的出现也是为了帮助我们更好的管理各种各样的包。
如果直接将世面上的库应用到项目中，就会造成项目高度耦合，如果日后这个库有 bug 且不再被维护，或者有更好的替代库可以选择，如果项目中多处直接使用到，日后更换成本就会被加大。
因此我觉得外观模式是很好的实践，在项目中如果需要引入社区资源，强烈建议加一个抽象层，屏蔽底层代码，提供统一的对外输出。比如 axios 等 ajax 库，又或者日历插件等。