在面向对象编程中、有一条非常经典的设计原则，那就是：组合优于继承，多用组合少用继承。为什么不推荐使用继承？组合相比继承有哪些优势？如何判断该用组合还是继承？今天,我们就围绕着这三个问题，来详细讲解一下这条设计原则。

话不多说、让我们正式开始今天的学习吧！

为什么不推荐使用继承？

继承是面向对象的四大特性之一、用来表示类之间的is-a关系,可以解决代码复用的问题。虽然继承有诸多作用，但继承层次过深、过复杂,也会影响到代码的可维护性。所以,对于是否应该在项目中使用继承,网上有很多争议。很多人觉得继承是一种反模式,应该尽量少用，甚至不用。为什么会有这样的争议？我们通过一个例子来解释一下。

假设我们要设计一个关于鸟的类。我们将“鸟类”这样一个抽象的事物概念，定义为一个抽象类AbstractBird。所有更细分的鸟,比如麻雀、鸽子、乌鸦等,都继承这个抽象类。

我们知道、大部分鸟都会飞,那我们可不可以在AbstractBird抽象类中,定义一个fly0方法呢?答案是否定的。尽管大部分鸟都会飞,但也有特例,比如鸵鸟就不会飞。鸵鸟继承具有fly0方法的父类,那鸵鸟就具有“飞”这样的行为,这显然不符合我们对现实世界中事物的认识。当然，你可能会说,我在鸵鸟这个子类中重写(override) fly0方法,让它抛出UnSupportedMethodException异常不就可以了吗?具体的代码实现如下所示：

public class AbstractBird {
    //...省略其他属性和方法....
    public void fly() { //... }
    public class Ostrich extends AbstractBird {
        //鸵鸟
        //...省略其他属性和方法....
    }
    public void fly() {
        throw new UnSupportedMethodException("I can't fly.'");
    }
}

这种设计思路虽然可以解决问题，但不够优美。因为除了鸵鸟之外，不会飞的鸟还有很多，比如企鹅。对于这些不会飞的鸟来说，我们都需要重写fly0方法,抛出异常。这样的设计,一方面,徒增了编码的工作量;另一方面,也违背了我们之后要讲的最小知识原则(Least Knowiedge Principle,也叫最少知识原则或者迪米特法则) ,暴露不该暴露的接口给外部,增加了类使用过程中被误用的概率。

你可能又会说,那我们再通过AbstractBird类派生出两个更加细分的抽象类:会飞的鸟类AbstractFlyableBird和不会飞的鸟类AbstractUnFlyableBird，让麻雀、乌鸦这些会飞的鸟都继承AbstractFlyableBird，让鸵鸟、企鹅这些不会飞的鸟，都继承AbstractUnFlyableBird类，不就可以了吗？具体的继承关系如下图所示：

从图中我们可以看出，继承关系变成了三层。不过，整体上来讲，目前的继承关系还比较简单，层次比较浅，也算是一种可以接受的设计患路。我们再继续加点难度。在刚刚这个场景中,我们只关注“鸟会不会飞”,但如果我们还关注“鸟会不会叫”,那这个时候,我们又该如何设计类之间的继承关系呢？

是否会飞？是否会叫？两个行为搭配起来会产生四种情况：会飞会叫、不会飞会叫、会飞不会叫、不会飞不会叫。如果我们继续沿用刚才的设计思路,那就需要再定义四个抽象类(AbstractFlyableTweetableBird、AbstractFlyableUnTweetableBird、AbstractUnFlyableTweetableBird, AbstractUnFlyableUnTweetableBird) 。

如果我们还需要考虑“是否会下蛋”这样一个行为，那估计就要组合爆炸了。类的继承层次会越来越深、继承关系会越来越复杂。而这种隆次很深、很复杂的继承关系，一方面，会导致代码的可读性变差。因为我们要搞清楚某个类具有哪些方法、属性、必须词读父类的代码、父类約父类的代码……一直追溯到最顶层父类的代码。另一方面,这也破坏了类的封装特性,将父类的实现细节条露给了子类。子类的实现依赖父类的实现，两者高度耦合，一旦父类代码修改，就会影响所有子类的逻辑。

总之,继承最大约问题就在于:继承层次过深、继承关系过于复杂会影响到代码的可读性和可维护性,这也是为什么我们不推春使用继承。那刚刚例子中继承存在的问题，我们又该如何来解决呢？你可以先自己思考一下，再听我下面的讲解。

组合相比继承有哪些优势？

实际上,我们可以利用组合(composition) 、接口、委托(delegation)三个技术手段,一缺儿来解决刚刚继承存在的问题.

我们前面讲到接口的时候说过,接口表示具有某种行为特性。针对"会飞"这样一个行为特性,我们可以定义一个Flyable接口,只让会飞的鸟去实现这个接口。对于会叫、会下蛋这些行为特性,我们可以类似地定义Tweetable接口、EggLayable接口。我们将这个设计思路翻译成Java代码的话，就是下面这个样子:

public interface Flyable (void fly();
public interface Tweetablevoid tweet();
public interface EggLayable void layEgg();
public class Ostrich implements Tweetable, EggLayable {
    //鸵鸟//...省略其他属性和方法...
    @override
    public void tweet() { //... }
    @override
    public void layEgg() { //... }
}
public class Sparrow implements Flyable, Tweetable, EggLayable (
    //麻雀//... 省略其他属性和方法....
    @override
    public void fly() { //... }
    @override
    public void tweet() { //... }
    @override
    public void layEgg() { //... }
}

不过，我们知道，接口只声明方法,不定义实现。也就是说，每个会下蛋的鸟都要实现一遍layEgg0方法,并且实现逻辑是一样的,这就会导致代码重复的问题。那这个问题又该如何解决呢?

我们可以针对三个接口再定义三个实现类,它们分别是:实现了fly0方法的FlyAbility类、实现了tweet0方法的TweetAbility类、实现了layEgg0方法的EggLayAbility类。然后,通过组合和委托技术来消除代码重复。具体的代码实现如下所示:

public interface Flyable {
    void fly();
}
public class FlyAbility implements Flyablefoverride
    public void fly() { //... }
    //省略Tweetable/TweetAbility/EggLayable/EggLayAbility一
    public class Ostrich implementB Tweetable, EggLayable (//鸵鸟
    private TweetAbility tweetAbility = new TweetAbility(); //组合
    private EggLayAbility eggLayAbility = new EggLayAbility(); //组合//... 省略其他属性和方法...
    @override
    public void tweet() {
    tweetAbility.tweet(); // 委托
    }
    @override
    public void layEgg() {
    eggLayAbility.layEgg(); // 委托一
    }
}

我们知道继承主要有三个作用:表示is-a关系,支持多态特性,代码复用。而这三个作用都可以通过其他技术手段来达成。比如is-a天系,我们可以通过组合和接口的has-a关系来替代;多态特性我们可以利用接口来实现;代码复用我们可以通过组合和委托来实现。所以,从理论上讲,通过组合、接口、委托三个技术手段,我们完全可以替换掉继承,在项目中不用或者少用继承关系,特别是一些复杂的继承关系。

如何判断该用组合还是继承？

尽管我们鼓励多用组合少用继承,但组合也并不是完美的,继承也并非一无是处。从上面的例子来看,继承改写成组合意味着要做更细粒度的类的拆分。这也就意味着,我们要定义更多的类和接口。类和接口的增多也就或多或少地增加代码的复杂程度和维护成本。所以,在实际的项目开发中,我们还是要根据具体的情况,来具体选择该用继承还是组合。

如果类之间的继承结构稳定(不会轻易改变) ,继承层次比较浅(比如,最多有两层继承关系) ,继承关系不复杂,我们就可以大胆地使用继承。反之,系统越不稳定,继承层次很深,继承关系复杂,我们就尽量使用组合来替代继承。

除此之外,还有一些设计模式会固定使用继承或者组合。比如,装饰者模式(decorator pattern) 、策略模式(strategy pattern) 、组合模式(composite pattern)等都使用了组合关系,而模板模式(template pattern)使用了继承关系。

前面我们讲到继承可以实现代码复用。利用继承特性,我们把相同的属性和方法,抽取出来,定义到父类中。子类复用父类中的属性和方法,达到代码复用的目的。但是,有的时候,从业务含义上, A类和B类并不一定具有继承关系。比如,Crawler类和PageAnalyzer类,它们都用到了URL拼接和分割的功能,但并不具有继承关系(既不是父子关系,也不是兄弟关系) 。仅仅为了代码复用,生硬地抽象出一个父类出来，会影响到代码的可读性。如果不熟悉背后设计思路的同事，发现Crawler类和PageAnalyzer类继承同一个父类，而父类中定义的却只是URL相关的操作,会觉得这个代码写得莫名其妙,理解不了。这个时候,使用组合就更加合理、更加灵活。具体的代码实现如下所示：

public class Crawler{
    private Url url; 
    public Crawler(){
        this.url new Url();
    }
}
//...
public class PageAnalyzer {
    private Url url; // 組合
    public PageAnalyser() {
        this.url = new Url();
    }
}

还有一些特殊的场景要求我们必须使用继承。如果你不能改变一个函数的入参类型，而入参又非接口，为了支持多态，只能采用继承米买现。比如下面这样一段代码,其中FeignClient是一个外部类,我们没有权限去修改这部分代码,但是我们希望能重写这个类在运行时执行的encode()函数。这个时候，我们只能采用继承来实现了。

public class FeignClient { 
    // Feign Client框架代码//...省略其他代码...
    public void encode(String url) { 
    //... 
    }
    public void demofunction(FeignClient feignclient){//...
        feignClient.encode(url);//...
    }
}
public class CustomizedFeignClient extends Feignclient {
    @override
    public void encode(String url) { //..重写encode的实现...}d
        // 调用
        FeignClient client = new CustomizedFeignClient();
        demofunction(client);
    }
}

尽管有些人说,要杜绝继承, 100%用组合代替继承,但是我的观点没那么极端!之所以“多用组合少用继承”这个口号喊得这么响,只是因为,长期以来,我们过度使用继承。还是那句话,组合并不完美,继承也不是一无是处。只要我们控制好它们的副作用、发挥它们各自的优势,在不同的场合下,恰当地选择使用继承还是组合,这才是我们所追求的境界。

重点回顾

到此，今天的内容就讲完了。我们一块儿来回顾一下，你需要重点掌握的知识点。

1.为什么不推荐使用继承？

继承是面向对象的四大特性之一，用来表示类之间的is-a关系,可以解决代码复用的问题。虽然继承有诸多作用、但继承层次过深、过复杂，也会影响到代码的可维护性。在这种情况下，我们应该尽量少用，甚至不用继承。2.组合相比继承有哪些优势？

MacBook Pro继承主要有三个作用:表示is-a关系,支持多态特性,代码复用。而这三个作用都可以通过组合、接口、委托三个技术手段来达成。除此之外，利用组合还能解决层次过深、过复杂的继承关系影响代码可维护性的问题。

3.如何判断该用组合还是继承？

尽管我们鼓励多用组合少用继承,但组合也并不是完美的,继承也并非一无是处。在实际的项目开发中,我们还是要根据具体的情况,来选择该用继承还是组合。如果类之间的继承结构稳定,层次比较浅,关系不复杂,我们就可以大胆地使用继承。反之,我们就尽量使用组合来替代继承。除此之外,还有一些设计模式、特殊的应用场景,会固定使用继承或者组合。

课堂讨论

我们在基于MVC架构开发Web应用的时候,经常会在数据库层定义Entity,在Service业务层定义BO (Business Object) ,在Controller接口层定义VO (View Object) 。大部分情况下, Entity、BO、 VO三者之间的代码有很大重复,但又不完全相同。我们该如何处理Entity、BO、VO代码重复的问题呢？