代码变更策略分析

当产品功能渐渐向多元和多变的方向发展时，往往希望新修改的部分不会对之前的已经稳定的部分产生影响。如何提高软件的可扩展性，使软件稳定性在版本间保持独立是一个值得讨论的问题。

这里有几种方案可供选择，一种就是为每个产品都维护一套代码，各个产品的代码之间相互独立，这样当为某一个产品修改或者添加新功能时不会影响到其他已经稳定的代码。弊端也很明显，就是会产生大量的冗余代码，当有些修改和扩展是针对多数产品的时候，保证不同版本代码的一致性是非常困难的。

第二种方案就是在一个版本中维护所有的产品，各个产品都是从该版本中配置出来，这样带来一个设计决策的问题，，即当某一个过程函数需要修改时，一个选择就是直接对原函数进行修改，这可能意味着不仅要改变函数本身可能还需要改变接口；另一个选择就是重新构造该过程，这样可以通过配置参数形成分支，不同的配置走不同的路径，这样不用考虑对原有的分支产生影响的问题。即原有的代码还是稳定的，所有的不确定因素都在新构造的分支中，也就是说只需要对新的分支进行测试即可。

其实第二种策略跟方案一的本质是一样的，，因为要建立新的分支，不可避免的新分支中某些过程跟旧版本之间是重复的，这个问题跟代码本身模块粒度有关，模块粒度越粗，冗余代码就越多。当冗余代码产生时，就意味着某一段代码在同一个工程下存在一个或多个副本，就跟方案1一样，当对这部分代码进行修改时，必须保证所有副本的一致性。

层次化的设计思想是一个放之四海皆准的方法。不论上到在架构设计还是下至硬件寄存器设计都能体现出层次化的优越性，，总之当分解一个系统时，首选方案就是层次化分解，这是不会错的。。

回到刚才的问题，要保证软件稳定性的不同版本独立性，也就是提高可扩展性，层次化的架构是最好的选择。

这里总结一下实现代码变更的方法：

1.通过添加分支来实现变更：

        

    

2.通过继承新类来实现变更：

            继承原有类，创建一个新类。在新类中加入变更

 

即使采用了层次化多态架构，完全的消除冗余也是不可能做到的，细化系统模块粒度可以降低代码冗余度但是会带来额外的分解开销，其实从本质上来说层次化多态架构跟上面提到策略2分支结构的改进就是消除了分支，使得扩展不依赖于swtich 、if else而已。