谈谈开闭原则(OCP)的翻译问题和我的理解

OCP（Open-Close Principle）：软件实体应该可以扩展，但不可以修改。

一开始看到开闭原则时，我觉得这个说法非常扯淡，还不是一般的扯淡。不能修改这个可能吗？人的认知和推动软件发展的硬件都是在进步的，你却在说不能修改。

而且从这个理论的提出时间：1988到今天2012-08-11，24年了有哪个软件做到了这个原则？！

但在后续的学习中发现很多文章都在说，而且我想我的对OO的理解肯定是不如提出原则的大师。于是有了看看原文的想法（本人英语非常的差）。

原文：Software entities should be open for extension,but closed for modification

Software entiies:应该是指类体系结构上某个非最终的子节点。否则扩展一说毫无意义。

should be open for extenstion。but close for modification：直译为“对扩展开放，对修改关闭”，看起来没有问题但我知道大师也明白：“修改是不可避免的”。

所以我的理解是：but close for modification并不是指关闭对类函数、属性的修改，而是对实体所代表意义的修改，例如：一个表示“车”的类，但不能修改为表示具有“人”这个类的东西。否则“车”下的“自行车”，“汽车”这些子类将变得面目全非。

举一个例子，某国企的员工结构如下：

员工

正式员工  招聘员工 劳务派遣员工

解释：正式员工一般为领导，招聘来的一般是真正干活的，劳务派遣的一般是扫地，保安等等。

假设一个需求：公司需要向正式员工和招聘来的员工发公司通知这类短信，现在公司决定给所有的正式员工发手机，发出的短信要求发在发给员工的手机号码上，原来的员工自有手机不再发送。但招聘来的员工还是向其自有手机上发短信。

于是：修改不可避免的出现，无论你是把发短信的功能定义为接口让正式员工或招聘员工这两个类去实现，还是在员工类上加一个虚函数（SendShotMessage）让能实现的类去覆盖。为实现这个需求你总是不能避免修改类和加上实现方法。

但不管怎么改，员工还是员工，不会变成一辆车，也不会变成一台电脑。我想这才是开闭原则的真正理解。

所以我的理解：软件实体应该是可以扩展的，但不能因修改而改变它在抽象层次上的确定性。