4.3　何时应对变化

小菜：“啊，有道理。所以，我们尽量应在设计时，考虑到需求的种种变化，把问题想得全了，就不会因为需求一来，手足无措。”

大鸟：“哪有那么容易，如果什么问题都考虑得到，那不就成了未卜先知，这是不可能的。需求时常会在你想不到的地方出现，让你防不胜防。”

小菜：“那我们应该怎么做？”

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

小菜：“这可能做到吗？我深表怀疑呀，怎么可能写完一个类就再也不改了呢？”

大鸟：“你说得没错，绝对的对修改关闭是不可能的。无论模块是多么的‘封闭’，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须先猜测出最有可能发生的变化种类，然后构造抽象来隔离那些变化[ASD]。”

小菜：“那还是需要猜测程序可能会发生的变化，猜对了，那是成功，猜错了，那就完全走到另一面去了，把本该简单的设计做得非常复杂，很不划算呀。而且事先猜测，这又是很难做到的。”

大鸟：“你说得没错，我们是很难预先猜测，但我们却可以在发生小变化时，就及早去想办法应对发生更大变化的可能。也就是说，等到变化发生时立即采取行动[ASD]。正所谓，同一地方，摔第一跤不是你的错，再次在此摔跤就是你的不对了。”

大鸟：“在我们最初编写代码时，假设变化不会发生。当变化发生时，我们就创建抽象来隔离以后发生的同类变化[ASD]。比如，我之前让你写的加法程序，你很快在一个client类中就完成，此时变化还没有发生。然后我让你加一个减法功能，你发现，增加功能需要修改原来这个类，这就违背了今天讲到的‘开放-封闭原则’，于是你就该考虑重构程序，增加一个抽象的运算类，通过一些面向对象的手段，如继承，多态等来隔离具体加法、减法与client耦合，需求依然可以满足，还能应对变化。这时我又要你再加乘除法功能，你就不需要再去更改client以及加法减法的类了，而是增加乘法和除法子类就可。即面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码[ASD]。这就是‘开放-封闭原则’的精神所在。”（样例代码见第1章）

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

小菜：“这个我能理解，如果加减运算都在很多地方应用了，再考虑抽象、考虑分离，就很困难。”

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

小菜：“哦，我还以为尽量地抽象是好事呢，看来过犹不及呀。”