C++的继承(三)：版本管理

OO世界看起来秩序井然。但我确信这是一种假象。现在又一头怪兽蹦出来了。这就是版本管理。

版本管理的想法是，先写一部分代码，作为基础类。然后接着再写一些代码，作为派生类。然后接着再写一些代码，作为派生类的派生类。如此下去。基础类和派生类和派生类的派生类，概念上没有明显的隶属关系。谁做基础类，谁做派生类，往往取决于作者的当时怎么想。有的代码作者先想到，想的多了点，觉得相对成熟了些，就让它先作了基础类。有的时候安排的时间不够，只能先做一些小的功能。因为书写的顺序，让这些小功能作了基础类。当然还有别的原因。版本管理的每一个类名，都相当于一次check-in。

每个工程师设计功力有深有浅。常常不能一下子设计出一整套严谨的类体系。有时又需要探索，下一步或许可以走A, 或许可以走B, 或许可以走C。思路不同，导致不同的设计路线。这时候又要决策。

原来的代码上可以派生出A, 或者派生出B, 或者派生出C。这样会产生了三个分支。不知道那个分支会容易一些。或者那个看起来容易，实际上会遇到难以克服的技术问题。或者不知道它的子任务，谁会先提交。如果在某个分支上遇到难题，必然需要回溯，在某个上游类上重新派生，丢掉最少的代码。这是对已经完成的工作的保护。最后在某个分支上成功地解决了问题时，就砍掉其他的分支。这样呈现在大家眼前的是一个长长的继承链, 而每一级继承实现的功能又较少，逻辑关系也不是教科书上典型的知识点中的关系。这时候该考虑重构了。当然如果不能安排时间，就只能这样了。因为能用了，多数也就这样了。

现在，版本管理工具已经非常成熟。这么做是不推荐的，因为毕竟这是版本管理工具所擅长的事。尤其是，当版本管理的继承和逻辑关系的继承搅到一起时，常常会导致异常复杂的代码。理解不了。不过有些重要的代码已经这样做了。实际开发和教学理想是两回事。“谁来支付这些额外的成本？” 很多美好的想法遇到这个问题时，常常只能选择让路。阅读别人代码时遇到这种情况需要额外注意。