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

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

最易于维护。

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

看下面一个例子。

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

不兼容的（不像现在就两个操作系统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）