说是读后感,根本算不上,当记个笔记,划个重点吧。

Reference

继承

继承导致的最大的一个特征:高耦合。
耦合是一个特征,当耦合成为需求的时候,耦合就不是缺陷了。
继承是紧耦合的一种模式,主要的体现就是在于牵一发动全身。

解决方案

组合替代继承。
大部分我们通过代码复用来选择继承的情况,其实都是变成组合比较好。

继承使用

e.g.

1
2
3
4
5
6
7
8
1.
Object -> Model
Object -> View
Object -> Controller
2.
ApiManager -> DetailManager
ApiManager -> ListManager
ApiManager -> CityManager

1. 父类只是给子类提供服务,并不涉及子类的业务逻辑。

1
2
3
4
5
6
1.
Object 并不影响 Model, View, Controller 的执行逻辑和业务

Object 为子类提供基础服务,例如内存计数等
2.
ApiManager 并不影响其他的 Manager

ApiManager 只是给派生的 Manager 提供服务而已,ApiManager 做的只是分内的事,不参与子类做的事情

2. 层级关系明显,功能划分清晰,父类和子类各做各的。

1
2
3
4
5
1.
Object 并不参与 MVC 的管理中,那些都只是各自派生类自己要处理的事情

2.
DetailManager ListManager CityManager 都只是处理各自业务的对象

ApiManager 并不应该涉足对应的业务

3. 父类的所有变化,都需要在子类中体现,也就是说此时耦合已经成为需求。

1
2
3
4
1.
Object 对类的描述,对内存引用的计数方式等,都是普遍影响派生类的

2.
ApiManager 中对网络请求的发起,网络状态的判断,是所有派生类都需要的

此时,牵一发动全身就成为了需求,是适合继承的。

总结

万不得已不要用继承,优先考虑组合。

  1. 考虑以上 3 点要素是否符合,才能决定是否使用继承。
  2. 当你发现你的继承超过 2 层的时候,你就要好好率是否这个继承的方案了,第三层继承正是滥用的开端。