设计模式之 外观模式

 

外观模式（Facade Pattern）隐藏系统的复杂性，并向客户端提供了一个客户端可以访问系统的接口。

这种类型的设计模式属于结构型模式，它向现有的系统添加一个接口，来隐藏系统的复杂性。

 

主要解决：降低访问复杂系统的内部子系统时的复杂度，简化客户端与之的接口。

使用场景： 1、客户端不需要知道系统内部的复杂联系，整个系统只需提供一个"接待员"即可。 2、定义系统的入口。

解决方法：客户端不与系统耦合，外观类与系统耦合。

 

应用实例： 

　　1、去医院看病，可能要去挂号、门诊、划价、取药，让患者或患者家属觉得很复杂，如果有提供接待人员，只让接待人员来处理，就很方便 。

　　2、JAVA 的三层开发模式MVC 。

 

结合实际理解：

　　对于面向对象有一定基础，即使没有听说过外观模式，也完全有可能在很多时候使用它；比如java web开发的项目中有很多的service和dao，这一层service有一个非常重要的作用，就是为了方便我们管理项目中与业务逻辑相关的事物，service层同时也是组合dao层暴露给controller层或action层的功能；外观模式还完美地体现了依赖倒转原则和迪米特法则的思想，所以是很常用的模式之一。 

 

一个形象的例子：

　　电脑整机是 CPU、内存、硬盘的外观。

　　有了外观以后，启动电脑和关闭电脑都简化了。

　　直接 new 一个电脑。

　　在 new 电脑的同时把 cpu、内存、硬盘都初始化好并且接好线。

　　对外暴露方法（启动电脑，关闭电脑）。

　　启动电脑（按一下电源键）：启动CPU、启动内存、启动硬盘

　　关闭电脑（按一下电源键）：关闭硬盘、关闭内存、关闭CPU

 

 

优点： 

　　1、减少系统间的相互依赖，实现松耦合。

　　2、提高灵活性。（在维护一个遗留的大型系统时，可能这个系统已经非常难以维护和扩展了，这时候如果有新系统必需依赖于它就可以为新系统开发一个外观类，为高度复杂的遗留代码提供比较清晰的接口，让新系统与外观类交互，外观类与遗留代码交互所有复杂工作。）

　　3、降低了大型软件系统中的编译依赖性，并简化了系统在不同平台之间的移植过程。

缺点：

　　1、不符合开闭原则，如果要修改某一个子系统的功能，通常外观类也要一起修改。（在不引入外观类的情况下，增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。）

　　2、不能很好地限制客户使用子系统，如果对客户访问子系统类做太多限制减少了可变性和灵活性。没有办法直接阻止外部不通过外观类访问子系统的功能，因为子系统类中的功能必须是公开的（根据需要决定是否使用 internal 访问级别可解决这个缺点，但外观类需要和子系统类在同一个程序集内）。

 

 

共同学习，共同进步，若有补充，欢迎指出，谢谢！