类之OCP(Open Closed Principle)：开闭原则

//z 2012-4-17 15:31:13 PM IS2120@CSDN
1. OCP 是什么？
OCP : OPEN CLOSED PRINCIPLE
对扩展开放，对修改关闭
Software entities should be open for extension, but closed for modification
//z 2012-4-17 15:54:58 PM IS2120@CSDN
1.1 扩展
通过继承、覆写、委托等实现新的功能

2. OCP的好处
通过扩展，满足新需求，使软件系统有灵活性
已有的软件模块，尤其是抽象层模块不再修改，使得软件具有稳定性和延续性
2.1 动机
架构稳定；又能满足变化中的需求
//z 2012-4-17 15:39:07 PM IS2120@CSDN
2.2 为何需要OCP
重用（那些在变更中不变的部分）

//z 2012-4-17 15:34:37 PM IS2120@CSDN
3. 如何实现？
抽象是解决问题的关键；抽象出不变的部分，与变化的部分相隔离。
//z 2012-4-17 15:53:08 PM IS2120@CSDN
3.1 系统设计阶段
在系统设计阶段，对系统可能发生变化的部分进行评估和分类，每一个可变因素都单独进行封装。（理想情况；极端）

//z 2012-4-17 15:35:52 PM IS2120@CSDN
4. 封装可变性
一种可变性应该存在于一个类中；而不是散落于代码各处
一种可变性不可与另一种可变性混合在一起；一般的继承层次不超过两层

//z 2012-4-17 15:37:49 PM IS2120@CSDN
5. OCP
5.1 软件实体（类、模块等）应对扩展开放，而对修改闭合。
5.2 按语：对于已存的代码不需要进行变更；所有新的功能都能够通过增加新的派生类并覆写方法来实现
或是通过委托使用已存的代码来实现。
5.3 不向已存的代码引入新代码，就不会向其中引入新bug
5.4 使用抽象类，由类实现接口

//z 2012-4-17 15:46:12 PM IS2120@CSDN
6. 关于OCP的对话
Shubho: Here goes the poster for the Open-Closed Principle:

Figure: Open Closed Principle poster

If I need to explain it in design oriented terms, it would be as follows:

"Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification."

扩展类的行为而不用修改类本身
At the most basic level, that means, you should be able to extend a class's behavior without modifying it. It's just like I should be able
to put on a dress without doing any change to my body, ha ha.

Farhana: Interesting. You can change your look by putting any dress you want, and you don't have to change your body for that. So you are
open for extension, right?

Shubho: Yes. In OOD, open for extensions means that the behavior of the module/class can be extended and we can make the module behave in
new and different ways as the requirements change, or to meet the needs of new applications.

Farhana: And your body is closed for modification. I like this example. So, the source code for a core class or module should not be
modified when it needs an extension. Can you explain with some examples?

Shubho: Sure, take a look at the following example. This doesn't support the "Open-Closed" principle:

Class hierarchy showing violation of Open Closed principle

client->server

You see, the Client and Server classes are both concrete. So, if for any reason, the server implementation is changed, the client also
needs a change.

Farhana: Makes sense. If a browser is implemented as tightly coupled to a specific server (such as IIS), then if the server is replaced
for some reason with another one (say, Apache) the browser also needs to be changed or replaced. That would be really horrible!

Shubho: Correct. So following would be the correct design:

Class hierarchy showing Open Closed Principle

client -> abstract server -- server

In this example, there is an Abstract Server class added, and the client holds a reference to the abstract class, and the Concrete Server
class implements the Abstract Server class. So, if for any reason the Server implementation is changed, the Client is not likely to require
 any change.

The Abstract Server class here is closed for modification, and the concrete class implementations here are open for extension.

抽象是关键；增加一个中间层
Farhana: As I understand, abstraction is the key, right?

抽象系统的核心概念，并作为双方交互的一个接口（类似TCP的各层设计）
Shubho: Yes, basically, you abstract the things that are the core concepts of your system, and if you do the abstraction well, most likely
, it would require no change when the functionality is to be extended (such as the server is an abstract concept). And, you define the
abstract things in the implementations (say, IISServer implements the Server) and code against abstractions (Server) as much as possible.
This would allow you to extend the abstract thing and define a new implementation (say, ApacheServer) without doing any change in the
client code.