共计 5379 个字符，预计需要花费 14 分钟才能阅读完成。
起源：blog.csdn.net/fuzhongmin05/article/details/108646872
面向对象编程中，有一条十分经典的设计准则，那就是：组合优于继承，多用组合少用继承。
同样地，在《阿里巴巴 Java 开发手册》中有一条规定： 审慎应用继承的形式进行扩大，优先应用组合的形式实现。 这个能够在公众号 Java 核心技术回复：手册，获取最新高清完整版 PDF。
为什么不举荐应用继承
每个人在刚刚学习面向对象编程时都会感觉：继承能够实现类的复用。所以，很多开发人员在须要复用一些代码的时候会很天然的应用类的继承的形式，因为书上就是这么写的。继承是面向对象的四大个性之一，用来示意类之间的 is- a 关系，能够解决代码复用的问题。尽管继承有诸多作用，但继承档次过深、过简单，也会影响到代码的可维护性。
假如咱们要设计一个对于鸟的类。咱们将“鸟”这样一个形象的事物概念，定义为一个抽象类 AbstractBird。所有更细分的鸟，比方麻雀、鸽子、乌鸦等，都继承这个抽象类。咱们晓得，大部分鸟都会飞，那咱们可不可以在 AbstractBird 抽象类中，定义一个 fly() 办法呢？
答案是否定的。只管大部分鸟都会飞，但也有特例，比方鸵鸟就不会飞。鸵鸟继承具备 fly() 办法的父类，那鸵鸟就具备“飞”这样的行为，这显然不对。如果在鸵鸟这个子类中重写 fly() 办法，让它抛出 UnSupportedMethodException 异样呢？
具体的代码实现如下所示：
public class AbstractBird {
//... 省略其余属性和办法...
public void fly() { //...}
}
public class Ostrich extends AbstractBird { // 鸵鸟
//... 省略其余属性和办法...
public void fly() {throw new UnSupportedMethodException("I can't fly.'");
}
}这种写法尽管能够解决问题，但不优雅。因为除了鸵鸟之外，不会飞的鸟还有很多，比方企鹅。对于这些不会飞的鸟来说，全副都去重写 fly() 办法，抛出异样，齐全属于代码反复。实践上这些不会飞的鸟基本就不应该领有 fly() 办法，让不会飞的鸟裸露 fly() 接口给内部，减少了被误用的概率。
要解决下面的问题，就得让 AbstractBird 类派生出两个更加细分的抽象类：会飞的鸟类 AbstractFlyableBird 和不会飞的鸟类 AbstractUnFlyableBird，让麻雀、乌鸦这些会飞的鸟都继承 AbstractFlyableBird，让鸵鸟、企鹅这些不会飞的鸟，都继承 AbstractUnFlyableBird 类。
具体的继承关系如下图所示：
这样一来，继承关系变成了三层。然而如果咱们不只关注“鸟会不会飞”，还要持续关注“鸟会不会叫”，将鸟划分得更加粗疏时呢？两个关注行为自在搭配起来会产生四种状况：会飞会叫、不会飞会叫、会飞不会叫、不会飞不会叫。如果持续沿用方才的设计思路，继承档次会再次加深。
如果持续减少“鸟会不会下蛋”这样的行为，类的继承档次会越来越深、继承关系会越来越简单。而这种档次很深、很简单的继承关系，一方面，会导致代码的可读性变差。因为咱们要搞清楚某个类具备哪些办法、属性，必须浏览父类的代码、父类的父类的代码……始终追溯到最顶层父类的代码。另一方面，这也毁坏了类的封装个性，将父类的实现细节裸露给了子类。子类的实现依赖父类的实现，两者高度耦合，一旦父类代码批改，就会影响所有子类的逻辑。
继承最大的问题就在于： 继承档次过深、继承关系过于简单时会影响到代码的可读性和可维护性。
组合相比继承有哪些劣势
复用性是面向对象技术带来的很棒的潜在益处之一。如果使用的好的话能够帮忙咱们节俭很多开发工夫，晋升开发效率。然而，如果被滥用那么就可能产生很多难以保护的代码。作为一门面向对象开发的语言，代码复用是 Java 引人注意的性能之一。Java 代码的复用有继承、组合以及委托三种具体的实现模式。
对于下面提到的继承带来的问题，能够利用组合（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 implements Flayable, 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(); // 委托
}
}应用 Java8 的接口默认办法
在 Java8 中，咱们能够在接口中写默认实现办法。应用关键字 default 定义默认接口实现，当然这个默认的办法也能够重写。
public interface Flyable {default void fly() {// 默认实现...}
}
public interface Flyable {default void fly() {// 默认实现...}
}
public interface Tweetable {default void tweet() {// 默认实现...}
}
public interface EggLayable {default void layEgg() {// 默认实现...}
}
public class Ostrich implements Tweetable, EggLayable {// 鸵鸟
//... 省略其余属性和办法...
}
public class Sparrow implements Flayable, Tweetable, EggLayable {// 麻雀
//... 省略其余属性和办法...
}继承次要有三个作用：示意 is- a 关系、反对多态个性、代码复用。而这三个作用都能够通过其余技术手段来达成。比方 is- a 关系，咱们能够通过组合和接口的 has- a 关系来代替；多态个性咱们也能够利用接口来实现；代码复用咱们能够通过组合和委托来实现。所以， 从实践上讲，通过组合、接口、委托三个技术手段，咱们齐全能够替换掉继承，在我的项目中不必或者少用继承关系，特地是一些简单的继承关系。
如何判断该用组合还是继承
只管咱们激励多用组合少用继承，但组合也并不是完满的， 继承也并非一无是处。从下面的例子来看，继承改写成组合意味着要做更细粒度的类的拆分。这也就意味着，咱们要定义更多的类和接口。类和接口的增多也就或多或少地减少代码的复杂程度和保护老本。如果类之间的继承构造稳固（不会轻易扭转），继承档次比拟浅（比方，最多有两层继承关系），继承关系不简单，咱们就能够大胆地应用继承。反之，零碎越不稳固，继承档次很深，继承关系简单，咱们就尽量应用组合来代替继承。
除此之外，还有一些设计模式会固定应用继承或者组合。比方，装璜者模式（decorator pattern）、策略模式（strategy pattern）、组合模式（composite pattern）等都应用了组合关系，而模板模式（template pattern）应用了继承关系。
有的中央提到组合优先继承这条软件开发准则时，可能会说成“ 多用组合，少用继承 ”。所谓多用与少用，理论指的是要弄清楚在具体的场景下须要哪种。软件开发准则这类问题，不宜死扣字眼。其实在《Thinking in Java》里有提到，当你用继承的时候，必定是想要应用多态的个性。
比方你要写一个画图零碎，画不同的图形，这个时候，你可能思考到调用相应的函数的时候能够不思考具体类型，间接画就好了，具体什么图形，交给运行时去判断。这个时候，就要用到多态，就须要有继承关系。一个父类，多个子类。而后用父类的类型去援用具体子类的对象，就能够了。
而用不到多态的时候，应用继承有什么用呢？代码复用？一个继承能够让你少写很多代码，然而用错了场合，前期的保护可能是灾难性的。因为继承关系的耦合度很高，一处改会导致处处须要批改。这个时候就须要组合。
所以我保持， 如果不想应用多态个性，继承关系就是无用的。
处境难堪的继承
大家对继承的讨厌次要是因为长期以来程序员适度应用继承，继承并非一无是处。
在某些非凡场景下，咱们必须应用继承。如果你不能扭转一个函数的入参类型，而入参又非接口，为了反对多态，只能采纳继承来实现。比方上面这样一段代码，其中 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);下面这个例子，举得不是太失当，更像是一种无可奈何。这恰好反映了继承在面向对象编程的大部分场景下的难堪处境。
其实咱们很难真正应用好继承，根本原因在于，自然界中，代际之间是存在变异的，物种之间也是，而且这种变动是无奈做法则化形容的，既随同着某些性能的减少，也随同着某些性能的弱化，甚至还有某些性能的扭转。
在软件行业最晚期，软件性能很贫乏，须要一直减少软件性能来满足需要，这时候继承关系可能体现软件迭代后性能加强的特点。但很快就达到瓶颈期，性能不再是掂量软件好坏的次要指标，各种差异化的体验变得更加重要，此时软件迭代时不再是单纯的性能的累加，甚至于是齐全的推倒重来，编程语言上的继承关系也就随之被废除。
注：以上对于组合及继承的代码例子，出自极客工夫王争老师的《设计模式之美》第十讲
近期热文举荐：
1.1,000+ 道 Java 面试题及答案整顿 (2022 最新版)
2. 劲爆！Java 协程要来了。。。
3.Spring Boot 2.x 教程，太全了！
4. 别再写满屏的爆爆爆炸类了，试试装璜器模式，这才是优雅的形式！！
5.《Java 开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞 + 转发哦！
