对于OCP原则的困惑

to 庄表伟:
如果是
简单的设计，我承认我的说法是不正确的。
就这一句：
我想也是一样偏颇的！
简单的设计，也就没有讨论的必要，不是吗？

但是现在容器装配对象的概念深入人心，开始就考虑接口又何尝不可呢。
另外，工厂方法的使用也是很谨慎的，我的讨论也没有围绕工厂来讨论，我更多是想说说容器的可装配或者配置文件动态构架对象。
动不动就使用工厂方法自然是不明智的，工厂的使用应该象javax.xml.parsers.DocumentBuilderFactory;这种设计才是合理。

一开始就设计接口，又何尝不可呢？难道一开始就设计接口就是过渡设计吗？
接口出来，就一定要工厂来支撑它的实例化吗？

我的设计思路的实施总是是伴随着实现我的抽象接口展开的，当然抽象接口的提取应该是具体-->抽象--->具体设计的过程。

Help youself！

1、设计的复杂程度，不是“离散”而是“连续”的。
2、设计的复杂度，不是静止的，而是生长的。
3、复杂度的生长，不是全面的，而是有一定方向的。
4、提前设计，就是在准确预计复杂度生长的方向的基础上做出的设计。
5、过度设计，就是在无法预计复杂度生长的方向的情况下，在每一个方向加入灵活性。
6、如果一个类，只有一种用法，而你再给他加上一个接口，那么在需求没有稳定之前，每次改动，你可能需要同时改两个以上的文件。
7、如果你通过配置文件来定义，那么改动工作就转移到了配置文件。
8、总而言之，如果你在需求没有稳定下来之前，搞出n多的层次，来隔离变化，非常有可能出现的情况就是：当变化来临，你不但没有隔离变化，而且需要同时更改n多的文件。


从一开始就设计接口，然后你就会不断的同时修改类和接口的文件。我并不认为这是一个省力的办法。只有当需要接口的信号明确出现时，才是使用接口的好时机。

容器装配对象的概念深入人心，并不是让自己更加费力的理由。
美学也不是。

to 庄：

这个问题，你不应该问我，而是应该问Java之父，问他为什么要搞出一个Interface来！他自然会回答你。
至于这一句：
java代码，要改一样可以改。
C编写者大可以也跟着这样说：
我写的也是代码，你们OO者写的也是代码。大家改的也都是代码！又何来优劣之分呢？

我不是已经说了，什么时候才是使用interface的正确时机吗？

何必去问java之父？我又没有否定interface。

你拿C来跟我“扳道理”，何必呢？

千万不要以为只要是OO了，就能够写出好代码。
正好相反，OO语言，更加纵容程序员，写出垃圾的代码来。

这样的活，我干过，我也心安理的干过。干得也是顺心！
没有什么复杂，设计永远不可能准确。修改接口又何尝不可？你认为这种改动很复杂吗？相反，我不认为，倒是认为是进步的一步。

唉，言尽于此。

哈，我还言尽如此呢！
你问我interface的准确时机，那我也可反问你准确时机到底是什么时候？是等到系统完全可以运行了，interface才能准备设计吗？
你敢说你设计的interface在项目进展中不用改动吗？准确时机，我想这个词还是少用为妙！

我一开始就说过了。

当且仅当：一个类，有两个以上的用法时，才需要重构，为它加上interface。

主要的用途不是这里.

一般是说, 函数的参数类型, 返回类型, 类的成员类型声明为接口比直接用类好.

new B()这种东西, 很多可以被换成ioc,也就是说,你声明一个类型A的变量, 然后从构造器里面接受.