继承的弊端：
有这么一个情况：
你想要创建一个只有嘴巴的机器人类，并且这个机器人类只有一个行为：嘴巴吃东西。
你发现动物这个类有嘴巴，并且会吃东西，好，这就方便了，机器人类直接继承动物类。继承完毕，机器人有嘴巴了，但是嘴巴不仅会吃东西，还会说话了。你本身并不需要它会说话呀。这就是继承带来的坏处，带来了并不需要的属性或者行为方法。
这时候你又想，没事，想办法不让外界使用到这些多余的方法不就行了嘛。这时候两个办法：
方法1、把多余的行为方法都覆写一遍，改成你想透出给外界的方法。
方法2、换一个类继承。
上面两个方法看起来是不是都很变态，第一个方法你要覆写的方法可能会很多很多，多到你自己都搞不清楚了。第二个方法一样可能会继承到很多并不需要的属性或者行为方法。好，这个问题先告诉你可以用组合来解决，再来看另一个问题：
比如你不仅想让机器人用嘴吃东西，还想它会做瑜伽。这时候怎么办，继承只能单继承呀。
回头来看组合。
组合的优点：
组合的意思就是把你需要的东西组合在一个类里面，这个类并不需要继承任何父类，也可以提供想要的行为方法。
比如说上面的例子，我们可以创建一个机器人类，内部有一个动物对象，机器人类对外透出一个吃东西的方法，内部调用动物对象的嘴巴吃东西。这个时候从外部来看，嘴巴只会吃东西了，而不会说话。这个时候对于动物类来说模式就是组合，而不是继承。并且如果你想让机器人会做瑜伽，可以再内部创建一个会做瑜伽的类的对象，调用做瑜伽方法，或者实现一个做瑜伽的接口，实现接口的做瑜伽方法。
这样就可以避免单继承，而无限扩展。并且可以做到不用关心无用的方法。
Adapter设计模式：
很多模式都用到了组合，继续上面例子
假设机器人内部已经存在一个会跳芭蕾舞的对象，此对象有一个跳芭蕾舞的行为，这时候有个接口，名字叫“舞者”，“舞者”中有一个方法叫“表演天鹅湖”，想让机器人表演天鹅湖的话就可以让机器人实现“舞者”这个接口，在“表演天鹅湖”这个行为的内部调用的芭蕾舞对象的跳芭蕾舞方法。
这就是Adapter设计模式。Adapter模式就是将一个已经存在的类，转换为目标接口所期望的行为形式。
再比如Decorator模式：
现在你要开一家奶茶店，卖抹茶奶茶、红茶奶茶、柠檬养乐多奶茶、波霸奶茶等等等各种奶茶。
那么就创建各种子类来继承奶茶类就好了呀，这时候我们得到了：MatchaMilkyTea、Black MilkyTea、LemonYLDMilkyTea、等等，好多子类啊，这就是继承导致类的无限膨胀，这还没有结束，每一种奶茶还可能加冰、加糖等等各种选项，就要给每种子类都加一个冰和糖的选项。。有人会说不能吧冰和糖的选项给加到奶茶这个父类中吗？这看起来确实是一个捷径，但是仔细想想以后还可能会有温度、椰果、补丁等等选项，都要加到父类中去吗？明显不合适。
我们来看看Decorator模式是如何解决上面这个问题的：
装饰者模式的抽象概念：不改变原有类（奶茶）的情况下，进行行为扩展（加糖、加冰），并且是动态的，想怎么组合都可以。可以想象成俄罗斯套娃，最里面的那个娃就是要被装饰的原有类，外面每套一层娃就是一层装饰。
所以不管你怎么装饰嵌套组合，所有层的类型其实都是“娃娃”这个类型，不是小狗类型、也不是小猫类型。也就是说装饰类是实现或者继承了被装饰类的。
再回到我们的奶茶：
我们把冰、糖、椰果等等这些统统称作“额外选项”
然后按以下步骤来操作：
1、我们现在有一个奶茶的原有类：其中有奶茶名称，和对应的get方法。还有一个“抹茶奶茶”类继承自奶茶类。
public class MilkyTea{
public String teaName="我是一个奶茶";
public String getTeaName() {
return teaName;
}
}
public class MatchaMilkyTea extends MilkyTea {
public MatchaMilkyTea() {
teaName = "抹茶奶茶";
}
}
2、现在我们要对奶茶进行装饰，先创建一套装饰的标准，于是创建一个名字叫“额外选项装饰”的抽象类，继承奶茶类（刚才说了，俄罗斯套娃的所有层都是同一个类型），里面有一个获取奶茶名称的抽象方法，用来打印奶茶的名称。
public abstract class ExtraOptionsDeco extends MilkyTea {
public abstract String getTeaName();
}
3、创建一个类，名字叫“糖”，继承“额外选项装饰器”的类，有一个“奶茶”类的属性，并且在构造函数中赋值，实现获取奶茶名称的方法，把传入的奶茶对象的名称和“加糖”组合起来返回出去。
public class Sugar extends ExtraOptionsDeco{
private MilkyTea milkyTea;
public Sugar(MilkyTea arg) {
this.milkyTea = arg;
}
@Override
public String getTeaName() {
return milkyTea.getTeaName()+"加糖";
}
}
4、同样方法创建一个类，名字叫“冰”：
public class Ice extends ExtraOptionsDeco{
private MilkyTea milkyTea;
public Ice(MilkyTea arg) {
this.milkyTea = arg;
}
@Override
public String getTeaName() {
return milkyTea.getTeaName()+"加冰";
}
}
5、测试一下
客户想要抹茶奶茶，并且加糖
public static void main(String[] args) {
MilkyTea matchaMilkyTea = new MatchaMilkyTea();
Sugar sugar = new Sugar(matchaMilkyTea);
System.out.println(sugar.getTeaName());
}
输出：
抹茶奶茶加糖
如果用户想要抹茶奶茶加冰又加糖
MilkyTea matchaMilkyTea = new Sugar(new Ice(new MatchaMilkyTea()));
System.out.println(matchaMilkyTea.getTeaName());
输出：
抹茶奶茶加冰加糖
可以看到，并没有在抹茶奶茶等奶茶的子类中去一一添加加冰、加糖等行为，也实现了需求。装饰模式把类中装饰和核心职责区分开来，使原有的类职责更单一，没有添加多余的职责，并且可以动态的添加行为。
