1、继承的缺点是什么？为什么不推荐使用继承？
如果滥用继承，会导致继承层次过深，复杂的继承关系。导致维护性降低。（如果继承关系层次少，不fu）
（继承是面向对象的四大特性之一，用来表示类之间的 is-a 关系，可以解决代码复用的问
题。虽然继承有诸多作用，但继承层次过深、过复杂，也会影响到代码的可维护性。在这种
情况下，我们应该尽量少用，甚至不用继承。）
2、我们有什么手段可以替代继承呢？
可以用组合，接口，委托来实现。我们下看看下面的代码：
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(); // 委托
}
}
3、 组合相比继承有哪些优势？
继承主要有三个作用，表示is-a关系，支持多态特性，代码复用。而这三个作用都可以通过组合、接口、委托三个技术手段来达成。
除此之外，利用组合还能解决层次过深，过复杂的继承关系影响代码可维护性
4、如何判断该用组合还是继承？
如果类之间的继承结构稳定，层次比较浅，关系不复杂，我们就可以大胆地使用继承。
反之，我们就尽量使用组合来替代继承。除此之外，还有一些设计模式，特殊的应用场景，会固定使用继承或者组合
5、有人极力不使用继承，原因是什么？
- 人无法预知未来，现在比较稳定的类继承关系将来未必稳定。
2.两种设计之间的选择耗费资源，每次都要为这个问题拿捏一下，甚至争论一下，不如把
争论放在业务逻辑的实现上。
3.相对于接口+组合+委托增加的复杂度，代码统一成接口+组合+委托带来的好处更多，
GO完全摒弃了继承，在语法上只有组合，接口之间也可以组合(这也是官方鼓励的做法)。
问题：
我们在基于 MVC 架构开发 Web 应用的时候，经常会在数据库层定义 Entity，在 Service业务层定义 BO（Business Object），在 Controller 接口层定义 VO（View Object）。大部分情况下，Entity、BO、VO 三者之间的代码有很大重复，但又不完全相同。我们该如何处理 Entity、BO、VO 代码重复的问题呢？
VO和BO都会采用组合entity的方式