设计模式笔记--桥梁模式
2016-01-13 18:21
253 查看
常用设计模式有23中,分为:
创建型模式(主要用于创建对象)
1、单例模式 2、工厂方法模式
3、抽象工厂模式 4、建造者模式 5、原型模式
行为型模式 (主要用于描述对象或类是怎样交互和怎样分配职责)
1、模板方法模式 2、中介者模式 3、命令模式
4、责任链模式 5、策略模式 6、迭代器模式
7、观察者模式 8、备忘录模式 9、访问者模式 10、状态模式 11、解释器模式
结构型模式(主要用于处理类或对象的组合)
1、代理模式 2、装饰模式
3、适配器模式 4、组合模式 5、外观模式(门面模式) 6、享元模式
7、桥梁模式
桥梁模式
桥梁模式(Bridge Pattern)也叫做桥接模式,是一个比较简单的模式,其定义如下:
将抽象和实现解耦,使得两者可以独立地变化。
桥梁模式的重点是在“解耦”上
我们先来看桥梁模式中的4个角色。
● Abstraction——抽象化角色
它的主要职责是定义出该角色的行为,同时保存一个对实现化角色的引用,该角色一般是抽象类。
● Implementor——实现化角色
它是接口或者抽象类,定义角色必需的行为和属性。
● RefinedAbstraction——修正抽象化角色
它引用实现化角色对抽象化角色进行修正。
● ConcreteImplementor——具体实现化角色
它实现接口或抽象类定义的方法和属性。
抽象角色引用实现角色,或者说抽象角色的部分实现是由实现角色完成的
通用源码
先看实现化角色,如代码清单29-16所示。
它没有任何特殊的地方,就是一个一般的接口,定义要实现的方法。
其实现类如代码清单29-17所示。
上面定义了两个具体实现化角色——代表两个不同的业务逻辑。
我们再来看抽象化角色,如代码清单29-18所示。
为什么要增加一个构造函数?答案是为了提醒子类,你必须做这项工作,指定实现者,特别是已经明确了实现者,则尽量清晰明确地定义出来。
我们来看具体的抽象化角色,如代码清单29-19所示。
想想看,如果我们的实现化角色有很多的子接口,然后是一堆的子实现。如果在构造函数中不传递一个尽量明确的实现者,代码就很不清晰。
我们来看场景类如何模拟,如代码清单29-20所示。
桥梁模式是一个非常简单的模式,它只是使用了类间的聚合关系、继承、覆写等常用功能,但是它却提供了一个非常清晰、稳定的架构。
优点
● 抽象和实现分离
这也是桥梁模式的主要特点,它完全是为了解决继承的缺点而提出的设计模式。在该模式下,实现可以不受抽象的约束,不用再绑定在一个固定的抽象层次上。
● 优秀的扩充能力
● 实现细节对客户透明
使用场景
● 不希望或不适用使用继承的场景
● 接口或抽象类不稳定的场景
● 重用性要求较高的场景
注意事项
桥梁模式的意图还是对变化的封装,尽量把可能变化的因素封装到最细、最小的逻辑单元中,避免风险扩散。因此读者在进行系统设计时,发现类的继承有N层时,可以考虑使用桥梁模式。
继承的优点有很多,可以把公共的方法或属性抽取,父类封装共性,子类实现特性,这是继承的基本功能。
缺点有没有?有!即强侵入,父类有一个方法,子类也必须有这个方法。
对于比较明确不发生变化的,则通过继承来完成;
若不能确定是否会发生变化的,那就认为是会发生变化,则通过桥梁模式来解决,这才是一个完美的世界。
实例 山寨工厂
先看Product抽象类
House产品类如代码清单29-8所示。
既然是产品类,那肯定有两种行为要存在:被生产和被销售,否则就不能称为产品了。
我们再来看iPod产品类,如代码清单29-9所示。
产品是由公司生产出来的,我们来看公司Corp抽象类,如代码清单29-10所示。
这里多了个有参构造,其目的是要继承的子类都必选重写自己的有参构造函数,把产品类传递进来,
再看子类HouseCorp的实现,如代码清单29-11所示。
继续看山寨公司的实现,如代码清单29-12所示。
HouseCorp类和ShanZhaiCorp类的区别是在有参构造的参数类型上,HouseCorp类比较明确,我就是只要House类,所以直接定义传递进来的必须是House类, 一个类尽可能少地承担职责,那方法也一样,既然HouseCorp类已经非常明确地只生产House产品,那为什么不定义成House类型呢?ShanZhaiCorp就不同了,它确定不了生产什么类型。
好了,两大对应的阵营都已经产生了。我们再看Client程序,如代码清单29-13所示。
深入思考一下,既然万物都是运动的,现在只有房地产公司和山寨公司,那以后我会不会增加一些其他的公司呢?或者房地产公司会不会对业务进行细化,如分为公寓房公司、别墅公司,以及商业房公司等呢?
绝对会的!但是你发觉没有,这种变化对我们上面的类图来说不会做大的修改,充其量只是扩展:
● 增加公司,要么继承Corp类,要么继承HouseCorp或ShanZhaiCorp,不用再修改原有的类了。
● 增加产品,继承Product类,或者继承House类,你要把房子分为公寓房、别墅、商业用房等。
唯一要修改的就是Client类。类都增加了,高层模块也需要修改,也就是说Corp类和Product类都可以自由地扩展,而不会对整个应用产生太大的变更,这就是桥梁模式。
创建型模式(主要用于创建对象)
1、单例模式 2、工厂方法模式
3、抽象工厂模式 4、建造者模式 5、原型模式
行为型模式 (主要用于描述对象或类是怎样交互和怎样分配职责)
1、模板方法模式 2、中介者模式 3、命令模式
4、责任链模式 5、策略模式 6、迭代器模式
7、观察者模式 8、备忘录模式 9、访问者模式 10、状态模式 11、解释器模式
结构型模式(主要用于处理类或对象的组合)
1、代理模式 2、装饰模式
3、适配器模式 4、组合模式 5、外观模式(门面模式) 6、享元模式
7、桥梁模式
桥梁模式
桥梁模式(Bridge Pattern)也叫做桥接模式,是一个比较简单的模式,其定义如下:
将抽象和实现解耦,使得两者可以独立地变化。
桥梁模式的重点是在“解耦”上
我们先来看桥梁模式中的4个角色。
● Abstraction——抽象化角色
它的主要职责是定义出该角色的行为,同时保存一个对实现化角色的引用,该角色一般是抽象类。
● Implementor——实现化角色
它是接口或者抽象类,定义角色必需的行为和属性。
● RefinedAbstraction——修正抽象化角色
它引用实现化角色对抽象化角色进行修正。
● ConcreteImplementor——具体实现化角色
它实现接口或抽象类定义的方法和属性。
抽象角色引用实现角色,或者说抽象角色的部分实现是由实现角色完成的
通用源码
先看实现化角色,如代码清单29-16所示。
<span style="font-size:18px;">代码清单29-16 实现化角色 public interface Implementor { //基本方法 public void doSomething(); public void doAnything(); }</span>
它没有任何特殊的地方,就是一个一般的接口,定义要实现的方法。
其实现类如代码清单29-17所示。
<span style="font-size:18px;">代码清单29-17 具体实现化角色 public class ConcreteImplementor1 implements Implementor{ public void doSomething(){ //业务逻辑处理 } public void doAnything(){ //业务逻辑处理 } }</span>
<span style="font-size:18px;">public class ConcreteImplementor2 implements Implementor{ public void doSomething(){ //业务逻辑处理 } public void doAnything(){ //业务逻辑处理 } }</span>
上面定义了两个具体实现化角色——代表两个不同的业务逻辑。
我们再来看抽象化角色,如代码清单29-18所示。
<span style="font-size:18px;">代码清单29-18 抽象化角色 public abstract class Abstraction { //定义对实现化角色的引用 private Implementor imp; //约束子类必须实现该构造函数 public Abstraction(Implementor _imp){ this.imp = _imp; } //自身的行为和属性 public void request(){ this.imp.doSomething(); } //获得实现化角色 public Implementor getImp(){ return imp; } }</span>
为什么要增加一个构造函数?答案是为了提醒子类,你必须做这项工作,指定实现者,特别是已经明确了实现者,则尽量清晰明确地定义出来。
我们来看具体的抽象化角色,如代码清单29-19所示。
<span style="font-size:18px;">代码清单29-19 具体抽象化角色 public class RefinedAbstraction extends Abstraction { //覆写构造函数 public RefinedAbstraction(Implementor _imp){ super(_imp); } //修正父类的行为 @Override public void request(){ /* * 业务处理... */ super.request(); super.getImp().doAnything(); } }</span>
想想看,如果我们的实现化角色有很多的子接口,然后是一堆的子实现。如果在构造函数中不传递一个尽量明确的实现者,代码就很不清晰。
我们来看场景类如何模拟,如代码清单29-20所示。
<span style="font-size:18px;">代码清单29-20 场景类 public class Client { public static void main(String[] args) { //定义一个实现化角色 Implementor imp = new ConcreteImplementor1(); //定义一个抽象化角色 Abstraction abs = new RefinedAbstraction(imp); //执行行文 abs.request(); } }</span>
桥梁模式是一个非常简单的模式,它只是使用了类间的聚合关系、继承、覆写等常用功能,但是它却提供了一个非常清晰、稳定的架构。
优点
● 抽象和实现分离
这也是桥梁模式的主要特点,它完全是为了解决继承的缺点而提出的设计模式。在该模式下,实现可以不受抽象的约束,不用再绑定在一个固定的抽象层次上。
● 优秀的扩充能力
● 实现细节对客户透明
使用场景
● 不希望或不适用使用继承的场景
● 接口或抽象类不稳定的场景
● 重用性要求较高的场景
注意事项
桥梁模式的意图还是对变化的封装,尽量把可能变化的因素封装到最细、最小的逻辑单元中,避免风险扩散。因此读者在进行系统设计时,发现类的继承有N层时,可以考虑使用桥梁模式。
继承的优点有很多,可以把公共的方法或属性抽取,父类封装共性,子类实现特性,这是继承的基本功能。
缺点有没有?有!即强侵入,父类有一个方法,子类也必须有这个方法。
对于比较明确不发生变化的,则通过继承来完成;
若不能确定是否会发生变化的,那就认为是会发生变化,则通过桥梁模式来解决,这才是一个完美的世界。
实例 山寨工厂
先看Product抽象类
<span style="font-size:18px;">代码清单29-7 抽象产品类 public abstract class Product { //甭管是什么产品它总要能被生产出来 public abstract void beProducted(); //生产出来的东西,一定要销售出去,否则亏本 public abstract void beSelled(); }</span>
House产品类如代码清单29-8所示。
<span style="font-size:18px;">代码清单29-8 房子 public class House extends Product { //豆腐渣就豆腐渣呗,好歹也是房子 public void beProducted() { System.out.println("生产出的房子是这样的..."); } //虽然是豆腐渣,也是能够销售出去的 public void beSelled() { System.out.println("生产出的房子卖出去了..."); } }</span>
既然是产品类,那肯定有两种行为要存在:被生产和被销售,否则就不能称为产品了。
我们再来看iPod产品类,如代码清单29-9所示。
<span style="font-size:18px;">代码清单29-9 iPod产品 public class IPod extends Product { public void beProducted() { System.out.println("生产出的iPod是这样的..."); } public void beSelled() { System.out.println("生产出的iPod卖出去了..."); } }</span>
产品是由公司生产出来的,我们来看公司Corp抽象类,如代码清单29-10所示。
<span style="font-size:18px;">代码清单29-10 抽象公司类 public abstract class Corp { //定义一个抽象的产品对象,不知道具体是什么产品 private Product product; //构造函数,由子类定义传递具体的产品进来 public Corp(Product product){ this.product = product; } //公司是干什么的?赚钱的! public void makeMoney(){ //每家公司都是一样,先生产 this.product.beProducted(); //然后销售 this.product.beSelled(); } }</span>
这里多了个有参构造,其目的是要继承的子类都必选重写自己的有参构造函数,把产品类传递进来,
再看子类HouseCorp的实现,如代码清单29-11所示。
<span style="font-size:18px;">代码清单29-11 房地产公司 public class HouseCorp extends Corp { //定义传递一个House产品进来 public HouseCorp(House house){ super(house); } //房地产公司很High了,赚钱,计算利润 public void makeMoney(){ super.makeMoney(); System.out.println("房地产公司赚大钱了..."); } }</span>
继续看山寨公司的实现,如代码清单29-12所示。
<span style="font-size:18px;">代码清单29-12 山寨公司 public class ShanZhaiCorp extends Corp { //产什么产品,不知道,等被调用的才知道 public ShanZhaiCorp(Product product){ super(product); } //狂赚钱 public void makeMoney(){ super.makeMoney(); System.out.println("我赚钱呀..."); } }</span>
HouseCorp类和ShanZhaiCorp类的区别是在有参构造的参数类型上,HouseCorp类比较明确,我就是只要House类,所以直接定义传递进来的必须是House类, 一个类尽可能少地承担职责,那方法也一样,既然HouseCorp类已经非常明确地只生产House产品,那为什么不定义成House类型呢?ShanZhaiCorp就不同了,它确定不了生产什么类型。
好了,两大对应的阵营都已经产生了。我们再看Client程序,如代码清单29-13所示。
代码清单29-13 场景类 public class Client { public static void main(String[] args) { House house = new House(); System.out.println("-------房地产公司是这样运行的-------"); //先找到房地产公司 HouseCorp houseCorp =new HouseCorp(house); //看我怎么挣钱 houseCorp.makeMoney(); System.out.println("\n"); //山寨公司生产的产品很多,不过我只要指定产品就成了 System.out.println("-------山寨公司是这样运行的-------"); ShanZhaiCorp shanZhaiCorp = new ShanZhaiCorp(new IPod()); shanZhaiCorp.makeMoney(); } }
深入思考一下,既然万物都是运动的,现在只有房地产公司和山寨公司,那以后我会不会增加一些其他的公司呢?或者房地产公司会不会对业务进行细化,如分为公寓房公司、别墅公司,以及商业房公司等呢?
绝对会的!但是你发觉没有,这种变化对我们上面的类图来说不会做大的修改,充其量只是扩展:
● 增加公司,要么继承Corp类,要么继承HouseCorp或ShanZhaiCorp,不用再修改原有的类了。
● 增加产品,继承Product类,或者继承House类,你要把房子分为公寓房、别墅、商业用房等。
唯一要修改的就是Client类。类都增加了,高层模块也需要修改,也就是说Corp类和Product类都可以自由地扩展,而不会对整个应用产生太大的变更,这就是桥梁模式。
相关文章推荐
- 【Delphi 篇】CodeGear 问题与解决方式
- linux服务器 磁盘和文件系统管理(三) LVM应用实例
- C++10中的移动语义
- Android 创建其他程序对应的Context
- 2015 Open Source News
- 62. Unique Paths && 63. Unique Paths II
- LeetCode14. Longest Common Prefix
- Volley
- 3D打印准备工作
- Android音乐播放器乱码
- rhel6 rhel7 fedora ubuntu windows 共存 使用grub2 os-probe 启动 使用grub的老系统 bootloader
- Redis 安装
- RxJava开发精要8 - 与REST无缝结合-RxJava和Retrofit
- 教你用SingalR实现后台开发程序运行时时检测
- Android之Activity的栈管理
- Nginx配置PHP的Yii与CakePHP框架的rewrite规则示例
- apue高级IO
- iOS 雷达扫描效果 实现
- 迎接2016,一个程序员的总结
- java学习个人笔记---常见的垃圾回收器及存储结构分析