桥接模式--继承并不一定总是最优

或许一般敲代码时，总会想到用继承或者实现接口的方式来使得代码结构最清晰，

最易于维护。

但是呢，正如标题所说的，并不是所有的情况继承都是最好的。

看下面一个例子。

在过去传统手机时代，也就是诺基亚称王的时代，当时不同的手机软件是互相

不兼容的（不像现在就两个操作系统Android和IOS）。那么问题来了类结构应该如何设计呢？

先看下面这个类图：

再进一步就是这样：

这就是很正经的通过继承关系来优化的，垂直下来。

试想，如果还要增加一个音乐软件，那么左边M要加一个类，右边N也要加一个类。

如果继续增多，每多一个软件，2个类，这样如果软件数量庞大，

那可能会发展成不可控制的庞然大物！

接下来就是重点来了，不通过继承来，而通过聚合的方式来，

也就是桥接模式。这里先将一个原则：

合成/聚合福永原则(CARP):尽量使用合成/聚合，尽量不要使用类继承。

这个原则的好处是，优先使用对象的合成/聚合将有助于你保持每个类被封装，

并且被集中在单个任务上。这样类和类继承层次会保持较小规模，并且不会增长为庞然大物。

接下来看桥接模式类图：

从这里面可以看出，HandsetBrand和HandsetSoft直接通过聚合的方式联系了起来，

可能单单从类图并没有发现太多优点，下面看具体类代码：

HandsetSoft类：

package com.blog.anla.Bridge;
/**
 * s手机软件抽象类
 * @author U-ANLA
 *
 */
public abstract class HandsetSoft {
	public abstract void run();
}

HandsetGame类：

package com.blog.anla.Bridge;

public class HandsetGame extends HandsetSoft{

	@Override
	public void run() {
		System.out.println("运行手机游戏");
	}
}	

HandsetAddressList类：

package com.blog.anla.Bridge;

public class HandsetAddressList extends HandsetSoft{

	@Override
	public void run() {
		System.out.println("运行手机通讯录");
	}

}

HandsetBrand类：

package com.blog.anla.Bridge;
/**
 * 手机品牌抽象类
 * @author U-ANLA
 *
 */
public abstract class HandsetBrand {
	protected HandsetSoft soft;
	
	public void setHandsetSoft(HandsetSoft soft){
		this.soft = soft;
	}
	
	public abstract void Run();
}

HandsetBrandM类：

package com.blog.anla.Bridge;

public class HandsetBrandM extends HandsetBrand{
	@Override
	public void Run() {
		soft.run();
	}

}

HandsetBrandN类：

package com.blog.anla.Bridge;

public class HandsetBrandN extends HandsetBrand{

	@Override
	public void Run() {
		soft.run();
	}
	
}

这里体现了依赖倒转原则：抽象不依赖于细节，而细节依赖于抽象。

手机品牌M,N并没有直接运行M软件N软件，而是交给HandsetSoft去运行。

慢慢去理解吧嘿嘿

赠人玫瑰手留余香（oo）