外观模式 - 结构型模式
来源:互联网 发布:大数据主要应用领域 编辑:程序博客网 时间:2024/05/17 14:18
个人理解:
模式类型:
Facade 外观模式 - 结构型模式,也称之为门面模式。
在软件开发系统中,客户程序经常会与复杂系统的内部子系统之间产生耦合,而导致客户程序随着子系统的变化而变化。那么如何简化客户程序与子系统之间的交互接口?如何将复杂系统的内部子系统与客户程序之间的依赖解耦?
外观模式中,一个子系统的外部与其内部的通信通过一个统一的外观类进行,外观类将客户类与子系统的内部复杂性分隔开,使得客户类只需要与外观角色打交道,而不需要与子系统内部的很多对象打交道。
引入一个抽象外观类,客户端针对抽象外观类编程,而在运行时再确定具体外观类
Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.
角色:
(1) Facade(外观角色):在客户端可以调用它的方法,在外观角色中可以知道相关的(一个或者多个)子系统的功能和责任;在正常情况下,它将所有从客户端发来的请求委派到相应的子系统去,传递给相应的子系统对象处理。
(2) SubSystem(子系统角色):在软件系统中可以有一个或者多个子系统角色,每一个子系统可以不是一个单独的类,而是一个类的集合,它实现子系统的功能;每一个子系统都可以被客户端直接调用,或者被外观角色调用,它处理由外观类传过来的请求;子系统并不知道外观的存在,对于子系统而言,外观角色仅仅是另外一个客户端而已。
模式的应用场景:
1 .为一个复杂子系统提供一个简单接口。
2 .提高子系统的独立性。
3 .在层次化结构中,可以使用 Facade 模式定义系统中每一层的入口。
结构图:
模式的优缺点:
外观模式的主要优点如下:
(1) 它对客户端屏蔽了子系统组件,减少了客户端所需处理的对象数目,并使得子系统使用起来更加容易。通过引入外观模式,客户端代码将变得很简单,与之关联的对象也很少。
(2) 它实现了子系统与客户端之间的松耦合关系,这使得子系统的变化不会影响到调用它的客户端,只需要调整外观类即可。
(3) 一个子系统的修改对其他子系统没有任何影响,而且子系统内部变化也不会影响到外观对象。
外观模式的主要缺点如下:
(1) 不能很好地限制客户端直接使用子系统类,如果对客户端访问子系统类做太多的限制则减少了可变性和灵活 性。
(2) 如果设计不当,增加新的子系统可能需要修改外观类的源代码,违背了开闭原则。
模式的应用实例:
模式比较:
注意区分Facade模式、Adapter模式、Bridge模式与Decorator模式。Facade模式注重简化接口,Adapter模式注重转换 接口,Bridge模式注重分离接口(抽象)与其实现,Decorator模式注重稳定接口的前提下为对象扩展功能。
要点:
从客户程序的角度来看,Facade模式不仅简化了整个组件系统的接口,同时对于组件内部与外部客户程序来说,从某种程度上也达到了一种“解耦”的效果----内部子系统的任何变化不会影响到Facade接口的变化。
Facade设计模式更注重从架构的层次去看整个系统,而不是单个类的层次。Facdae很多时候更是一种架构。
外观模式的主要目的在于降低系统的复杂程度,在面向对象软件系统中,类与类之间的关系越多,不能表示系统设计得越好,反而表示系统中类之间的耦合度太大,这样的系统在维护和修改时都缺乏灵活性,因为一个类的改动会导致多个类发生变化,而外观模式的引入在很大程度上降低了类与类之间的耦合关系。引入外观模式之后,增加新的子系统或者移除子系统都非常方便,客户类无须进行修改(或者极少的修改),只需要在外观类中增加或移除对子系统的引用即可。从这一点来说,外观模式在一定程度上并不符合开闭原则,增加新的子系统需要对原有系统进行一定的修改,虽然这个修改工作量不大。
外观模式中所指的子系统是一个广义的概念,它可以是一个类、一个功能模块、系统的一个组成部分或者一个完整的系统。子系统类通常是一些业务类,实现了一些具体的、独立的业务功能。
代码(其实读UML图要比代码还要一目了然):
参考/转自:
http://blog.csdn.net/lovelion/article/details/8258121
http://blog.csdn.net/lovelion/article/details/8259789
http://blog.csdn.net/cjjky/article/details/7570632
http://sourcemaking.com/design_patterns/fa%C3%A7ade
转载请注明:http://blog.csdn.net/paincupid/article/details/44164411
模式类型:
Facade 外观模式 - 结构型模式,也称之为门面模式。
意图(Motivate):
为子系统中的一组接口提供一个一致的接口, Facade模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。
Provide a unified interface to a set of interface in a subsystem.Facade defines a higher-lever interface that make the subsystem easier to use.
在软件开发系统中,客户程序经常会与复杂系统的内部子系统之间产生耦合,而导致客户程序随着子系统的变化而变化。那么如何简化客户程序与子系统之间的交互接口?如何将复杂系统的内部子系统与客户程序之间的依赖解耦?
外观模式中,一个子系统的外部与其内部的通信通过一个统一的外观类进行,外观类将客户类与子系统的内部复杂性分隔开,使得客户类只需要与外观角色打交道,而不需要与子系统内部的很多对象打交道。
引入一个抽象外观类,客户端针对抽象外观类编程,而在运行时再确定具体外观类
Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.
Wrap a complicated subsystem with a simpler interface.
角色:
(1) Facade(外观角色):在客户端可以调用它的方法,在外观角色中可以知道相关的(一个或者多个)子系统的功能和责任;在正常情况下,它将所有从客户端发来的请求委派到相应的子系统去,传递给相应的子系统对象处理。
(2) SubSystem(子系统角色):在软件系统中可以有一个或者多个子系统角色,每一个子系统可以不是一个单独的类,而是一个类的集合,它实现子系统的功能;每一个子系统都可以被客户端直接调用,或者被外观角色调用,它处理由外观类传过来的请求;子系统并不知道外观的存在,对于子系统而言,外观角色仅仅是另外一个客户端而已。
模式的应用场景:
1 .为一个复杂子系统提供一个简单接口。
2 .提高子系统的独立性。
3 .在层次化结构中,可以使用 Facade 模式定义系统中每一层的入口。
结构图:
模式的优缺点:
外观模式的主要优点如下:
(1) 它对客户端屏蔽了子系统组件,减少了客户端所需处理的对象数目,并使得子系统使用起来更加容易。通过引入外观模式,客户端代码将变得很简单,与之关联的对象也很少。
(2) 它实现了子系统与客户端之间的松耦合关系,这使得子系统的变化不会影响到调用它的客户端,只需要调整外观类即可。
(3) 一个子系统的修改对其他子系统没有任何影响,而且子系统内部变化也不会影响到外观对象。
外观模式的主要缺点如下:
(1) 不能很好地限制客户端直接使用子系统类,如果对客户端访问子系统类做太多的限制则减少了可变性和灵活 性。
(2) 如果设计不当,增加新的子系统可能需要修改外观类的源代码,违背了开闭原则。
模式的应用实例:
模式比较:
注意区分Facade模式、Adapter模式、Bridge模式与Decorator模式。Facade模式注重简化接口,Adapter模式注重转换 接口,Bridge模式注重分离接口(抽象)与其实现,Decorator模式注重稳定接口的前提下为对象扩展功能。
要点:
从客户程序的角度来看,Facade模式不仅简化了整个组件系统的接口,同时对于组件内部与外部客户程序来说,从某种程度上也达到了一种“解耦”的效果----内部子系统的任何变化不会影响到Facade接口的变化。
Facade设计模式更注重从架构的层次去看整个系统,而不是单个类的层次。Facdae很多时候更是一种架构。
外观模式的主要目的在于降低系统的复杂程度,在面向对象软件系统中,类与类之间的关系越多,不能表示系统设计得越好,反而表示系统中类之间的耦合度太大,这样的系统在维护和修改时都缺乏灵活性,因为一个类的改动会导致多个类发生变化,而外观模式的引入在很大程度上降低了类与类之间的耦合关系。引入外观模式之后,增加新的子系统或者移除子系统都非常方便,客户类无须进行修改(或者极少的修改),只需要在外观类中增加或移除对子系统的引用即可。从这一点来说,外观模式在一定程度上并不符合开闭原则,增加新的子系统需要对原有系统进行一定的修改,虽然这个修改工作量不大。
外观模式中所指的子系统是一个广义的概念,它可以是一个类、一个功能模块、系统的一个组成部分或者一个完整的系统。子系统类通常是一些业务类,实现了一些具体的、独立的业务功能。
代码(其实读UML图要比代码还要一目了然):
class SubSystemA { public void MethodA() { //业务实现代码 } } class SubSystemB { public void MethodB() { //业务实现代码 } } class SubSystemC { public void MethodC() { //业务实现代码 } } //在引入外观类之后,与子系统业务类之间的交互统一由外观类来完成,在外观类中通常存在如下代码: class Facade { private SubSystemA obj1 = new SubSystemA(); private SubSystemB obj2 = new SubSystemB(); private SubSystemC obj3 = new SubSystemC(); public void Method() { obj1.MethodA(); obj2.MethodB(); obj3.MethodC(); } } //由于在外观类中维持了对子系统对象的引用,客户端可以通过外观类来间接调用子系统对象的业务方法,而无须与子系统对象直接交互。引入外观类后,客户端代码变得非常简单,典型代码如下: class Program { static void Main(string[] args) { Facade facade = new Facade(); facade.Method(); } }
所有模式:
创建型模式,共五种:工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。
结构型模式,共七种:适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
行为型模式,共十一种:策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
补充模式:空对象模式
参考/转自:
http://blog.csdn.net/lovelion/article/details/8258121
http://blog.csdn.net/lovelion/article/details/8259789
http://blog.csdn.net/cjjky/article/details/7570632
http://sourcemaking.com/design_patterns/fa%C3%A7ade
转载请注明:http://blog.csdn.net/paincupid/article/details/44164411
0 0
- 结构型模式-外观
- 外观模式(结构型)
- 外观模式(结构型)
- 结构型模式-外观模式
- 结构型模式--外观模式
- 外观模式 - 结构型模式
- 结构型模式-外观模式
- 结构型模式--外观模式
- 设计模式 - 结构型模式 - 外观模式
- 【设计模式】- 【结构型模式】外观模式
- 结构模式->外观模式
- 【结构型模式】facade(外观)
- 8-结构型-外观模式
- 结构型之外观模式
- 结构型模式-外观(facade)
- 设计模式-结构型-外观
- 设计模式-结构型模式-外观
- Facade外观模式(结构型模式)
- hdu 2844 多重背包
- 【黑马程序员】关于NSString和NSDictionary遍历的几种方式
- Boost Thread 使用指南
- 黑马程序员--this和super关键字
- leetcode:Set Matrix Zeors 菜鸟解法
- 外观模式 - 结构型模式
- Android SDK开发包国内下载地址
- Windows7下QT5开发环境搭建
- cocos2dx 3.4适配
- 我的Android学习之旅[3]——从简单的Hello World来剖析项目结构
- 分享一种兼具UD、U+V2高端隐藏,支持UEFI和4GB大文件的U启制作思路
- LeetCode 34 Search For A Range 二叉查找相关(二)
- 【Android基础】Activity的启动模式(android:launchMode)
- Linux kernel coding style