类的继承之痛

通过类的继承，构建了一个树形的逻辑依赖结构，也就是子类的功能是依赖父类的。但是随着时间的推移，我们发现，我们需要对父类进行改造，父类本身也会发生变化，原来的 class father逻辑上变成了class father和class father1，往往因为过渡时期或者历史原因，father和father1必须同时存在，我们发现，为了使用father1，我们得重新编写他的子类，尽管这两个父类的子类逻辑是一致的。这就是类的继承之痛，父类可以通过多态调用不同的子类，但是子类调用父类确是定好的，在开发后期无法更改的行为。

时间，是所有逻辑处理中最为复杂的因素，因为时间变化，需求在不断变化，在所有的逻辑环节都有可能发现变化。作为开发者，希望每次代码都能复用，逻辑都不冗余。通过继承特性，新的需求逻辑可以不去更改老的逻辑，也可以直接复用老的逻辑，但是这样的复用关系就被定格了，在逻辑上形成不能解开的一环。或者说，这种树形的逻辑结构，并不能简单描述网状结构的逻辑。

为了解开这一环，应该使用分层的思想，上层逻辑依赖底层的功能，但是不依赖底层的具体实现，在进行底层层内逻辑更改、丰富的时候，上次逻辑是不需要改变的。也就是不能因为我有两个父类，我就需要两棵树去实现上层的逻辑。依赖只能仅在接口层次上。

实现这中解耦的方法之一是，通过模板类，也就是上层类在构建的时候，就指定自己依赖的父类，这样上层类的代码是完全复用的，不同的父类就是一个参数而已。但是这样有几个缺点：

1 模板类的编码方式显得很丑，因为每一个类的方法都要带着这个参数，尽管这个类方法完全不需要这个参数，上整个上层类的代码看上去很累，总是背着一个包袱。

2 模板类由于模板参数是在编译时才能确定的，因此无法编译成链接库的形式，每一次都要新的编译，随着时间的积累，编译的包袱也越来越大。

解开这一环，另一种编码方式就是注册回掉的方式，这种有点像设备驱动的实现方式。上层类，提供一个注册接口，能将底层类的函数指针进行注册，在上层类的实现中进行回掉。这样上下的逻辑唯一联系就是函数指针。具体这个函数怎么实现的，相关不影响。

类的实现中，将数据和行为(data and program)进行了封装，数据往往是内敛的，行为往往是外显的，数据往往是不可复用的，行为是可以复用的，因此在考虑代码复用性的时候，就应该将数据剥离开来。