开闭原则：
如何保证对修改关闭，对扩展开放呢？
那么首先说，为什么会有需求的变动吧。
1 需求追加。
2 需求变更。
举个例子把，比如我们有一个坦克，坦克有种型号。
塔克的基本机能是能走能射击。
坦克类{
跑（）
射击（）
}
70坦克{
跑：70公里没小时；
射程：700米；
}
50坦克{
跑：50公里每小时；
射程：500米；
}
现在增加90坦克。具体如下？
90坦克
{
跑：90公里每小时；
射程：900米；
}
符合开闭原则。
这个是机能的变更。符合开闭原则。
现在假设追加红外瞄准功能，如果想给全部的坦克追加这个机能。
那么怎么办呢？红外瞄准机能射击机能的一个附近机能。
我们给以上的没种坦克都安装商这个机能行吗？
下面我把按照符和开闭原则取设计。
70红外瞄准坦克{
跑：70公里没小时；
射程：700米+红外瞄准；
}
50红外瞄准坦克{
跑：50公里每小时；
射程：500米+红外瞄准；
}
90红外瞄准坦克
{
跑：90公里每小时；
射程：900米+红外瞄准；
}
这也符和开闭原则，但是如果我们真的这么设计了，那么就有点怪了。
怪在那了呢？重复，明显的机能重复。
先不管是否符和开闭吧，我们理想的设计应该是这样的。
间一个瞄准的类
瞄准类{
普通瞄准。
}
红外瞄准 继承瞄准类{
红外瞄准。
}
然后坦克类的变更如下
坦克{
瞄准类 瞄准对象
设计:瞄准对象.瞄准函数运行。
跑（）；
}
各个子类设计略。
这里大家一定有疑问了？
这种修改后的设计是好的，但是设计的过程明显是不符和开闭原则的？
这里我的理解是，开闭原则是个静态原则，我们在每次设计的时候尽量考虑这个原则。
为以后机能的变更留有余地。
但是变化的东西总会超出我们的想象，我们有不能受限与这个原则。
大胆果断的重构，任何原则都是为设计服务的。我们要一好的设计为中心。
记录避免变更，尽量通过扩展来应对变更。
这里回到问题之初，开闭原则的价值是什么呢？
是新机能的引入对寄存机能的影响尽量的小，就像上面的第一次变更。
90坦克的追加，对继存的机能几乎没有任何影响，70坦克和50坦克，根本不需要再次测试。
但是第二次的变更是不行。
因为坦克基类都变化了，所以必须对全部的坦克进行测试。
那么有没有办法解决这个问题呢？
能：如果我们在坦克的设计之初就考虑到关于瞄准会有红外瞄准的引入，我们就可以用一个专门的瞄准类来应对这个变化。
如果最终的那个设计在设计之初，我们就考虑到了。
就可以在第二次变更的时候依然保存对开闭原则的遵守。
这里也说明了一个问题，关于开闭原则的遵守需要有适当的前瞻性。
这里有涉及到涉及的根本了，封装共性稳定行，隔离变化和不稳定行。
最后总结一下：原则这东西是为设计服务的，就是给我们一个设计的基础方向，不用过于拘泥。
知道他是怎么个意图就行了。
怎么好的设计也有需要突破原则的时候。
把原则当成你设计的参谋吧，他不是司令。