面象对象VS结构化设计
历史的车轮不会停止前进的脚步,正是由于人们在使用标准结构化设计时遇到了不少难题,才促成面的向对象概念的产生。今天我们再次提起标准化结构设计为我们带来的困扰,就是为了更好的看到面向对象程序设计的优点,更好的理解这一机制。
具体的案例往往比抽象的概念更容易让人接受,所以我们就从一个任务开始吧!
上司安排了这样一个任务给你:编写一个程序,读取数据库中的几何形状的描述,再把得到的几何形状显示出来。如果你是一个没有接触过面象对象的标准化结构设计师,很自然你会考虑分步骤完成这个任务。你可能会按照下面的步骤来处理:
1、在数据库中查找几何形状的列表
2、打开形状列表
3、将这个列表排序
4、显示单个的几何形状
上面所采用的方法可以叫做“功能分解”,因为分析者将问题拆分成多个功能步骤。这些步骤组合起来就可以解决问题。因为把问题分成小块来处理,比一次处理整个问题要简单得多,这与“个个击破”是一个道理。你是这样做的,我也是这样做的,大家都是这样做的,我们如此自然如此经常地使用这种方法处理问题,以至于我们很少对它提出质疑,习惯终成自然了。
难道就真的没有问题吗?当然有了,功能分解的问题是:它不能帮助我们应对未来可能发生的变化,它不能帮助我们的代码优雅地演变。变化是一定会发生的,就拿上面的案例来说,我们可能要追加处理新的形状或显示形状的方法。如果我们把上面这些步骤的所有逻辑都放在一个大的函数或模块中,那么,这些步骤中的任何一个发生一点变化,我们都必须改变这个函数或模块,正可谓:牵一发而动全身,这不是我们想要的。
除此之外,变化的发生还为错误和意外结果的发生创造了机会。或者,正如某人所说的,许多错误都来自于代码的变化。
你是否遇到过这样的时候:你想在代码中做一些修改,但又不敢这么做,因为你知道对一个地方代码的修改可能在另一个地方造成破坏。为什么会这样?是否写一处代码时,必须注意它所有的函数和所有使用这些函数的方式?一个函数怎么样与另一个函数交互?对于一个函数,是否有太多的细节--诸如尝试实现的逻辑、交互的对象、使用的数据,等等--需要去注意?就跟人一样,试图同时关注过多的东西,就等于邀请错误与变化同时来到你的身边。
一句话,这世上没有一成不变的事物!不管你多么努力地尝试,不管你把分析做得多么好,你永远也无法知道用户所有的需求。关于未来有太多的未知数。事物总是在变化的... ...
变化是无法阻止的,那我们就要勇于去面对变化,我们未必一定会败在它的脚下... ...