开闭原则
     各位大侠，请问一下 开闭原则。接触设计模式几年了，但是一直徘徊在其门外。。

     以往用到得模式都是重构出来的，仅仅是为了代码美观，思路清晰。其他作用不大。。 为什么这么说呢？
    
        ----对扩展开放对修改关闭。
    往往在接到需求的时候，对于以后的变化百分之80以上的不知道。毕竟需求确定后，谁也不知道怎么变？

这样该 怎么设计预留接口就成了烦恼。当有需求变更的时候，在以前设计中并没有预留变化，所以只能通过改代码解决。。

请问这种情况该怎么办呢？ 对于未知的需求如何能够把握其以后的扩展？请高手指教，不胜感激。
------最佳解决方案--------------------
这主要看你的代码是面向过程的，还是面向对象的了。

很简单的，粗略地统计一下平均每个函数/方法的代码的行数、swtich...case 及 if...else... 的数量，以及嵌套的 if...else... 的层数，这些值越高，表明代码越趋于过程化。

有能力做到 OCP 的代码，在初期需要经过精心的设计，而且前期的代码量和类的数量，及对象关系统较为复杂，但也带来对于后期维的简便性。如果前期没有精心的设计，代码都是揉在一个类里的话，那后期维护就会变成对代码的补丁操作，会导致这些类越来越复杂，越来越庞大，各种 if...else... 各种嵌套的 if...else... 久而久之这种现象会更为严重，导致后面的维护成本和出错率越来越高
------其他解决方案--------------------
在接到需求设计代码时，若设计的粒度过细则会增加代码量，若涉及的粒度过粗 可能以后修改的时候容易改一处而动全身。如何把握这个度？经验？火候?
------其他解决方案--------------------
如果面对新的变更需求 要实现 开闭原则 
    设计代码时，使功能之间松耦合，会不会面对变更时会更从容一下。
------其他解决方案--------------------
等待高手回答。。
------其他解决方案--------------------

引用:

在接到需求设计代码时，若设计的粒度过细则会增加代码量，若涉及的粒度过粗 可能以后修改的时候容易改一处而动全身。如何把握这个度？经验？火候?

应该是写多了自然而然知道怎么避免这些
------其他解决方案--------------------
这个真是经验吧，把设计模式啥的都学会了也没用
------其他解决方案--------------------
等有经验的指导。
------其他解决方案--------------------
经验啊。。。。
------其他解决方案--------------------
谢谢 7楼 给分。满意。