在面向对象的编程中，有一条非常经典的设计原则：组合优于继承，多用组合少用继承。什么不推荐使用继承？组合比继承有哪些优势？
为什么不推荐使用继承？
继承是面相对象的四大特性之一，用来表示类之间的is-a关系，可以解决代码复用的问题。虽然继承有诸多作用，但继承层次过深、过复杂，也会影响到代码的可维护性。所以对于项目中是否应该使用继承有很多争议，很多人觉得继承是一种反模式，应该尽量少用，甚至不用。为什么会有这样的争议？我们通过一个例子来解释一下。
假设我们要设计一个关于鸟的类。我们将“鸟类”这样一个抽象的事物概念，定义为一个抽象的类AbstractBird。所有更细分的鸟，比如麻雀、鸽子、乌鸦等，都继承这个抽象类。
我们都知道，大部分鸟会飞，那我们可不可以在AbstractBird抽象类中，定义一个fly()方法呢？答案是否定的。尽管大部分鸟会飞，但也有特例，比如鸵鸟就不会飞。鸵鸟继承具有fly()方法的父类，那鸵鸟就具有“飞”的这样的行为，显然是不合情理的。当然你可能会说，在鸵鸟这个子类中重写（overwride）fly()方法，让它抛出UnsupportedMethodException异常不就可以了吗？具体的实现代码如下所示:
public class AbstractBird {
//...省略其他属性和方法...
public void fly() { //... }
}
public class Ostrich extends AbstractBird { //鸵鸟
//...省略其他属性和方法...
public void fly() {
throw new UnSupportedMethodException("I can't fly.'");
}
}
这种设计思路虽然可以解决问题，但不够优雅。因为除了鸵鸟之外，不会飞的鸟还有很多，比如企鹅。对于这些不会飞的鸟来说，我们都需要重写fly()方法，抛出异常。这样的设计，一方面徒增了编码的工作量;另一方面，也违背了我们所说的最小知识原则（Least Knowledge Principle，也叫最小知识原则或者迪米特法则），暴露不该暴露的接口给外部，增加类使用过程中被误用的概率。
你可能又会说，那我们再通过AbstractBird类派生出两个更加细分的抽象类：会飞的鸟类AbstractFlyableBird和不会飞的鸟类AbstractUnFlyableBird。继承关系如下图:
从整体上来看，继承关系比较简单，层次比较浅，也算一种可以接受的设计思路。那如果我们还关注“鸟会不会叫“，那这个时候我们又该如何设计类之间的继承关系呢？
是否会飞？是否会叫？这两个行为搭配起来就会产生四种情况。如果我们还需要关注“是否会下蛋”这样一个行为，那估计就要组合爆炸了。类的层次越来越深，继承关系越来越复杂。
总之，继承最大的问题就在于：继承层次过深，继承关系过于复杂影响到代码的可读性和可维护性。
组合相比继承有哪些优势？
实际上我们可以利用组合（composition）、接口、委托（delegation）三个技术手段一块来解决刚刚继承存在的问题。
接口表示具有某种行为特征。针对“会飞”这样一个行为特性，我们可以定义一个Flyable接口，只让会飞的鸟去实现这个接口。对于会叫，会下蛋这些行为特性，我们可以类似的定义Tweetable、EggLayable接口。就是下面这个样子：
public interface Flyable {
void fly();
}
public interface Tweetable {
void tweet();
}
public interface EggLayable {
void layEgg();
}
public class Ostrich implements Tweetable, EggLayable {//鸵鸟
//... 省略其他属性和方法...
@Override
public void tweet() { //... }
@Override
public void layEgg() { //... }
}
public class Sparrow impelents Flayable, Tweetable, EggLayable {//麻雀
//... 省略其他属性和方法...
@Override
public void fly() { //... }
@Override
public void tweet() { //... }
@Override
public void layEgg() { //... }
}
不过，我们知道，接口只声明方法，不定义实现。也就是说每个会下蛋的鸟都要实现一遍layEgg()方法，并且实现逻辑都是一样的，这就导致代码重复的问题。如何解决呢？
我们可以针对三个接口再定义三个实现类，通过组合和委托技术来消除代码重复：
public interface Flyable {
void fly()；
}
public class FlyAbility implements Flyable {
@Override
public void fly() { //... }
}
//省略Tweetable/TweetAbility/EggLayable/EggLayAbility
public class Ostrich implements Tweetable, EggLayable {//鸵鸟
private TweetAbility tweetAbility = new TweetAbility(); //组合
private EggLayAbility eggLayAbility = new EggLayAbility(); //组合
//... 省略其他属性和方法...
@Override
public void tweet() {
tweetAbility.tweet(); // 委托
}
@Override
public void layEgg() {
eggLayAbility.layEgg(); // 委托
}
}
如何判断该用组合还是继承？
尽管我们鼓励多用组合少用继承，但组合也并不是完美的，继承也并非一无是处。从上面例子来看，继承改写成组合意味着要做更细粒度的类的拆分。这就意味着我们要定义更多的类和接口，或多或少的增加代码复杂程度和维护成本。所以，在实际的项目开发中，我们还是要根据具体的情况，来具体选择。
如果类之间的继承结构稳定，不会轻易改变，继承层次比较浅，比如最多有两层继承关系，继承关系不复杂，我们就可以大胆的使用继承。
反之，系统越不稳定，继承层次很深，继承关系复杂，我们就尽量使用组合代替继承。
除此之外，还有一些设计模式会固定使用继承或者组合。比如，装饰者模式、策略模式、组合模式等都使用了组合关系，而模板模式使用了继承。
