由来：
怎么样的设计才能面对需求的改变却可以保持相对稳定，从而使得系统可以在第一版本以后不断推出新的版本呢？bertrand meyer 在1988年提出的著名的开发—封闭原则（the open-closed princle)为我们提供了指引。
遵循开放—封闭原则设计出的模块具有两个主要特征：
1. “对于扩张是开放的”（open for extension)
这以为着模块的行为是可以扩展的。当应用的需求改变时，我们可以对模块进行扩展，使其具有满足那些改变的行为。也就是说，我们可以改变模块的功能。
2. “对于更改是封闭的”（closed for modification）
对模块行为进行扩展时，不必改动模块的源代码或者二进制代码。模块的二进制可执行版本，无论是可链接的库、dll都无需改动。
这两个特征看似矛盾，怎么可能在不改模块源代码的情况下去更改它的行为呢？怎样才能无需对模块进行改动的情况先就改变它的功能呢？
关键是抽象
在c++中，可以创建出固定却能够描述一组任意个可能行为的抽象体。这个抽象体就是抽象基类，而这一组人一个可以能的行为则表现为可能的派生类。
这个基类就是不需要修改的，里面的成员方法（接口）声明为纯虚函数，具体的实现可以在派生类去实现、更改、扩展。
应用OCP，可以把一个功能通用的部分和实现细节部分清晰的分离开。
在实际应用中，设计人员必须对于他设计的模块应该对哪种变化封闭做出判断。他必须猜测出最有可能发生变化的一些行为，然后构造抽象来隔离这些变化。
这需要设计人员具备一些从经验中获得预测的能力， 需要设计人员对应用领域很了解，能够以此来判断各种变化的可能性。然后，他才能设计出合理的OCP。
事实上，很难在第一次设计中就能预测出所有可能的变化，
所以，我们怎么隔离变化呢？
1、只受一次愚弄
有句谚语：“愚弄我一次，应该感到羞愧的是你。再次愚弄到我，应该感到羞愧的是我。”这也是一种有效的对待软件设计的态度，我们会允许自己被愚弄一次。这以为着在我们最初编写代码时，假设不会发生变化。但变化发生时，我们就创建抽象来隔离以后发生同类的变化。简而言之，我们愿意被第一颗子弹击中，然后我们会确保自己不会再被同一只枪发射的其他子弹击中。
2、刺激变化
如果我们决定接受第一颗子弹，那么子弹到来的越早越好，我们就会越早的发现问题，解决问题。我们希望在开发工作展开不就就知道可能发生的变化。查明可能发生的变化所等待的时间越长，要创建正确的抽象就越困难。正所谓早发现早解决
因此，我们需要去刺激变化：
*编写测试
*使用很短的迭代周期进行开发
*尽早地、经常性地发布软件。尽可能频繁地把软件展示给客户和使用人员，得到他们的反馈。
总结：
在许多方面，OCP都是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处（灵活性、可重用性以及可维护性）。然而，并不是说只要使用一种面向对象语音 就是 遵循了这个原则，对于应用程序中每个部分都肆意的进行抽象同样不是一个好注意。正确的做法是，开发人员应该仅仅对程序中呈现出 频繁变化的那些部分做出抽象。拒绝不成熟的抽象和抽象本身一样重要。