外观设计模式Facade Pattern：我要面对全世界的复杂，只是为你简单

外观模式Facade Pattern，有时又译为门面模式，这是开发人员的经常运用的一种设计模式，在服务器端的开发我们通常都会采用一个MVC类型的框架的来辅助开发，比如Spring MVC、Struts2等。前端开发人员只需要关注服务端提供的接口，而无需进一步了解接口内部如何去做子系统之间的协调及调用。

外观模式要解决的问题就是让客户端对各个子系统的调用变得简单。下图是《设计模式》上的一个的插图，Facade将众多复杂的子系统对Client屏蔽开来，Client只需要关注Facade提供的一个简单接口即可。

外观模式实践了最小知识原则，客户端只需要关注对外的一个外观接口即可，无需关注内部实现的复杂度。但们模式也有其缺点，因为外观接口内部本身是复杂的，是面向特定目的所在的系统整合，往往并不符合开闭原则，没有流程继承重写等机制，所以维护迭代起来比较很麻烦。所以外观接口对于外人使用起来很简单，但也面临着你不要动我的接口的困境。所以对于外观接口内的实现，请务必适当控制复杂度，不能完全因为对外的简单而忽略了可维护性，而可维护性势必会把复杂度向外推送，这之间需要做很多平衡取舍（沟通！）。

尽管上面已经把外观模式的概念、应用场景、优缺点都讲到了，我们还是以一个代码实例来做结尾。
假设我们有3个子系统：
三角形系统Triangle，提供drawCircle()方法绘制三角形
方形系统Rectangle，提供drawRetangle()方法绘制方形
圆形系统Circle，提供drawTriangle()方法绘制圆形
我们要绘制一座房子，并不需要分别调用3个子系统的接口来分别绘制3中形状来组合成一房子，而是直接外观类House的drawHouse()方法来直接盖一座房子出来

输出结果：
A circle draws
A rectangle draws
A triangle draws

可以看到我们只需调用house.drawHouse()就可以完成房子的绘制，实际上要绘制一座房子，要比我们的示例实现代码要复杂的多，比如调整各个形状的位置、大小、颜色等，而FacadeDemo并需要知道这些，一个接口调用全部搞定了。

————————————————
版权声明：本文为CSDN博主「请给我一根烟的时间」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/mytream/article/details/125023338