笔记--统一编程接口外观模式
2016-02-15 16:26
375 查看
外观模式在开发过程中使用频率非常高,它的精髓二字在于封装。通过一个高层次结构为用户提供统一的API入口,使得用户通过一个类型就基本能操作整个系统,这样减少了用户的使用成本,也能提升系统的灵活性。
使用场景:
为一个复杂子系统提供一个简单接口。子系统往往因为不断演化而变得越来越复杂,甚至被替换。大多数模式使用时都会产生更多更小的类。在这对子系统更具有可重用性的同时也更容易对子系统进行定制 修改,这种易变性使得隐藏子系统的具体实现变得尤为重要。 外观模式可以提供一个简单统一的接口,对外隐藏子系统的具体实现、隔离变化。
当你需要构件一个层次结构的子系统时,使用Facade模式定义子系统中的每层入口点。如果子系统之间是相互依赖的,你可以让他们仅通过Facade接口进行通信,从而简化他们之间的依赖关系。
生活中使用外观模式的地方非常多,任何一个类似中央调度结构的组织都类似外观模式。
下面的文章转载自http://blog.csdn.net/chenssy/article/details/9428553#comments
前面介绍的适配器模式(设计模式读书笔记-----适配器模式)讲的是如何将一个接口转换成客户所需要的另一个接
口,它的目的在于解决接口的不兼容性问题。现在这里有这样一个模式,它的目的在于如何简化接口,它可以将多个
类的复杂的一切隐藏在背后,只显露出一个干净美观的外观。
晚上睡觉之前,你总是喜欢看电视,在你进入卧室的时候你需要完成以下几个步骤:打开电灯、打开空调、放
心银幕(假如你家有)、打开电视通过这么些繁琐的步骤后你终于可以看电视了,但是你要睡觉了呢?又要去进行繁琐
的关闭动作。这里你就需要一个外观模式了,通过实现一个更加合理的接口外观类将这些动作都包装起来,实现一
键“看电视”、一键“关电视”。这就是外观模式的动机
一、模式定义
所谓外观模式就是提供一个统一的接口,用来访问子系统中的一群接口。
外观模式定义了一个高层接口,让子系统更容易使用。如下图,是使用外观模式后将子系统的使用变得更加简单。
在引入外观模式后,客户只需要与外观角色打交道,客户与子系统的复杂关系有外观角色来实现,从而降低了
系统的耦合度。
二、模式结构
外观模式包含如下两个角色:
Facade: 外观角色
SubSystem:子系统角色
三、模式实现
场景就是上面那个“睡觉看电视”的场景。
实例的UML图
首先是四个组件(电视、电灯、空调、银幕)
[java] view
plain copy
print?
public class Television {
public void on(){
System.out.println("打开了电视....");
}
public void off(){
System.out.println("关闭了电视....");
}
}
[java] view
plain copy
print?
public class Light {
public void on(){
System.out.println("打开了电灯....");
}
public void off(){
System.out.println("关闭了电灯....");
}
}
[java] view
plain copy
print?
public class AirCondition {
public void on(){
System.out.println("打开了空调....");
}
public void off(){
System.out.println("关闭了空调....");
}
}
[java] view
plain copy
print?
public class Screen {
public void up(){
System.out.println("升起银幕....");
}
public void down(){
System.out.println("下降银幕....");
}
}
然后是比较强大、干净、美观的外观
[java] view
plain copy
print?
public class WatchTvSwtichFacade {
Light light;
AirCondition ac;
Television tv;
Screen screen;
public WatchTvSwtichFacade(Light light,AirCondition ac,Television tv,Screen screen){
this.light = light;
this.ac = ac;
this.tv = tv;
this.screen = screen;
}
public void on(){
light.on(); //首先开灯
ac.on(); //然后是打开空调
screen.down(); //把银幕降下来
tv.on(); //最后是打开电视
}
public void off(){
tv.off(); //首先关闭电视机
screen.up(); //银幕升上去
ac.off(); //空调关闭
light.off(); //最后关灯
}
}
客户端
[java] view
plain copy
print?
public class Client {
public static void main(String[] args) {
//实例化组件
Light light = new Light();
Television tv = new Television();
AirCondition ac = new AirCondition();
Screen screen = new Screen();
WatchTvSwtichFacade watchTv = new WatchTvSwtichFacade(light, ac, tv, screen);
watchTv.on();
System.out.println("--------------可以看电视了.........");
watchTv.off();
System.out.println("--------------可以睡觉了...........");
}
}
运行结果
从上面的使用通过使用外观模式,客户可以非常方便的实现比较复杂的功能。
四、模式优缺点
优点
1、引入外观模式,是客户对子系统的使用变得简单了,减少了与子系统的关联对象,实现了子系统与客户之间
的松耦合关系。
2、只是提供了一个访问子系统的统一入口,并不影响用户直接使用子系统类
3、降低了大型软件系统中的编译依赖性,并简化了系统在不同平台之间的移植过程
缺点
1、不能很好地限制客户使用子系统类,如果对客户访问子系统类做太多的限制则减少了可变性和灵活性
2、在不引入抽象外观类的情况下,增加新的子系统可能需要修改外观类或客户端的源代码,违背了“开闭原则”
五、使用场景
1、当要为一个复杂子系统提供一个简单接口时可以使用外观模式。
2、客户程序与多个子系统之间存在很大的依赖性。引入外观类将子系统与客户以及其他子系统解耦,可以提
高子系统的独立性和可移植性
六、模式总结
1、 外观模式的主要优点就在于减少了客户与子系统之间的关联对象,使用客户对子系统的使用变得简单了,
也实现了客户与子系统之间的松耦合关系。它的缺点就在于违背了“开闭原则”。
2、 如果需要实现一个外观模式,需要将子系统组合进外观中,然后将工作委托给子系统执行。
使用场景:
为一个复杂子系统提供一个简单接口。子系统往往因为不断演化而变得越来越复杂,甚至被替换。大多数模式使用时都会产生更多更小的类。在这对子系统更具有可重用性的同时也更容易对子系统进行定制 修改,这种易变性使得隐藏子系统的具体实现变得尤为重要。 外观模式可以提供一个简单统一的接口,对外隐藏子系统的具体实现、隔离变化。
当你需要构件一个层次结构的子系统时,使用Facade模式定义子系统中的每层入口点。如果子系统之间是相互依赖的,你可以让他们仅通过Facade接口进行通信,从而简化他们之间的依赖关系。
生活中使用外观模式的地方非常多,任何一个类似中央调度结构的组织都类似外观模式。
下面的文章转载自http://blog.csdn.net/chenssy/article/details/9428553#comments
前面介绍的适配器模式(设计模式读书笔记-----适配器模式)讲的是如何将一个接口转换成客户所需要的另一个接
口,它的目的在于解决接口的不兼容性问题。现在这里有这样一个模式,它的目的在于如何简化接口,它可以将多个
类的复杂的一切隐藏在背后,只显露出一个干净美观的外观。
晚上睡觉之前,你总是喜欢看电视,在你进入卧室的时候你需要完成以下几个步骤:打开电灯、打开空调、放
心银幕(假如你家有)、打开电视通过这么些繁琐的步骤后你终于可以看电视了,但是你要睡觉了呢?又要去进行繁琐
的关闭动作。这里你就需要一个外观模式了,通过实现一个更加合理的接口外观类将这些动作都包装起来,实现一
键“看电视”、一键“关电视”。这就是外观模式的动机
一、模式定义
所谓外观模式就是提供一个统一的接口,用来访问子系统中的一群接口。
外观模式定义了一个高层接口,让子系统更容易使用。如下图,是使用外观模式后将子系统的使用变得更加简单。
在引入外观模式后,客户只需要与外观角色打交道,客户与子系统的复杂关系有外观角色来实现,从而降低了
系统的耦合度。
二、模式结构
外观模式包含如下两个角色:
Facade: 外观角色
SubSystem:子系统角色
三、模式实现
场景就是上面那个“睡觉看电视”的场景。
实例的UML图
首先是四个组件(电视、电灯、空调、银幕)
[java] view
plain copy
print?
public class Television {
public void on(){
System.out.println("打开了电视....");
}
public void off(){
System.out.println("关闭了电视....");
}
}
[java] view
plain copy
print?
public class Light {
public void on(){
System.out.println("打开了电灯....");
}
public void off(){
System.out.println("关闭了电灯....");
}
}
[java] view
plain copy
print?
public class AirCondition {
public void on(){
System.out.println("打开了空调....");
}
public void off(){
System.out.println("关闭了空调....");
}
}
[java] view
plain copy
print?
public class Screen {
public void up(){
System.out.println("升起银幕....");
}
public void down(){
System.out.println("下降银幕....");
}
}
然后是比较强大、干净、美观的外观
[java] view
plain copy
print?
public class WatchTvSwtichFacade {
Light light;
AirCondition ac;
Television tv;
Screen screen;
public WatchTvSwtichFacade(Light light,AirCondition ac,Television tv,Screen screen){
this.light = light;
this.ac = ac;
this.tv = tv;
this.screen = screen;
}
public void on(){
light.on(); //首先开灯
ac.on(); //然后是打开空调
screen.down(); //把银幕降下来
tv.on(); //最后是打开电视
}
public void off(){
tv.off(); //首先关闭电视机
screen.up(); //银幕升上去
ac.off(); //空调关闭
light.off(); //最后关灯
}
}
客户端
[java] view
plain copy
print?
public class Client {
public static void main(String[] args) {
//实例化组件
Light light = new Light();
Television tv = new Television();
AirCondition ac = new AirCondition();
Screen screen = new Screen();
WatchTvSwtichFacade watchTv = new WatchTvSwtichFacade(light, ac, tv, screen);
watchTv.on();
System.out.println("--------------可以看电视了.........");
watchTv.off();
System.out.println("--------------可以睡觉了...........");
}
}
运行结果
从上面的使用通过使用外观模式,客户可以非常方便的实现比较复杂的功能。
四、模式优缺点
优点
1、引入外观模式,是客户对子系统的使用变得简单了,减少了与子系统的关联对象,实现了子系统与客户之间
的松耦合关系。
2、只是提供了一个访问子系统的统一入口,并不影响用户直接使用子系统类
3、降低了大型软件系统中的编译依赖性,并简化了系统在不同平台之间的移植过程
缺点
1、不能很好地限制客户使用子系统类,如果对客户访问子系统类做太多的限制则减少了可变性和灵活性
2、在不引入抽象外观类的情况下,增加新的子系统可能需要修改外观类或客户端的源代码,违背了“开闭原则”
五、使用场景
1、当要为一个复杂子系统提供一个简单接口时可以使用外观模式。
2、客户程序与多个子系统之间存在很大的依赖性。引入外观类将子系统与客户以及其他子系统解耦,可以提
高子系统的独立性和可移植性
六、模式总结
1、 外观模式的主要优点就在于减少了客户与子系统之间的关联对象,使用客户对子系统的使用变得简单了,
也实现了客户与子系统之间的松耦合关系。它的缺点就在于违背了“开闭原则”。
2、 如果需要实现一个外观模式,需要将子系统组合进外观中,然后将工作委托给子系统执行。
相关文章推荐
- python笔记--廖雪峰站学习笔记
- spring security 3中的10个典型用法小结
- C# WebService (二)发布与IIS配置
- Java 高并发缓存与Guava Cache
- Dubbo与Zookeeper、SpringMVC整合和使用(负载均衡、容错)
- 深入浅出Python装饰器
- VsFtpd服务配置简明笔记
- c# - Cache Code
- eclipse中的android布局文件的快捷键Alt+/不起作用的一种解决方法
- 第44讲:Scala中View Bounds代码实战及其在Spark中的应用源码解析
- PHP数组操作
- python中的引用
- SpringMvc:在使用@RequestBody和@ResponseBody的时候报415错误
- php获取某天的上周一日期与时间戳
- C++求1到n中1出现的次数以及数的二进制表示中1的个数
- hdu1016 深搜回溯
- Python + PIL 图片验证码
- 异常com.google.gson.internal.StringMap cannot be cast to XXX解决方案
- 使用python爬取csdn博客访问量
- 菜鸟学SSH(二)——Struts2国际化手动切换版