门面设计模式在 Tomcat 中有多处使用，在 Request 和 Response 对象封装中、Standard Wrapper 到 ServletConfig 封装中、ApplicationContext 到 ServletContext 封装中等都用到了这种设计模式。
今天我们来聊两个设计模式：调停者设计模式和门面设计模式，为什么要将他们放在一起讲解，因为他们两个东东太像了，仅仅是由于作用的地方不同而产生的不同的叫法。
门面设计模式在 Tomcat中有多处使用，在 Request 和 Response 对象封装中Standard Wrapper 到 ServletConfig 封装中、ApplicationContext 到 ServletContext 封装中等都用到了这种设计模式
在一文了解MVI架构，学起来吧~这篇文章的最后，我们提到了对网域层的理解类似于门面模式，所以这里单独写一篇文章介绍一下门面模式。
门面设计模式又叫外观设计模式，其核心思想正如其字面意思，向用户提供一个门户，用户只需要访问这个门户来获取他们想要的数据，无需管理这个门户内部的构成，也无需知道里面的运行流程等等，对于开发者来说，使用门面模式，我们可以只向用户提供他们想要的东西，而不要暴露所有的信息。
上一次分享了一篇好文：《为什么阿里巴巴禁止工程师直接使用日志系统(Log4j、Logback)中的 API》
设计模式（Design Pattern）是一套被反复使用、多数人知晓的、经过分类的、代码设计经验的总结。使用设计模式的目的：为了代码可重用性、让代码更容易被他人理解、保证代码可靠性。设计模式使代码编写真正工程化；设计模式是软件工程的基石脉络，如同大厦的结构一样。
门面模式，也叫外观模式，英文全称是 Facade Design Pattern。在 GoF 的《设计模式》一书中，门面模式是这样定义的：
门面模式也叫外观模式，是一种结构型设计模式，能为程序库、框架或其他复杂类提供一个简单的接口。
什么是“门面”？门面就是让你一看就知道里面可以提供什么东西，但是你又不会知道它是如何提供的。 门面模式是什么？
什么是“门面”？门面就是让你一看就知道里面可以提供什么东西，但是你又不会知道它是如何提供的。
门面设计模式是面向对象设计模式中的一种，日志框架采用的就是这种模式，类似 JDBC 的设计理念。它只提供一套接口规范，自身不负责日志功能的实现，目的是让使用者不需要关注底层具体是哪个日志库来负责日志打印及具体的使用细节等。目前用得最为广泛的日志门面有两种：slf4j 和 commons-logging。
打个还算比较形象的比喻吧，我们把门面比作建筑工地上的建筑物的表面，可以是贴有横幅，如：XXXX铁路工程局，这种比较醒目的一面，能更吸引人注意力，当人们从建筑物旁边经过时，可以看到其外部的面貌，此时并不了解其本身结构的复杂性。 在程序里门面在隐藏内部复杂性的同时，也为外部客户端提供了一个可以轻松访问的接口。
Design Patterns: Elements of Reusable Object-Oriented Software（以下简称《设计模式》），一书由Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides合著（Addison-Wesley，1995）。这四位作者常被称为“四人组（Gang of Four）”，而这本书也就被称为“四人组（或 GoF）”书。他们首次给我们总结出一套软件开发可以反复使用的经验，帮助我们提高代码的可重用性、系统的可维护性等，解决软件开发中的复杂问题。
这次要介绍的是外观模式（也称为门面模式），外观模式也属于结构型模式，其实外观模式还是非常好理解的，简单的来讲就是将多个复杂的业务封装成一个方法，在调用此方法时可以不必关系具体执行了哪些业务，而只关心结果即可。这个场景其实在日常开发中使用的频率还是非常高的，下面来简单了解一下吧。
在之前我们的设计模式相关的系列文章中，已经学习过了门面模式。在设计模式中，门面模式的定义是：为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。当时我们也实现了自己的设计模式，不记得的小伙伴欢迎移步 PHP设计模式-门面模式https://mp.weixin.qq.com/s/RzCoM96XnlT610q4AiuAVA 再复习复习。
此处主要讲解常见的是：单例、工厂方法（及 变式：工厂方法模式、抽象工厂模式）、建造者模式。
所谓设计模式，就是一套被反复使用的代码设计经验的总结（情境中一个问题经过证实的一个解决方案）。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。设计模式使人们可以更加简单方便的复用成功的设计和体系结构。将已证实的技术表述成设计模式也会使新系统开发者更加容易理解其设计思路。 在GoF的《Design Patterns: Elements of Reusable Object-Oriented Software》中给出了三类（创建型[对类的实例化过程的抽象化]、结构型[描述如何将类或对象结合在一起形成更大的结构]、行为型[对在不同的对象之间划分责任和算法的抽象化]）共23种设计模式，包括：Abstract Factory（抽象工厂模式），Builder（建造者模式），Factory Method（工厂方法模式），Prototype（原始模型模式），Singleton（单例模式）；Facade（门面模式），Adapter（适配器模式），Bridge（桥梁模式），Composite（合成模式），Decorator（装饰模式），Flyweight（享元模式），Proxy（代理模式）；Command（命令模式），Interpreter（解释器模式），Visitor（访问者模式），Iterator（迭代子模式），Mediator（调停者模式），Memento（备忘录模式），Observer（观察者模式），State（状态模式），Strategy（策略模式），Template Method（模板方法模式）， Chain Of Responsibility（责任链模式）。 面试被问到关于设计模式的知识时，可以拣最常用的作答，例如：
代码也写了几年了，设计模式处于看了忘，忘了看的状态，最近对设计模式有了点感觉，索性就再学习总结下吧。
上述A方案的问题在于组件的客户和组件中各种复杂的子系统有了过多的耦合,随着外部客户程序和各子系统的演化.这种过多的耦合面临很多变化的挑战
今天我们继续来学习前面没有学完的结构型设计模式中的一种：门面模式。门面模式也是一种不太常用的设计模式。所以，我们今天依旧是了解为主，暂时不去深入的学习。
在生活中，我们也能感受的门面模式的影子。比如在医院有接待员帮助病人完成门诊、挂号、付费以及取药，病人只接触接待员即可，由接待员负责与医院的各个部门打交道。
设计模式正是为了解决这些反复出现的问题而产生的。因此，你所要做的就是根据你的框架和语言实现特定的模式就可以了！
外观模式也叫门面模式，是开发过程中使用频率非常高的一种设计模式，但非常容易理解。
在 Java 开发中，设计模式是一种十分常见的编程思想，它可以帮助我们解决很多实际开发中的问题。本篇文章将介绍一种常见的设计模式——外观模式，并结合实际的开发场景进行讲解。本文将以 SpringBoot 开发门面模式中间件，实现一个统一控制接口白名单的场景来展示外观模式的应用。
肥朝小声逼逼：这个模式，其实我们每天都在用到，但是你可能却浑然不知。只要你用到面向接口编程，其实都是在用桥接模式。
比如用户是用电脑，电脑有操作：开机关机重启等。每个操作里都有复杂的逻辑，比如开始需要先启动BIOS-引导硬盘—进入系统-初始化桌面等。对于使用者来说，只需要调用开机的方法。
写完项目之后，再来看这个设计模式，就会觉得前面写的那些代码好垃圾啊，不知道是谁写出来的。 设计模式并不是书上那简单的23种，在真实的应用场景中可能会有不同的变种，以及多种模式的嵌套。 书上那些模式也有不少是互相变种出来的，所以我们重在思想，不要流于表面。
面对复杂的业务场景，千变万化的客户需求，如何以一变应万变，以最小的开发成本快速落地实现，同时保证系统有着较低的复杂度，能够保证系统后续de持续迭代能力，让系统拥有较高的可扩展性。
在我做第一个后端项目的时候，是老师给我们的框架，我又自己找学长拿了他的项目，两者框架差不多，看样子是没怎么改了。
Facade，中文术语叫「外观模式」，也叫「门面模式」。在经典设计模式中，归为结构型（Structural）模式分类，因为这种模式用于帮助构建结构。它可以为程序库、框架或其他复杂情况提供一个简单的接口。
本文先给个例子让你看懂了这个设计模式的概念，再分析这个这设计模式的优点，最后再具体的去看看实现方式。 1.一个例子来让你理解门面设计模式概念 最直观的需求是，有多个病人，病人直接挂号、划价、缴费、取药等。
为了更好的学习设计模式，以及督促自己完成设计模式的学习，现提笔为记。 怎么的，每周至少也要学一个设计模式！！！ 恳请大家的监督和不吝赐教，共同学习和进步！ 内容主要参考自《设计模式之禅》以及相关网络博文！ 源码路径：源代码C# GitHub 目录 想学设计模式，你得先会看类图，一张图读懂UML 大致了解下都有哪些设计模式 我是独一无二的『单例模式』 创建相似对象，就交给『工厂模式』吧 固定模板，不同算法，就用『模板方法模式』 关注产出，不关心细节，『建造者模式』 重复构造，打出原形，
适配器模式的作用是让原本不兼容的接口适配成可以一起使用的接口，比如我们生活中的USB转接头。
世界上到处都有这种模式，烹饪、艺术馆、医药、法律、数学、音乐、舞蹈等等领域。 一般来说，模式是为解决一般性经常发生类似的问题而提出的解决方案，简单来说就是一种解决方案的轮廓，但是又不仅仅于此。 用更正式的话来说，模式是对重复出现的问题的可重用解决方案的概括总览。
子类对象能够替换程序中父类对象出现的任何地方，并且保证原来程序的逻辑行为不变及正确性不被破坏。
外观模式（Facade Pattern），又称为门面模式，是 GoF 的 23 种设计模式中的一种结构型设计模式。
从前，有一个书生，去到很远的地方读书。离开家里久了，难免会思念家乡，于是他便带着书童收拾好行囊，来到城门口登记 —— 接收包裹检查 —— 赶路 —— 到家。几次折腾之后，书生的成绩下滑了，身体也吃不消了，家里觉得这也不是一个长期的办法，于是商量出来一个办法：想家的时候，他便写一封家书，叫自己的书童给他带到老父亲家里。这样一来，书童便拿着他的家书，在城门口进行登记、检查包裹、然后出了城赶路。这使得书生可以专心读书，传递家书的事情，都由书童来做。
外观模式提供了一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用。
设计模式作为我们程序员必备的基本功，由此，很多人也很纳闷，到底什么时候开始学设计模式？工作三年后？工作一年后？工作之前？
门面模式又叫外观模式，这个设计模式也比较简单，比较容易理解，其实在我们正常编码中就已经写出了门面模式，但是我们并不知道这个写法是叫门面模式。
Facade Design Pattern，也叫外观模式，在GoF的《设计模式》中定义：
本小节我们要学习的设计模式叫做外观模式，也叫做门面模式 Facade。想象一下，我们系统随着时间的推移，系统复杂性、类之间的相互调用会变得越来越多，相比较客户角度而言，客户往往关注的是某个单一接口 API，而不会关心该 API 内部的复杂性或者内部子系统是如何运作的。
文章会逐步更新于我的各个博客上（见文章尾部介绍），也希望各位观众老爷能够关注我的个人公众号：后端技术漫谈，所有文章都会在上面发布，不会错过精彩好看的文章。
GoF的设计模式一共23个，可以分为3大类：创建型、结构型和行为型，这篇文章主要讨论创建型。
外观模式（Facade）,他隐藏了系统的复杂性，并向客户端提供了一个可以访问系统的接口。这种类型的设计模式属于结构性模式。为子系统中的一组接口提供了一个统一的访问接口，这个接口使得子系统更容易被访问或者使用。类似的实际例子有消息中间件，把一个数据丢到消息中间件，谁需要，谁去消息后中间件去拿。这种设计模式可以用于解耦。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
