敏捷思考 遵循与破坏"开闭原则"

开放封闭原则跟针对接口编程并不是直接关联的，javascript开发中可以一个接口都没有，照样遵守开放封闭原则。
针对接口编程了，但这个接口不是内聚的，类的设计不遵守“单一职责原则”，类的内聚性很差，照样违反了开放封闭原则。

思维太oo了，不是好事情，容易把简单的事情复杂化

无法理解你的话,能否给个例子

为什么啊

比如如下代码
如果事情很简单
打开一扇门，我们可以，

isDoorOpen = true

如果oo点
就是

 function openDoor(){
         this.isDoorOpen  =true;
}
    

如果更oo点

Door door = Door.getInstance();
 door.open();

如果整个工程就是为了开门，显然搞的太复杂没有意义

嘿嘿,这不就是我一直想说的,我们应该敏捷起来吗?

这样的讨论很精彩，我在开发当中也经常遇到这样的问题。大部分的解决办法都是在后面加些参数，多些判断语句完事。就像LZ的方案一一样。因为，觉得这种办法最直接有效，但导致的结果是说，代码越来越多，维持起来越来越麻烦。偶尔也尝试用扩展的方式去新增一个类来解决。所以，我现在的认为是说，扩展与修改之间，做出两者间的平衡，如何取舍这点上，前期的分析或者判断，很难。

提高代码质量才是王道。至于预测未来，纯属扯淡。基于已有问题进行设计，而不是基于预测进行设计。设计的目的，是解决已存在的问题，而不是对未来的变化赌大小。
修改未必不可接受。软件的变化，必然会导致修改代码。配置文件，也是代码。从实际情况来看，修改配置文件，有时候还不如修改代码效率高。
怎么样能用最快的方法解决问题，保证软件质量，就是最好的设计。
好的设计，就是让编程变成打字。在保证正确性的前提下，开发和测试成本最低的设计就是最好的设计。
好的设计就是提高工作效率，其他都是扯淡。

简单和灵活性本来就是矛盾的，想要灵活势必会需要增加额外的付出，OO的目的就是为了解耦、扩展和维护，工作量一定会增加，如果做简单的应用是不用这么麻烦，但当开发一套复杂的系统，或进行重构，就能体会到接口的好处了，至于说到的增加接口的代码量，现在很多工具都能直接自动生成，能让机器来做的就不用人肉了。

依赖接口不依赖实现，接口实现分离，压根就是个习惯了。应该属于OCP的最开始的一个级别的遵守了