dedecms 网站安全设置,创艺装饰公司,一个人在线观看播放视频,南阳网站推广费用Bridge模式的概念 Bridge 模式是构造型的设计模式之中的一个。Bridge模式基于类的最小设计原则#xff0c;通过使用封装#xff0c;聚合以及继承等行为来让不同的类承担不同的责任。它的主要特点是把抽象#xff08;abstraction#xff09;与行为实现#xff08;implement… Bridge模式的概念 Bridge 模式是构造型的设计模式之中的一个。Bridge模式基于类的最小设计原则通过使用封装聚合以及继承等行为来让不同的类承担不同的责任。它的主要特点是把抽象abstraction与行为实现implementation分离开来从而能够保持各部分的独立性以及应对它们的功能扩展。 Bridge模式的应用场景 面向对象的程序设计OOP里有类继承子类继承父类的概念假设一个类或接口有多个详细实现子类。假设这些子类具有下面特性 - 存在相对并列的子类属性。 - 存在概念上的交叉。 - 可变性。 我们就能够用Bridge模式来对其进行抽象与详细。对相关类进行重构。 桥接模式的适用 你不希望在抽象和它的实现部分之间有一个固定的绑定关系。比如程序的实现部分在执行时须要被选择或者切换。 类的抽象以及它的实现都应该能够通过生成子类的方法加以扩充。这时Bridge模式使你能够对不同的抽象接口和实现部分进行组合并分别对它们进行扩充。 对一个抽象实现的改动须要对客户不产生影响即客户的代码不必又一次编译。 有很多类要生成。这样的情况下你必须将一个对象分解成两个部分。这样的类层次结构为“嵌套的普化”。 你想在多个对象间共享实现可能使用引用计数但同一时候要求客户并不知道这一点。 生活中的一个样例: 拿汽车在路上行驶的来说。既有小汽车又有公共汽车它们都不但能在市区中的公路上行驶也能在快速公路上行驶。这你会发现对于交通工具汽车有不同的类型。它们所行驶的环境路也有不同类型在软件系统中就要适应两个方面不同车型不同道路的变化如何实现才干应对这样的变化呢概述: 在软件系统中。某些类型因为自身的逻辑。它具有两个或多个维度的变化那么怎样应对这样的“多维度的变化”怎样利用面向对象的技术来使得该类型可以轻松的沿着多个方向进行变化而又不引入额外的复杂度这就要使用Bridge模式。意图: 将抽象部分与实现部分分离使它们都能够独立的变化。 ——《设计模式》GOF 上面这些话我也没看懂。。太抽象了可是一看代码你就明确是怎么回事了。结构图: 传统的做法: 通过类继承的方式来做上面的样例; 先看一下类结构图: 代码实现 [java] view plaincopyprint? //基类 路 class Road { void run() { System.out.println(路); } } //市区街道 class Street extends Road { void run() { System.out.println(市区街道); } } //快速公路 class SpeedWay extends Road { void run() { System.out.println(快速公路); } } //小汽车在市区街道行驶 class CarOnStreet extends Street { void run() { System.out.println(小汽车在市区街道行驶); } } //小汽车在快速公路行驶 class CarOnSpeedWay extends SpeedWay { void run() { System.out.println(小汽车在快速公路行驶); } } //公交车在市区街道行驶 class BusOnStreet extends Street { void run() { System.out.println(公交车在市区街道行驶); } } //公交车在快速公路行驶 class BusOnSpeedWay extends SpeedWay { void run() { System.out.println(公交车在快速公路行驶); } } //測试 public static void main(String[] args) { //小汽车在快速公路行驶 CarOnSpeedWay carOnSpeedWay new CarOnSpeedWay(); carOnSpeedWay.run(); //公交车在市区街道行驶 BusOnStreet busOnStreet new BusOnStreet(); busOnStreet.run(); } 缺点: 可是我们说这种设计是脆弱的细致分析就能够发现它还是存在非常多问题首先它在遵循开放-封闭原则的同一时候。违背了类的单一职责原则即一个类仅仅有一个引起它变化的原因。而这里引起变化的原因却有两个。即路类型的变化和汽车类型的变化其次是反复代码会非常多不同的汽车在不同的路上行驶也会有一部分的代码是同样的 再次是类的结构过于复杂继承关系太多难于维护。最后最致命的一点是扩展性太差。假设变化沿着汽车的类型和不同的道路两个方向变化我们会看到这个类的结构会迅速的变庞大。 应用设计模式 桥接模式Bridge来做; 先看一下类结构图: 代码实现 [java] view plaincopyprint? abstract class AbstractRoad{ AbstractCar aCar; void run(){}; } abstract class AbstractCar{ void run(){}; } class Street extends AbstractRoad{ Override void run() { // TODO Auto-generated method stub super.run(); aCar.run(); System.out.println(在市区街道行驶); } } class SpeedWay extends AbstractRoad{ Override void run() { // TODO Auto-generated method stub super.run(); aCar.run(); System.out.println(在快速公路行驶); } } class Car extends AbstractCar{ Override void run() { // TODO Auto-generated method stub super.run(); System.out.print(小汽车); } } class Bus extends AbstractCar{ Override void run() { // TODO Auto-generated method stub super.run(); System.out.print(公交车); } } public static void main(String[] args){ AbstractRoad speedWay new SpeedWay(); speedWay.aCar new Car(); speedWay.run(); AbstractRoad street new Street(); street.aCar new Bus(); street.run(); } 能够看到。通过对象组合的方式Bridge 模式把两个角色之间的继承关系改为了耦合的关系。从而使这两者能够从容自若的各自独立的变化这也是Bridge模式的本意。 这样添加了客户程序与路与汽车的耦合。事实上这种操心是没有必要的由于这种耦合性是由于对象的创建所带来的全然能够用创建型模式去解决。在应用时结合创建型设计模式来处理详细的问题。应用设计模式: 桥接模式Bridge来做(多维度变化); 结合上面的样例,添加一个维度人,不同的人开着不同的汽车在不同的路上行驶(三个维度); 结合上面添加一个类人,并又一次调用.代码实现: [java] view plaincopyprint? abstract class People { AbstractRoad road; void run() {} } class Man extends People{ Override void run() { // TODO Auto-generated method stub super.run(); System.out.print(男人开着); road.run(); } } class Woman extends People{ Override void run() { // TODO Auto-generated method stub super.run(); System.out.print(女人开着); road.run(); } } public static void main(String[] args) { AbstractRoad speedWay new SpeedWay(); speedWay.aCar new Car(); People man new Man(); man.road speedWay; man.run(); } 效果及实现要点1Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系使得抽象和实现能够沿着各自的维度来变化。 2所谓抽象和实现沿着各自维度的变化即“子类化”它们。得到各个子类之后便能够随意它们。从而获得不同路上的不同汽车。 3Bridge模式有时候类似于多继承方案可是多继承方案往往违背了类的单一职责原则即一个类仅仅有一个变化的原因复用性比較差。Bridge模式是比多继承方案更好的解决方法。 4Bridge模式的应用一般在“两个很强的变化维度”有时候即使有两个变化的维度。可是某个方向的变化维度并不剧烈——换言之两个变化不会导致纵横交错的结果并不一定要使用Bridge模式。适用性 在下面的情况下应当使用桥梁模式 1假设一个系统须要在构件的抽象化角色和详细化角色之间添加很多其它的灵活性避免在两个层次之间建立静态的联系。 2设计要求实现化角色的不论什么改变不应当影响client或者说实现化角色的改变对client是全然透明的。3一个构件有多于一个的抽象化角色和实现化角色。系统须要它们之间进行动态耦合。 4尽管在系统中使用继承是没有问题的。可是因为抽象化角色和详细化角色须要独立变化设计要求须要独立管理这两者。总结 Bridge模式是一个很实用的模式也很复杂。它很好的符合了开放-封闭原则和优先使用对象而不是继承这两个面向对象原则。 本文借鉴文章 http://blog.csdn.net/jason0539/article/details/22568865
