桥接模式《设计模式》

题目：试想一下，你开一家餐馆，菜的类别。分为肉类，青菜类，汤类，然后不同的类别都有大份儿中份儿小份儿。现在客户端需要计算需要根据客人点的餐算出可人所需要付的金额。 给大家三分钟的思考时间。

。。。

好了，时间到了，面对题目我们首先的想法，估计很多都是这样的

我们可以看到大家大概会设计出类似这种的类。同理青菜类 以及汤类。
但是试想一下，如果这个时候，客户说由于客人觉得大分量的还是分量不是很足，这个时候需要添加超大份儿的类别。这个时候我们需要在三个地方分别添加一个超大类别的类。如果开发出了一个新的产品类别，则这个产品类别也要重复添加4份额种类。这样虽然也是符合开闭的设计原则，但是代码的重用性特别的不好。
所以这个时候如果我们使用桥接模式来解决这个问题，就会比较的合适。（多维度问题才用桥接模式）

如图：
如此的设计图，有利于，当我们再加入新的产品种类的时候，例如添加超大份儿的时候则只需要在volumnType的子类中完成添加就行了，不用给每个foodType添加了。如果需要添加foodType则只需要添加一个类新的事物类别就行了，也不需要给新的食物类别添加VolumeType 。

好的现在大家思考这样的一个问题，我们根据现在的设计图，是使用继承完成这个题目还是使用组合完成这个题目呢。三分钟。

。。。

好的时间到。
我们知道在设计原则中有一个叫做，favor composition than inheritance .
好了下面是代码的书写时间。

public interface FoodType{    abstract double getPrice();}public interface VolumeType{    // 0 small 1 middle 2 big    public int abstract getVolumeNumber();}public class Big implements VolumnType{    public int getVolumeNumber(){        // this is will provide accordingly         return volumePrice;    }}// the same with middle and small public class Meat implements FoodType{    private VolumeType volType;    // init volType in contructor    // <warning>the VolumeType will passing in as needed by the client .     //and when we are designing an program we should keep in mind what the     //client will off what i can do to make it the client convenient as much as possible <warning>    public Meat(VolumeType type){        volType = type;    }    public double getPrice(){        return meatPrice * volType.getVolumeNumber();    }}// the same as Vegetable and soup .

总结：
桥接模式是解决多维度分类的常见方式。