设计模式之美
王争
前Google工程师,《数据结构与算法之美》专栏作者
立即订阅
17588 人已学习
课程目录
已更新 21 讲 / 共 100 讲
0/6登录后,你可以任选6讲全文学习。
开篇词 (1讲)
开篇词 | 一对一的设计与编码集训,让你告别没有成长的烂代码!
免费
设计模式学习导读 (3讲)
01 | 为什么说每个程序员都要尽早地学习并掌握设计模式相关知识?
02 | 从哪些维度评判代码质量的好坏?如何具备写出高质量代码的能力?
03 | 面向对象、设计原则、设计模式、编程规范、重构,这五者有何关系?
设计原则与思想:面向对象 (11讲)
04 | 理论一:当谈论面向对象的时候,我们到底在谈论什么?
05 | 理论二:封装、抽象、继承、多态分别可以解决哪些编程问题?
06 | 理论三:面向对象相比面向过程有哪些优势?面向过程真的过时了吗?
07 | 理论四:哪些代码设计看似是面向对象,实际是面向过程的?
08 | 理论五:接口vs抽象类的区别?如何用普通的类模拟抽象类和接口?
09 | 理论六:为什么基于接口而非实现编程?有必要为每个类都定义接口吗?
10 | 理论七:为何说要多用组合少用继承?如何决定该用组合还是继承?
11 | 实战一(上):业务开发常用的基于贫血模型的MVC架构违背OOP吗?
12 | 实战一(下):如何利用基于充血模型的DDD开发一个虚拟钱包系统?
13 | 实战二(上):如何对接口鉴权这样一个功能开发做面向对象分析?
14 | 实战二(下):如何利用面向对象设计和编程开发接口鉴权功能?
设计原则与思想:设计原则 (4讲)
15 | 理论一:对于单一职责原则,如何判定某个类的职责是否够“单一”?
16 | 理论二:如何做到“对扩展开放、修改关闭”?扩展和修改各指什么?
17 | 理论三:里式替换(LSP)跟多态有何区别?哪些代码违背了LSP?
18 | 理论四:接口隔离原则有哪三种应用?原则中的“接口”该如何理解?
不定期加餐 (2讲)
加餐一 | 用一篇文章带你了解专栏中用到的所有Java语法
加餐二 | 设计模式、重构、编程规范等相关书籍推荐
设计模式之美
登录|注册

10 | 理论七:为何说要多用组合少用继承?如何决定该用组合还是继承?

王争 2019-11-25
在面向对象编程中,有一条非常经典的设计原则,那就是:组合优于继承,多用组合少用继承。为什么不推荐使用继承?组合相比继承有哪些优势?如何判断该用组合还是继承?今天,我们就围绕着这三个问题,来详细讲解一下这条设计原则。
话不多说,让我们正式开始今天的学习吧!

为什么不推荐使用继承?

继承是面向对象的四大特性之一,用来表示类之间的 is-a 关系,可以解决代码复用的问题。虽然继承有诸多作用,但继承层次过深、过复杂,也会影响到代码的可维护性。所以,对于是否应该在项目中使用继承,网上有很多争议。很多人觉得继承是一种反模式,应该尽量少用,甚至不用。为什么会有这样的争议?我们通过一个例子来解释一下。
假设我们要设计一个关于鸟的类。我们将“鸟类”这样一个抽象的事物概念,定义为一个抽象类 AbstractBird。所有更细分的鸟,比如麻雀、鸽子、乌鸦等,都继承这个抽象类。
我们知道,大部分鸟都会飞,那我们可不可以在 AbstractBird 抽象类中,定义一个 fly() 方法呢?答案是否定的。尽管大部分鸟都会飞,但也有特例,比如鸵鸟就不会飞。鸵鸟继承具有 fly() 方法的父类,那鸵鸟就具有“飞”这样的行为,这显然不符合我们对现实世界中事物的认识。当然,你可能会说,我在鸵鸟这个子类中重写(override)fly() 方法,让它抛出 UnSupportedMethodException 异常不就可以了吗?具体的代码实现如下所示:
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《设计模式之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(110)

  • 探索无止境
    我个人感觉VO和BO都会采用组合entity的方式,老师是否可以在下一节课课聊聊上节课留下的思考题,您的处理方式?

    作者回复: 抽空集中答疑一下吧

    2019-11-25
    13
    106
  • Paul Shan
    我的观点比较极端,用接口,组合和委托代替继承。原因如下:
    1. 人无法预知未来,现在比较稳定的类继承关系将来未必稳定。
    2.两种设计之间的选择耗费资源,每次都要为这个问题拿捏一下,甚至争论一下,不如把争论放在业务逻辑的实现上。
    3.相对于接口+组合+委托增加的复杂度,代码统一成接口+组合+委托带来的好处更多,利于阅读和交流,毕竟读代码的次数大于写的次数,读一种类型的代码的难度远低于读两种类型。
    4.新的编程语言让接口+组合+委托变得容易,例如Kotlin就有专门的语法糖支持,消除了很多模板代码。
    5.接口+组合+委托符合矢量化思想,那就是将物体特征分成不同的维度,每个维度独立变化。继承则是将物体分类,抽取共性,处理共性,操作的灵活性大打折扣,毕竟现实中的物体特征多,共性少。
    2019-11-25
    4
    67
  • 守拙
    课堂讨论answer:
    Entity, Bo, Vo三者之间,显然并不存在 is-a关系,首先排除使用继承。

    其次三者间也并非是严格的has-a关系,half measure之一是考虑使用组合(composition) + 委托(delegation)的方式解决代码重复的问题,但并不是我心中的最佳答案.

    我的答案是不解决三者间的代码重复问题。Value Class就只是Value Class, 代码重复并不是业务上的代码重复,那就让它重复吧.

    2019-11-25
    4
    28
  • 花儿少年
    VO,BO,DO表示什么前面都说过了,我觉得得换一个思路去看待这种模型转换的问题。
    这里我们将BO看做ddd里面的核心域中的实体。那么这个对象的变化应该对VO或者DO隐藏起来,VO是对外的模型,为什么需要感知到内部业务的变化,DO是具体的存储方式,这是由实现决定的,在业务逻辑中也不应该关心。重要的是隔离,让这三者独立变化。
    所以我的结论是,既不应该用继承,也不应该使用组合,使用防腐层,模型转换层隔离这种变化才是最好的。
    但是实际上在很多业务中BO和DO是差不多的,于是就混用了,在业务不复杂的时候,也没太大关系。业务运行的很好,也不难理解。

    追求完美,却不可能处处完美。
    2019-11-26
    4
    19
  • Geek
    打卡✔
    看完之后有种感觉,我们平常写的spring的依赖注入这种形式,是不是就是跟组合,委托这种模式啊
    2019-11-25
    5
    17
  • Shanks
    希望,评论区能增加一个<b>可选开关</b>,“只看作者回复”的评论「(*/ω\*)」
    2019-11-25
    3
    16
  • 兔2🐰🍃
    看下来对组合跟委托两个概念表示不太明白,看了代码后才,以及网上查阅后才明白。
    继承(Inheritance):利用extends来扩展一个基类。is-a的关系。
    组合(composition):一个类的定义中使用其他对象。has-a的关系。
    委托(delegation):一个对象请求另一个对象的功能,捕获一个操作并将其发送到另一个对象。有uses-a, owns-a, has-a三种关系。
    2019-11-25
    8
  • 睡觉💤
    GO完全摒弃了继承,在语法上只有组合,接口之间也可以组合(这也是官方鼓励的做法)。
    2019-11-25
    8
  • 李湘河
    现代军事武器中的开发都在追求模块化开发,这样装备之间通用性更强,战损时随时可以替换掉损坏的模块,这样又可以重新作战,当要增强坦克某一部分的性能时,仅改进对应的模块就行,感觉很像组合的思想。就像文中说的,对于结构稳定,层次浅的地方完全可以用继承,或者说可以局部用继承,比如VO层,对于用户检验,分页等都可以抽象出来
    2019-11-25
    1
    5
  • tt
    谈谈对下面一段话的理解:


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

    理解或总结如下:

    1、“比如 is-a 关系,我们可以通过组合和接口的 has-a 关系来替代”,我的理解为:is-a意味着has-muilti-a's或者has-all-needed-a's。故而需要实现多个接口,而接口抽象的是操作或者方法而非数据(数据和方法的抽象由抽象类来完成),所以具体的操作要由被组合进来的类对象来完成,站在类间关系的角度来看,外部类和被组合类之间的关系被称为“委托”。

    2、这里面,被组合类的代码被抽象到了接口中,或者反过来说接口的具体操作下沉到了被组合类中,这就是“代码复用我们可以通过组合和委托来实现”的含义,代码被不同的被组合类“分门(类)别类”的复用了。

    3、“多态特性我们可以利用接口来实现”,因为接口代表了某种契约,而多态就是用子类代替父类。只要实现了某种接口,按照契约,自然就可以在某些方面或某种程度上代替父类。所以我觉得接口是“更细粒度更多控制的更有节制的继承”。

    回到本课的问题。

    之前的课说到VO,BO,Entity是典型的面向过程的编码,里面基本都是数据,没有方法。那么自然不可以用接口来减少代码的重复,只能用继承了。

    但是MVC的结构,我理解它是一种分层客户端服务器架构,Layered Client-Server,每一层为其之上的层服务,并使用其之下的层所提供的服务。为了减少层之间的耦合,必要的重复是可以的。
    2019-11-25
    4
  • 沧月丶下
    public class FeignClient { // feighn client框架代码

    feighn -> feign 勘误~

    作者回复: 嗯嗯多谢指出

    2019-11-25
    4
  • 未设置
    希望作者能在课程末尾梳理下上一节课程的课后习题,或者集中点评下大家的留言。感谢

    作者回复: 可以的...

    2019-11-25
    4
  • James
    我的个人感觉,等待高手更好的回答//
    Entity在VO,BO中基本上都是一模一样的,使用组合把Entity引用进来,然后在BO,VO中创建各自独特的属性/
    2019-11-25
    3
  • 黄林晴
    打卡✔
    老师好,今天刚用继承优化了代码臃肿的问题,但是感觉好奇怪,请老师指导:
    所有的消息都会先到一个A类中,在A类中,根据消息类型,比如类型1 2 3 4去处理不同的业务,每一类的业务都需要处理对应数据,原本随着消息类型的增加不断往这个A类中扩展代码,导致不好维护,所以我对每个业务模型建对应的类继承这个A类,在A类中将消息转给对应类去处理,其实new一个类 将所有参数传过去也可以,但是因为参数太多太多不美观,所以使用了继承,但回过头来想,我的继承只是被动使用的,好像和继承的原理相违背
    2019-11-25
    9
    3
  • DFighting
    可以使用组合+继承来解决代码重复的问题,但实际项目中我更倾向于不同层次之间的冗余(前提是MVC框架),因为我理解的优秀的代码是服务于优秀的设计架构的,也就是说不通层次之间的代码中肯定会有冗余,因为数据是在不同层次中流转的。不过在同一个层次中的代码冗余就有优化的必要了
    2019-11-27
    2
  • Jxin
    1.bo vo和entity三个命名在现在面向服务而非页面的后端编程,并不合适。
    2.这里最好用组合。entity是最小的实体单元,bo可能面对多个entity聚合,vo可能面对多个bo聚合,这种场景下,显然组合更适合。虽然也存在entity和bo一对一的场景,或者bo中只有一个主entity的场景,这种场景用继承倒也不为过。但是,为了套路单一,减少阅读思考,统一组合便是,没必要再引入继承。

    3.老项目里面,代码已经高度耦合,而且不是面相接口写的代码,那么整体改动成本会很大。这种情况下用继承实现多态我觉得挺合适。

    4.java1.8提供接口的方法默认实现后,我觉得继承的处境真的挺尴尬,新项目反正能用继承实现的用组合也可以。所以除非父子关系特别明显(继承不深其实比组合直观),不然没什么必要用继承了。
    2019-11-25
    2
  • xk_
    entity就不用动了,VO和BO都可以使用组合entity。我自己曾经抽取过VO和BO的共同属性,这个方法特别不好,只要父类要修改,子类也要跟着修改,子类调用的方法也要修改。

    如果用组合的方式,那改动就会相对少很多。代码也会清晰很多。

    要是很多entity有共同的属性,倒是可以抽出来作一个抽象类。
    2019-11-25
    1
    2
  • 辣么大
    很多同学提出复用Entity(DO),我有不同意见:若修改DO,可能会影响到BO和VO。
    我们都知道DO对应数据表,如PersonDO类有id,age,name。
    若现在需求改变,age要从政府系统获取,原有的Person表要删除age字段,相应的DO类就要修改,UI仍然显示person.age。BO、VO有如果使用了DO就会受到影响。
    为了降低影响,BO,VO考虑使用PersonDTO。
    上面的例子中DTO中保留Person.age属性,在Service层中将DO转换为DTO,转换时PersonDTO.age从其他系统获取。
    这样虽然增加了代码量,对DAO层的修改影响降到最低。
    2019-11-25
    2
  • 傲慢与偏执,
    我只有在该类需要更细化详情信息的时候会组合详情类的list 看了这节课后 受益匪浅
    2019-11-25
    2
  • 这次的思考题正好也是困惑我很久的问题,看看大家有什么好的方式。
    之前我的做法是用组合+委托的方式,但发现这种方式其实还是无法实现分层,即间接的将两个硬关联起来,增减属性的时候需要同时修改两个对象的代码;
    如果是继承关系,那么相当于多出一个类,让三个对象同时继承该类,但这个新衍生出的对象又怎么理解它呢?它与其他三个对象是否有is-a的关系?不能单纯的为了复用而继承。
    最后我极端的做法是将三者合为一体,抽象理解成“数据承载对象”…哈哈,但是这个对于VO对象,通常需要根据接口要求返回特定格式的数据,所以变成不伦不类的对象了。
    😭
    2019-11-25
    2
收起评论
99+
返回
顶部