「设计模式」4-开放封闭原则

开放封闭原则

软件实体(类，模块，函数等等)，应该可以扩展，但是不可以修改

对于扩展是开放的，对于更改是封闭的。

我们在做系统的时候，不要指望系统一开始时需求确定，就再也不会变化，既然需求一定会变化，那么如何在面对需求的变化时，设计的软件可以相对修改，不至于说，新需求一来，就要把整个程序推倒重来。

设计的时候，时刻要考虑，尽量让这个类足够好，写好了就不要去修改了，如果新需求来，我们增加一些类就完事了，原来的代码能不动则不动。

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

猜测程序可能的变化那确实不容易，但我们可以在发生小变化时，就及早地去想办法应对发生更大变化的可能。也就是说，等到发生变化时立即采取行动。

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

并不是什么时候应对变化都是容易的，我们希望的是在开发工作展开不久就知道可能的变化。查明可能发生的变化所等待的时间越长，要创建正确的抽象就越困难。

开放封闭原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护、可扩展、可复用、灵活性好。

开发人员应该仅对程序中呈现出频繁变化的那些部分做出抽象，然而，对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意。 拒绝不成熟的抽象和抽象本身一样重要.