大话设计模式--第四章 开放封闭原则

开放--封闭原则：

一、概念

开放-封闭原则, 指的是软件实体（类， 模块， 函数等等）应该可以扩展， 但是不可修改。

这个原则其实有两个特征, 对于扩展是开放的, 对于更改是封闭的. 做法: 对变化点进行抽象

我们在做任何系统的时候, 都不要指望系统一开始时需求确定, 就再也不会变化, 这是不现实也是不科学的. 那么如何在面对需求的变化时, 设计的软件可以相对容易修改。不至于说， 新需求一来， 就把整个程序推翻重来。怎么样的设计才能面对需求的改变时， 可以保持相对稳定， 从而使得系统可以在第一个版本以后不断推出新的版本呢？ 答案是： 开放-封闭原则。

第一点:尽可能的将类设计的足够好

开放--封闭原则意思是说: 你设计的时候, 时刻要考虑, 尽量让这个类足够好。写好了，就不要去修改了，如果新需求来了， 我们增加一些类就完事了， 原来的代码能不动则不动。

第二点: 提前预测变化点, 对变化点进行抽象隔离

然而, 绝对的对修改关闭时不可能的。无论模块是多么的封闭，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对于他设计的模块应该对哪些变化封闭做出选择。他必须先猜测出最有可能发生的变化种类，然后构造抽象来隔离那些变化。

但是, 猜测程序可能发生的变化的话, 猜对了, 那是成功, 猜错了, 那就完全走到另一面去了, 把本该简单的设计, 做的非常的复杂. 这很不划算呀. 而且,事先猜测, 这是很难做到的.

那么, 我们应该如何做呢?

我们很难预先猜测, 但我们却可以在发生小变化时, 就要及早想办法应对发生更大变化的可能。也就是说， 等到变化发生了， 立即采取行动。 正所谓， 同一个地方摔倒一次可以， 如果再次摔倒， 那就是自己的不对了。

我们最初编写代码时， 假设变化不会发生， 当变化发生时， 我们就创建抽象来隔离以后发生同类的变化。

面对需求, 对程序的改动是通过增加新代码进行的, 而不是更改现有的代码。

应对变化的时间点:

我们要尽可能在开发工作展开不久就知道可能发生的变化，查明可能发生的变化所等待的时间越长， 要创建正确的抽象就越困难。

开发-封闭原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现出频繁变化的那部分做出抽象，然而， 对于应用程序中的每个部分都刻意地进行抽象， 同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要。