JAVA设计模式初探之桥接模式

简介:

生活中的一个例子:
    拿汽车在路上行驶的来说。既有小汽车又有公共汽车,它们都不但能在市区中的公路上行驶,也能在高速公路上行驶。这你会发现,对于交通工具(汽车)有不同的类型,它们所行驶的环境(路)也有不同类型,在软件系统中就要适应两个方面(不同车型,不同道路)的变化,怎样实现才能应对这种变化呢?
概述:
在软件系统中,某些类型由于自身的逻辑,它具有两个或多个维度的变化,那么如何应对这种“多维度的变化”?如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化,而又不引入额外的复杂度?这就要使用Bridge模式。
意图:
   将抽象部分与实现部分分离,使它们都可以独立的变化。
                                                                    ——《设计模式》GOF 

上面这些话我也没看懂。。太抽象了,但是一看代码你就明白是怎么回事了。
结构图:

传统的做法:
        通过类继承的方式来做上面的例子;
先看一下类结构图:

代码实现:

[java]  view plain  copy print?在CODE上查看代码片派生到我的代码片
  1.         //基类 路  
  2. class Road {  
  3.     void run() {  
  4.         System.out.println("路");  
  5.     }  
  6. }  
  7.   
  8. //市区街道  
  9. class Street extends Road {  
  10.     void run() {  
  11.         System.out.println("市区街道");  
  12.     }  
  13. }  
  14.   
  15. //高速公路  
  16. class SpeedWay extends Road {  
  17.     void run() {  
  18.         System.out.println("高速公路");  
  19.     }  
  20. }  
  21. //小汽车在市区街道行驶  
  22. class CarOnStreet extends Street {  
  23.     void run() {  
  24.         System.out.println("小汽车在市区街道行驶");  
  25.     }  
  26. }  
  27. //小汽车在高速公路行驶  
  28. class CarOnSpeedWay extends SpeedWay {  
  29.     void run() {  
  30.         System.out.println("小汽车在高速公路行驶");  
  31.     }  
  32. }  
  33. //公交车在市区街道行驶  
  34. class BusOnStreet extends Street {  
  35.     void run() {  
  36.         System.out.println("公交车在市区街道行驶");  
  37.     }  
  38. }  
  39. //公交车在高速公路行驶  
  40. class BusOnSpeedWay extends SpeedWay {  
  41.     void run() {  
  42.         System.out.println("公交车在高速公路行驶");  
  43.     }  
  44. }  
  45. //测试  
  46. public static void main(String[] args) {  
  47.       
  48.     //小汽车在高速公路行驶  
  49.     CarOnSpeedWay carOnSpeedWay = new CarOnSpeedWay();  
  50.     carOnSpeedWay.run();  
  51.     //公交车在市区街道行驶  
  52.     BusOnStreet busOnStreet = new BusOnStreet();  
  53.     busOnStreet.run();  
  54.   
  55. }  

缺点:
     但是我们说这样的设计是脆弱的,仔细分析就可以发现,它还是存在很多问题,首先它在遵循开放-封闭原则的同时,违背了类的单一职责原则,即一个类只有一个引起它变化的原因,而这里引起变化的原因却有两个,即路类型的变化和汽车类型的变化;其次是重复代码会很多,不同的汽车在不同的路上行驶也会有一部分的代码是相同的;

再次是类的结构过于复杂,继承关系太多,难于维护,最后最致命的一点是扩展性太差。如果变化沿着汽车的类型和不同的道路两个方向变化,我们会看到这个类的结构会迅速的变庞大。

应用设计模式
       桥接模式(Bridge)来做;
先看一下类结构图:

代码实现:

[java]  view plain  copy print?在CODE上查看代码片派生到我的代码片
  1. abstract class AbstractRoad{  
  2.     AbstractCar aCar;  
  3.     void run(){};  
  4. }  
  5. abstract class AbstractCar{  
  6.     void run(){};  
  7. }  
  8.   
  9. class Street extends AbstractRoad{  
  10.     @Override  
  11.     void run() {  
  12.         // TODO Auto-generated method stub  
  13.         super.run();  
  14.         aCar.run();  
  15.         System.out.println("在市区街道行驶");  
  16.     }  
  17. }  
  18. class SpeedWay extends AbstractRoad{  
  19.     @Override  
  20.     void run() {  
  21.         // TODO Auto-generated method stub  
  22.         super.run();  
  23.         aCar.run();  
  24.         System.out.println("在高速公路行驶");  
  25.     }  
  26. }  
  27. class Car extends AbstractCar{  
  28.     @Override  
  29.     void run() {  
  30.         // TODO Auto-generated method stub  
  31.         super.run();  
  32.         System.out.print("小汽车");  
  33.     }  
  34. }  
  35. class Bus extends AbstractCar{  
  36.     @Override  
  37.     void run() {  
  38.         // TODO Auto-generated method stub  
  39.         super.run();  
  40.         System.out.print("公交车");  
  41.     }  
  42. }  
  43.   
  44. public static void main(String[] args){  
  45.       
  46.     AbstractRoad speedWay = new SpeedWay();  
  47.     speedWay.aCar = new Car();  
  48.     speedWay.run();  
  49.       
  50.     AbstractRoad street = new Street();  
  51.     street.aCar = new Bus();  
  52.     street.run();  
  53. }  

 可以看到,通过对象组合的方式,Bridge 模式把两个角色之间的继承关系改为了耦合的关系,从而使这两者可以从容自若的各自独立的变化,这也是Bridge模式的本意。
      这样增加了客户程序与路与汽车的耦合。其实这样的担心是没有必要的,因为这种耦合性是由于对象的创建所带来的,完全可以用创建型模式去解决。在应用时结合创建型设计模式来处理具体的问题。
应用设计模式:
       桥接模式(Bridge)来做(多维度变化);
       结合上面的例子,增加一个维度"人",不同的人开着不同的汽车在不同的路上行驶(三个维度);
       结合上面增加一个类"人",并重新调用.
代码实现:

[java]  view plain  copy print?在CODE上查看代码片派生到我的代码片
  1. abstract class People {  
  2.     AbstractRoad road;  
  3.   
  4.     void run() {}  
  5. }  
  6.   
  7. class Man extends People{  
  8.     @Override  
  9.     void run() {  
  10.         // TODO Auto-generated method stub  
  11.         super.run();  
  12.         System.out.print("男人开着");  
  13.         road.run();  
  14.     }  
  15. }  
  16. class Woman extends People{  
  17.     @Override  
  18.     void run() {  
  19.         // TODO Auto-generated method stub  
  20.         super.run();  
  21.         System.out.print("女人开着");  
  22.         road.run();  
  23.     }  
  24. }  
  25.   
  26. public static void main(String[] args) {  
  27.   
  28.     AbstractRoad speedWay = new SpeedWay();  
  29.     speedWay.aCar = new Car();  
  30.       
  31.     People man = new Man();  
  32.     man.road = speedWay;  
  33.     man.run();  
  34. }  


效果及实现要点:
1.Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系,使得抽象和实现可以沿着各自的维度来变化。
2.所谓抽象和实现沿着各自维度的变化,即“子类化”它们,得到各个子类之后,便可以任意它们,从而获得不同路上的不同汽车。
3.Bridge模式有时候类似于多继承方案,但是多继承方案往往违背了类的单一职责原则(即一个类只有一个变化的原因),复用性比较差。Bridge模式是比多继承方案更好的解决方法。
4.Bridge模式的应用一般在“两个非常强的变化维度”,有时候即使有两个变化的维度,但是某个方向的变化维度并不剧烈——换言之两个变化不会导致纵横交错的结果,并不一定要使用Bridge模式。

适用性:
   在以下的情况下应当使用桥梁模式:
1.如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性,避免在两个层次之间建立静态的联系。 
2.设计要求实现化角色的任何改变不应当影响客户端,或者说实现化角色的改变对客户端是完全透明的。
3.一个构件有多于一个的抽象化角色和实现化角色,系统需要它们之间进行动态耦合。 
4.虽然在系统中使用继承是没有问题的,但是由于抽象化角色和具体化角色需要独立变化,设计要求需要独立管理这两者。
总结:
      Bridge模式是一个非常有用的模式,也非常复杂,它很好的符合了开放-封闭原则和优先使用对象,而不是继承这两个面向对象原则。




    本文转自 一点点征服   博客园博客,原文链接:http://www.cnblogs.com/ldq2016/p/6714517.html,如需转载请自行联系原作者


相关文章
|
8天前
|
设计模式 Java 开发者
设计模式揭秘:Java世界的七大奇迹
【4月更文挑战第7天】探索Java设计模式:单例、工厂方法、抽象工厂、建造者、原型、适配器和观察者,助你构建健壮、灵活的软件系统。了解这些模式如何提升代码复用、可维护性,以及在特定场景下的应用,如资源管理、接口兼容和事件监听。掌握设计模式,但也需根据实际情况权衡,打造高效、优雅的软件解决方案。
|
9天前
|
设计模式 存储 Java
23种设计模式,享元模式的概念优缺点以及JAVA代码举例
【4月更文挑战第6天】享元模式(Flyweight Pattern)是一种结构型设计模式,旨在通过共享技术有效地支持大量细粒度对象的重用。这个模式在处理大量对象时非常有用,特别是当这些对象中的许多实例实际上可以共享相同的状态时,从而可以减少内存占用,提高程序效率
29 4
|
9天前
|
设计模式 Java 中间件
23种设计模式,适配器模式的概念优缺点以及JAVA代码举例
【4月更文挑战第6天】适配器模式(Adapter Pattern)是一种结构型设计模式,它的主要目标是让原本由于接口不匹配而不能一起工作的类可以一起工作。适配器模式主要有两种形式:类适配器和对象适配器。类适配器模式通过继承来实现适配,而对象适配器模式则通过组合来实现
30 4
|
13天前
|
设计模式 Java 数据库
Java设计模式精讲:让代码更优雅、更可维护
【4月更文挑战第2天】**设计模式是解决软件设计问题的成熟方案,分为创建型、结构型和行为型。Java中的单例模式确保类仅有一个实例,工厂方法模式让子类决定实例化哪个类。适配器模式则协调不兼容接口间的合作。观察者模式实现了一对多依赖,状态变化时自动通知相关对象。学习和适当应用设计模式能提升代码质量和可维护性,但需避免过度使用。设计模式的掌握源于实践与不断学习。**
Java设计模式精讲:让代码更优雅、更可维护
|
27天前
|
设计模式
设计模式之桥接模式
设计模式之桥接模式
|
1月前
|
设计模式 Linux Windows
【设计模式】桥接模式
【设计模式】桥接模式
|
17天前
|
设计模式 安全 Java
在Java中即指单例设计模式
在Java中即指单例设计模式
15 0
|
8天前
|
设计模式 监控 Java
设计模式 - 观察者模式(Observer):Java中的战术与策略
【4月更文挑战第7天】观察者模式是构建可维护、可扩展系统的关键,它在Java中通过`Observable`和`Observer`实现对象间一对多的依赖关系,常用于事件处理、数据绑定和同步。该模式支持事件驱动架构、数据同步和实时系统,但需注意避免循环依赖、控制通知粒度,并关注性能和内存泄漏问题。通过明确角色、使用抽象和管理观察者注册,可最大化其效果。
|
1月前
|
设计模式 存储 安全
Java设计模式---结构型模式
Java设计模式---结构型模式
|
1天前
|
设计模式 存储 Java
Java设计模式:解释一下单例模式(Singleton Pattern)。
`Singleton Pattern`是Java中的创建型设计模式,确保类只有一个实例并提供全局访问点。它通过私有化构造函数,用静态方法返回唯一的实例。类内静态变量存储此实例,对外仅通过静态方法访问。
9 1