开闭原则- 对修改关闭，对拓展开放

底层模块的变更，必然有高层模块的耦合，开闭原则就是要减少变更的扩散性。

而且接口是与其他模块交流的
契约，修改契约就等于让其他模块修改。因此，接口或抽象类一旦定义，就应该立即执行，
不能有修改接口的思想。

不轻易动接口，接口就是契约，业务变更时不应轻易动接口，如果变更可以通过拓展完成的话

这样只需要在需要变化的业务模块中改变下实现类就好。

 

然后开发中也要保持历史代码的纯洁性，减少对历史代码的修改，就能提高系统的稳定。

 

开闭原则应用

对修改关闭，对增加开放

比方说

1.开闭原则对测试的影响

比较重要的方法的测试方法甚至有十多种， 而且
单元测试是对类的测试， 类中的方法耦合是允许的， 在这样的条件下， 如果再想着通过修改
一个方法或多个方法代码来完成变化， 基本上就是痴人说梦
： 假设修改某段已经写好的底层代码。这个底层代码被应用的业务场景少还好，如果它出现在很多个业务场景下了，那就需要检查多个业务场景是否正确运行。

查看正确运行会用到测试用例，如果方法修改了参数什么的，就要在多个测试用例中改，改了这个还可能影响到别的。所以不要轻易修改老代码， 但可以拓展

 

2. 开闭原则可以提高复用性

在面向对象的设计中， 所有的逻辑都是从原子逻辑组合而来的， 而不是在一个类中独立
实现一个业务逻辑。 只有这样代码才可以复用， 粒度越小， 被复用的可能性就越大。

那怎么才能提高复用率呢？ 缩小逻辑粒度， 直到一个逻辑不可再拆分
为止。
这在项目中的反面体现就是加一个东西得在一堆地方+，改一个东西得在一堆地方改。如果把粒度设计的很细，这样大家都能用到这个小工具，改的时候直接改一个地方就好。