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

课堂讨论answer:
Entity， Bo， Vo三者之间，显然并不存在 is-a关系，首先排除使用继承。

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

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

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

追求完美，却不可能处处完美。

谈谈对下面一段话的理解：


“我们知道继承主要有三个作用：表示 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，每一层为其之上的层服务，并使用其之下的层所提供的服务。为了减少层之间的耦合，必要的重复是可以的。

1.bo vo和entity三个命名在现在面向服务而非页面的后端编程，并不合适。
2.这里最好用组合。entity是最小的实体单元，bo可能面对多个entity聚合，vo可能面对多个bo聚合，这种场景下，显然组合更适合。虽然也存在entity和bo一对一的场景，或者bo中只有一个主entity的场景，这种场景用继承倒也不为过。但是，为了套路单一，减少阅读思考，统一组合便是，没必要再引入继承。

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

4.java1.8提供接口的方法默认实现后，我觉得继承的处境真的挺尴尬，新项目反正能用继承实现的用组合也可以。所以除非父子关系特别明显（继承不深其实比组合直观），不然没什么必要用继承了。