[设计模式学习笔记][之二]面象对象单挑结构化设计

面象对象VS结构化设计

历史的车轮不会停止前进的脚步，正是由于人们在使用标准结构化设计时遇到了不少难题，才促成面的向对象概念的产生。今天我们再次提起标准化结构设计为我们带来的困扰，就是为了更好的看到面向对象程序设计的优点，更好的理解这一机制。

具体的案例往往比抽象的概念更容易让人接受，所以我们就从一个任务开始吧！

上司安排了这样一个任务给你：编写一个程序，读取数据库中的几何形状的描述，再把得到的几何形状显示出来。如果你是一个没有接触过面象对象的标准化结构设计师，很自然你会考虑分步骤完成这个任务。你可能会按照下面的步骤来处理：
1、在数据库中查找几何形状的列表
2、打开形状列表
3、将这个列表排序
4、显示单个的几何形状

上面所采用的方法可以叫做“功能分解”，因为分析者将问题拆分成多个功能步骤。这些步骤组合起来就可以解决问题。因为把问题分成小块来处理，比一次处理整个问题要简单得多，这与“个个击破”是一个道理。你是这样做的，我也是这样做的，大家都是这样做的，我们如此自然如此经常地使用这种方法处理问题，以至于我们很少对它提出质疑，习惯终成自然了。

难道就真的没有问题吗？当然有了，功能分解的问题是：它不能帮助我们应对未来可能发生的变化，它不能帮助我们的代码优雅地演变。变化是一定会发生的，就拿上面的案例来说，我们可能要追加处理新的形状或显示形状的方法。如果我们把上面这些步骤的所有逻辑都放在一个大的函数或模块中，那么，这些步骤中的任何一个发生一点变化，我们都必须改变这个函数或模块，正可谓：牵一发而动全身，这不是我们想要的。

除此之外，变化的发生还为错误和意外结果的发生创造了机会。或者，正如某人所说的，许多错误都来自于代码的变化。

你是否遇到过这样的时候：你想在代码中做一些修改，但又不敢这么做，因为你知道对一个地方代码的修改可能在另一个地方造成破坏。为什么会这样？是否写一处代码时，必须注意它所有的函数和所有使用这些函数的方式？一个函数怎么样与另一个函数交互？对于一个函数，是否有太多的细节--诸如尝试实现的逻辑、交互的对象、使用的数据，等等--需要去注意？就跟人一样，试图同时关注过多的东西，就等于邀请错误与变化同时来到你的身边。

一句话，这世上没有一成不变的事物！不管你多么努力地尝试，不管你把分析做得多么好，你永远也无法知道用户所有的需求。关于未来有太多的未知数。事物总是在变化的... ...

变化是无法阻止的，那我们就要勇于去面对变化，我们未必一定会败在它的脚下... ...