设计模式之外观模式-总结
在上一篇中，我们模拟家庭影院项目实现了外观模式讲解。本篇我们对外观模式进行总结。
来源：凯哥Java(kaigejava).本文由凯哥《23设计模》系列中的一篇。
凯哥突然感觉，使用家庭影院这个例子不恰当。换个通俗易懂的。去银行存取钱。这个案例大家都遇到过吧。
我们去银行后，每个窗口都有个漂亮的为各位服务。在我们存取钱的过程中，只需要和窗口沟通就可以了。我们把IDcard给、输入密码然后就会给你需要取得钱。我们来分析这个过程。
存取钱用户相对于银行系统来说，是外部人员(系统)，窗口服务员就是银行对外提供得一个交互窗口。我们把需要得IDCard、银行卡、密码输入之后，窗口服务员就会给我们打印收据、取钱、请领导签字(如果取钱额度较大得话)等等操作，窗口服务员都帮我们处理完了。最后，我们返回给我们得是我们需要取得现金或者存得凭证。
我们来分析角色：
外部调用系统(或者客户端)：如使用遥控器控制影院得人或去银行存取钱得我们
复杂系统：如影院相关得或者银行系统
在复杂系统中，内部子系统：
银行例子中的：验钞机、打印机、保险箱、银行领导等。
我们为什么要使用外观模式？能解决什么问题？
降低了访问复杂系统的内部的复杂联系。
如何理解这句话？
去银行取钱，如果没有窗口服务，我们需要自己数钱、自己找打印机、自己找银行领导签字等等。是不是很麻烦。有了窗口服务员，我们自需要和服务员交换，其他都不用关了。
所以，我们可以得到外观模式的关键代码在于：当客户端和复杂系统之间进行交换的时候，在两者之间在封装添加一层，这一层的作用就是将调用顺序、依赖关系等等都处理好的。
优点：
减少了系统之间的相互依赖关系、提高了系统的灵活性、提高了系统的安全性(想想如果去银行取钱，让你自己从保险柜中拿钱这感觉~)；
客户端不之间和复杂系统耦合，使用外观类和系统进行耦合，降低了耦合性；
预防低水平的开发人员带来的风险
缺点：
不符合软件设计的开闭原则，如果，需要修改东西，就要修改对外的窗口，很麻烦，继承重写都是不合适的。
使用场景：
为一个复杂的模块或者是子系统提供外界访问的模块；
子系统相对独立的
外观模式的目的：
为子系统中的一组接口或者一组功能提供一个一致的接口(界面)，外管模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
本文来源：凯哥Java(kaigejava)
凯哥个人博客：www.kaigejava.com
本文地址：http://kaigejava.com/gwjeesns/article/edit/567
应用实例：
如果家庭影院以及银行取钱例子还不好理解。那么最简单的，JAVA中三层开发模式(MVC)就是典型的外观模式。这下是不是就好理解了.
标签：总结,外观,窗口,银行,系统,模式,设计模式,我们 来源： https://blog.51cto.com/kaigejava/2435321
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。