前言：
最近有一个要好的朋友去阿里大厂面试Java高级工程师，在第二轮面试的过程中，面试官提了一个问题：“解释下Java项目中为什么要求多用组合，少用继承？”。朋友觉得这个题目既熟悉，又陌生，毕竟继承与组合在一开始学习Java时就要求掌握的，但是教学过程中只是说了它们的概念及基本理论知识，没有介绍它们之间孰优孰弱的问题，实际开发中也没有刻意去将它们进行比较。一时间竟然答不上来。那么面试官为什么要问这个问题呢？
回来后，查阅了一些资料，发现在《Effective Java》一书中的第16条提到“组合优先于继承”，原来这是在面向对象编程中的一条非常经典的设计原则，那就是：组合优于继承，多用组合少用继承。那继承到底会暴露什么问题呢？为什么更推荐优先使用组合呢？我们先来了解继承与组合的概念。
一、概念
1、什么是继承
继承（Inheritance）是一种联结类与类的层次模型。指的是一个类（称为子类、子接口）继承另外的一个类（称为父类、父接口）的功能，并可以增加它自己的新功能的能力，继承是类与类或者接口与接口之间最常见的关系；继承是一种is-a关系。（图片来自网络，侵删。）
2、什么是组合
组合(Composition)是一种较弱的关系，体现的是整体与部分、拥有的关系，即has-a的关系。
二、继承会带来什么问题？
1、初步问题
假设我们要设计一个关于鸟的类。我们将“鸟类”这样一个抽象的事物概念，定义为一个抽象类 AbstractBird，默认有eat吃东西的行为。所有更细分的鸟，比如麻雀、鸽子、鸵鸟等，都继承这个抽象类。
public class AbstractBird {
//... 省略其他属性和方法...
public void eat() {
//... }
}
// 鸵鸟
public class Ostrich extends AbstractBird {
}
但是，这时候搞不清楚情况的人根据需求给AbstractBird添加一个fly()的行为。但是对于鸵鸟这个子类来说，并不会飞，你如果不做任何处理，相当于让鸵鸟有了飞翔的功能，不符合设计。聪明的你想到了，那就重写以下吧，抛出一个异常，如下所示：
public class AbstractBird {
//... 省略其他属性和方法...
public void eat() {
//... }
public void fly() {
//... }
}
// 鸵鸟
public class Ostrich extends AbstractBird {
//... 省略其他属性和方法...
public void fly() {
throw new UnSupportedMethodException("I can't fly.'");
}
}
这种设计思路虽然可以解决问题，但不够优美。因为除了鸵鸟之外，不会飞的鸟还有很多，比如企鹅。对于这些不会飞的鸟来说，我们都需要重写 fly() 方法，抛出异常。而且真正好的设计，对于鸵鸟和企鹅来说，就不应该暴露给他们fly()这种不该暴露的接口，增加外部调用的负担。
这里只提到了fly(),如果还有下蛋egg()、唱歌sing()这么多行为，总不能都冗杂在父类里吧。关键像我们的项目同事，基本上把所有的类都写到了父类中，真的特别难以维护。
2、改进后遇到的问题
我们通过 AbstractBird 类派生出两个更加细分的抽象类：会飞的鸟类AbstractFlyableBird 和不会飞的鸟类 AbstractUnFlyableBird，让麻雀、乌鸦这些会飞的鸟都继承 AbstractFlyableBird，让鸵鸟、企鹅这些不会飞的鸟，都继承AbstractUnFlyableBird 类。
具体的继承关系如下图所示：
从图中我们可以看出，继承关系变成了三层。不过，整体上来讲，目前的继承关系还比较简单，层次比较浅，也算是一种可以接受的设计思路。我们再继续加点难度。在刚刚这个场景中，我们只关注“鸟会不会飞”，但如果我们还关注“鸟会不会叫”，那这个时候，我们又该如何设计类之间的继承关系呢？
3、再改进后的问题
是否会飞？是否会叫？两个行为搭配起来会产生四种情况：会飞会叫、不会飞会叫、会飞不会叫、不会飞不会叫。如果我们继续沿用刚才的设计思路，那就需要再定义四个抽象类（AbstractFlyableTweetableBird、AbstractFlyableUnTweetableBird、AbstractUnFlyableTweetableBird、AbstractUnFlyableUnTweetableBird）。
如果我们还需要考虑“是否会下蛋”这样一个行为，那估计就要组合爆炸了。类的继承层次会越来越深、继承关系会越来越复杂。而这种层次很深、很复杂的继承关系，一方面，会导致代码的可读性变差。因为我们要搞清楚某个类具有哪些方法、属性，必须阅读父类的代码、父类的父类的代码……一直追溯到最顶层父类的代码。另一方面，这也破坏了类的封装特性，将父类的实现细节暴露给了子类。子类的实现依赖父类的实现，两者高度耦合，一旦父类代码修改，就会影响所有子类的逻辑。
总之，继承最大的问题就在于：继承层次过深、继承关系过于复杂会影响到代码的可读性和可维护性。这也是为什么我们不推荐使用继承。那刚刚例子中继承存在的问题，我们又该如何来解决呢？你可以先自己思考一下，再听我下面的讲解。
三、组合相比继承有哪些优势？
实际上，我们可以利用组合（composition）、接口、委托（delegation）三个技术手段，一块儿来解决刚刚继承存在的问题。
我们前面讲到接口的时候说过，接口表示具有某种行为特性。针对“会飞”这样一个行为特性，我们可以定义一个Flyable接口，只让会飞的鸟去实现这个接口。对于会叫、会下蛋这些行为特性，我们可以类似地定义Tweetable接口、EggLayable接口。我们将这个设计思路翻译成Java代码的话，就是下面这个样子：
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 Flyable, Tweetable, EggLayable {
//麻雀
//... 省略其他属性和方法...
@Override
public void fly() {
//... }
@Override
public void tweet() {
//... }
@Override
public void layEgg() {
//... }
}
不过，我们知道，接口只声明方法，不定义实现。也就是说，每个会下蛋的鸟都要实现一遍layEgg()方法，并且实现逻辑是一样的，这就会导致代码重复的问题。那这个问题又该如何解决呢？
我们可以针对三个接口再定义三个实现类，它们分别是：实现了fly()方法的FlyAbility类、实现了tweet()方法的TweetAbility类、实现了layEgg()方法的EggLayAbility类。然后，通过组合和委托技术来消除代码重复。具体的代码实现如下所示：
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(); // 委托
}
}
我们知道继承主要有三个作用：表示is-a关系，支持多态特性，代码复用。而这三个作用都可以通过其他技术手段来达成。比如is-a关系，我们可以通过组合和接口的has-a关系来替代；多态特性我们可以利用接口来实现；代码复用我们可以通过组合和委托来实现。所以，从理论上讲，通过组合、接口、委托三个技术手段，我们完全可以替换掉继承，在项目中不用或者少用继承关系，特别是一些复杂的继承关系。
四、如何判断该用组合还是继承？
尽管我们鼓励多用组合少用继承，但组合也并不是完美的，继承也并非一无是处。从上面的例子来看，继承改写成组合意味着要做更细粒度的类的拆分。这也就意味着，我们要定义更多的类和接口。类和接口的增多也就或多或少地增加代码的复杂程度和维护成本。所以，在实际的项目开发中，我们还是要根据具体的情况，来具体选择该用继承还是组合。
如果类之间的继承结构稳定（不会轻易改变），继承层次比较浅（比如，最多有两层继承关系），继承关系不复杂，我们就可以大胆地使用继承。反之，系统越不稳定，继承层次很深，继承关系复杂，我们就尽量使用组合来替代继承。
除此之外，还有一些设计模式会固定使用继承或者组合。比如，装饰者模式（decorator pattern）、策略模式（strategy pattern）、组合模式（composite pattern）等都使用了组合关系，而模板模式（template pattern）使用了继承关系。
前面我们讲到继承可以实现代码复用。利用继承特性，我们把相同的属性和方法，抽取出来，定义到父类中。子类复用父类中的属性和方法，达到代码复用的目的。但是，有的时候，从业务含义上，A类和B类并不一定具有继承关系。比如，Crawler类和PageAnalyzer类，它们都用到了URL拼接和分割的功能，但并不具有继承关系（既不是父子关系，也不是兄弟关系）。仅仅为了代码复用，生硬地抽象出一个父类出来，会影响到代码的可读性。如果不熟悉背后设计思路的同事，发现Crawler类和PageAnalyzer类继承同一个父类，而父类中定义的却只是URL相关的操作，会觉得这个代码写得莫名其妙，理解不了。这个时候，使用组合就更加合理、更加灵活。具体的代码实现如下所示：
public class Url {
//...省略属性和方法
}
public class Crawler {
private Url url; // 组合
public Crawler() {
this.url = new Url();
}
//...
}
public class PageAnalyzer {
private Url url; // 组合
public PageAnalyzer() {
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的实现...}
}
// 调用
FeignClient client = new CustomizedFeignClient();
demofunction(client);
尽管有些人说，要杜绝继承，100%用组合代替继承，但是我的观点没那么极端！之所以“多用组合少用继承”这个口号喊得这么响，只是因为，长期以来，我们过度使用继承。还是那句话，组合并不完美，继承也不是一无是处。只要我们控制好它们的副作用、发挥它们各自的优势，在不同的场合下，恰当地选择使用继承还是组合，这才是我们所追求的境界。
五、重点回顾
到此，今天的内容就讲完了。我们一块儿来回顾一下，你需要重点掌握的知识点。
1.为什么不推荐使用继承？
继承是面向对象的四大特性之一，用来表示类之间的is-a关系，可以解决代码复用的问题。虽然继承有诸多作用，但继承层次过深、过复杂，也会影响到代码的可维护性。在这种情况下，我们应该尽量少用，甚至不用继承。
2.组合相比继承有哪些优势？
继承主要有三个作用：表示is-a关系，支持多态特性，代码复用。而这三个作用都可以通过组合、接口、委托三个技术手段来达成。除此之外，利用组合还能解决层次过深、过复杂的继承关系影响代码可维护性的问题。
3.如何判断该用组合还是继承？
尽管我们鼓励多用组合少用继承，但组合也并不是完美的，继承也并非一无是处。在实际的项目开发中，我们还是要根据具体的情况，来选择该用继承还是组合。如果类之间的继承结构稳定，层次比较浅，关系不复杂，我们就可以大胆地使用继承。反之，我们就尽量使用组合来替代继承。除此之外，还有一些设计模式、特殊的应用场景，会固定使用继承或者组合。
源码下载：
https://gitee.com/charlinchenlin/koo-erp