对于OCP原则的困惑

我对OCP原则的困惑：

ocp原则的基本思想是对于扩展是开放的，对于更改是封闭的。该原则在java中的实现是通过接口完成的，可是在具体操作中功能的扩展是一定会出现变化的，这样怎么是对更改是封闭的呢？

比如说我定义了一个接口Interface A，他的一个实现class B，我在调用B来完成功能时这样做A temp = new B();

这样的话当我给他另外一个实现class C时，我的客户段代码还是要改变的：
A temp = new C();

这也不是封闭的呀？

以上是我的理解，请各位指教小弟一下

我的理解不是正统的观点，在我看来，关键不是那些1234的OO原则，而是总的代码数量。

也就是说，在n次修改以后，你的总代码数（第一次的代码数＋每次修改改动的代码数）最小，那么你的设计就是最合理的。

可以用工厂方法

[code:1]A temp = factory.getInstance();[/code:1]

在一个reasonable的架构下，没有任何client代码会直接去new一个对象。

对于“对于扩展是开放的，对于更改是封闭的”
我的理解是：当我们需要功能扩展的时候，我们所要做的不是修改老的代码而是增加新代码

to:庄表伟

我同意你的理解，也就是说只要是能使我们的代码在需求变更时变动的尽量少，那就是好的设计。

to:Robbin

用工厂方法的话，那就是更改是在工厂里完成的，可是对于客户端来说，仍然需要显视地指出具体工厂，

A temp = factory.getInstance();

这句里factory应该是个具体工厂吧，或者说他实例化的时候应该是具体工厂吧，这是我对抽象工厂的理解，请你指教

工厂可以有很多实现。最起码，你可以读配置文件决定创建哪个类的实例。

这个也就是Ioc有用的地方了，你可以在你的客户代码里面只是声明一个接口的引用比方 A temp ;但是这个接口A的实现不是自己new的，而是由外部注入，比如用实现Ioc的容器spring 或 pico。这样就消除了对具体实现的依赖。

或者就是用factory 和 service locater 模式也可以达到同样的效果。

to gigix :这里这个client 指的是什么？到最后对象还是用new来生成的啊？那么由谁来生成对象是合理的呢？

由工厂或者容器来生成，client永远不应该知道自己究竟创建了哪个对象。所以以前说没有大量工厂的程序不是好的程序。现在有了dependency injection的容器，工厂也可以省掉很多，但client就更不应该知道如何创建对象了。