了解桥模式

桥模式：将某个问题抽象的不同形式分别与该问题的具体实现部分相分离，使他们都可以独立变化，并能够动态结合。

      例如电视厂商海尔，长虹生产21寸，29寸电视机。从这里要将它们分离出来，就用到桥模式。电视机与电视机生产厂商挂桥，从而，分离出不同厂商的实现，与不同电视机型号的实现.

     下面看下uml

 

从上图可以看出，将实际抽象分离出来。

看下代码

创建电视机

public abstract class Television {
	//电视厂商
	protected TelevisionMaker televisionMaker;
	//收看电视
	abstract public void teleview(TelevisionMaker televisionMaker);
}

 

接下来创建生产厂商

public abstract class TelevisionMaker {
	abstract public void produce();
}

 

电视机的型号，即继承电视机类

public class Inch21 extends Television{
	
	public void teleview(TelevisionMaker televisionMaker) {
		System.out.println("21寸电视");
	}

}

 

public class Inch29 extends Television{
	
	public void teleview(TelevisionMaker televisionMaker) {
		System.out.println("29寸电视");
	}

}

 

下面是不同厂商，即继承生产厂商

 

public class ChangHong extends TelevisionMaker{

	public ChangHong(){
		System.out.println("长虹厂商");
	}
	
	public void produce() {
		System.out.println("长虹厂商");
	}
}

 

public class Haier extends TelevisionMaker{
	public Haier(){
		System.out.println("海尔厂商");
	}
	
	public void produce() {
		System.out.println("海尔厂商");
	}

}

 

这样就使用了桥模式，将原本繁杂的系统分离开来。如果根据需求变动，要增加电视机生产型号或者电视机生产厂商，只需要实现相对应的抽象类即可。

这样，我们也可以根据用户的需要，得到他所需要的电视机，如长虹厂商出厂的29寸电视机。

测试代码如下：

public class Client {

	public static void main(String[] args) {
		// TODO Auto-generated method stub
		Inch29 i = new Inch29();
		i.teleview(new ChangHong());
	}
}

 结果：

       长虹厂商
       29寸电视

 

这便达到我们所需要的效果了。希望朋友指出错误与不到指出，谢谢

e..我怎么记得bridge模式的关键是产品是由元素组成的，把元素用接口表述。
这样就封装了底层实现，产品的元素拼装过程不需要再去重复修改。如果需要添加不同实现，则直接继承元素接口进行扩展。貌似这个例子不是这样的表述吧..我很久没看dp了。可能记错

所以用bridge的关键在于是否确知了上层不会轻易发生变化。。

GOF说的是"将抽象部分与它的实现部分分离，使它们都可以独立地变化",各人理解都是不一样的。有些模式从某种意义上来说，很广泛。

把握不当也许就要变成适配器了

你也许记成了builde模式吧

 
    23种模式，不是万能模式，每个都不是完美模式。在学23种模式，要学23种模式后面中深层的东西--------这是个人的观点。我在实际使用中，不是先想到用什么模式，再用该模式的实现。也就是说我不是为了模式而模式；在实践使用中我根本没有模式的概念了。前一阵子，看到各个模式的名称，居然没有印象了。（掌握各个模式的体含义的好处在于，方便沟通交流。在实际使用中，没有模式概含罢了）

    这个桥模式，说实在的，核心实现也就是适配器的实现方式----------对象注入。桥模式与适配器模式，仅仅是各个类由于具体的场景不同而含义不同罢了。在实践中，如何自然区分他们呢？把握设计模式的一个原则即可----------封装变化点。
    下面是来自李建忠讲师的讲义：
   
    其中意图，可简单理解成定义。

    桥模式，是两个维度的变化(从GOF给出的UML类图中看)。 如果一个对象，在实际需求中，有两个维度的变化（如：产品的型号规格与生产厂家都在变），我们要封装化点。自然的，各个维度都接定义一个接口，然后再采用对象注入，让两个接口以弱耦合的方式连接起来 。

   如果，不掌握最深成的东西，我们无法得心应手的使用设计模式。举个例子：

   当一个对象，是按三维、四维、五维。。。。。进行变化，我们选用什么设计模式？

  每个维度都用接口与该接口的实现进行规范，用户使用时，尽可能使用接口进行操作，而仅仅是接口，程序是无法运行的，因此向要接口中注入对象。 
  在以上的场景中，我们用的是桥接模式？还是适配模式？  如果每个该对象除了有多个维度在变化，而各个维度中的功能也在不断变化，又怎么实现呢？ 每个维度中，又有许多的其他对象组成，而这些对象也在变化怎么办？

  在这种复杂的变化中，这个整体又将用什么模式？能简单归成二十三种模式中的哪一种呢？


  至于适配器模式，从需求上看-----仅仅是让一个接口标准遵循另一接口标准。从实现上看，与桥模式大体相同，即
对象注入。不同在于，桥模式的，允许多个对象注入（引申一下：当非常复杂时，这些注入的对象管理就特重要了，这里用上一个被许多初学者认为没有用的东东-----数据结构。）。而GOF给出的实现中，仅注入了一个对象罢了。



  ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
在这里，不是针对fjlyxx进行反驳。filyxx也说得在理。在这里，仅仅是借其话题，引入自已对设计模式的一些理解与观点。 在二十三种设计模式中，其后面深层次的东西，更应该研究学习。


  

桥模式能实现类似于多继承的咚咚阿

你也许记成了builde模式吧



这是什么东西？builder?不会滴，builder是组装对象用的。和bridge不同