Structure vs OO

子夜将至，窗外零星灯火，偶得一书，不忍释卷。时而皱眉，时而喃喃，时而怔怔，时而抿唇。或言之“得惊世之奇书乎？”余乃示书名，但见一考试指导之书也，庸庸之属何奇哉。乃其珍也在于发人之思，通一窍而醒其身尔。于是伏案疾书，既恨无潘江陆海之才，又恐见笑于大方之家。

 

 

actually，上面文绉绉的瞎扯不过是深夜无人解闷时的自我娱乐，看文之诸君（倘若有的话），尽可付之一笑。

 

今天很难得在同一本书上同时看到“结构化开发方法”和“面向对象的开发方法”这两个词语。顺着作者的行文思路仔细想了几遍，突然有种豁然开朗的感觉。

结构化的开发方法，始创于上个世纪七十年代，迅速克服了软件开发不成体系，没有既定的标准的缺点，成为了商业社会主流的开发方法。随着商业环境愈发复杂，用户对于软件的要求也在不断的提高，并且总是存在着不可控的变化，面向对象的分析方法应运而生，相对于之前的各种方法，面向对象的方法首倡把对象的概念从现实生活中抽象出来，将整个系统看成一个互相影响的对象集。

 

几乎所有中国式的教科书，在讨论两个方法的优劣、异同的时候都喜欢列清单，
比如：
相同点 and 不同点
优势1、2、3（通常针对某个方面或者某个层面） and 劣势4、5、6
最后用马克思辩证的方法来说，各有优劣嘛，结合起来合理应用嘛，具体情况具体分析嘛。

我在上面这样说出来，并不代表我要批判这种通式，又或者我要在下文中使用什么新的好方法来阐述这个问题，事实上，我也打算这样“通式”一下。

Structure
说到结构化开发方法，那么就不得不说一下冯诺依曼计算机。可以说冯诺依曼先生对推动人类社会发展做出了卓著的贡献。现代计算机绝大多数都是源自冯诺依曼型计算机的模式，在处理事务的时候，将事务不断细化，直至不可分割的最小单位，交由CPU按一定方法排序然后顺序执行。
同样，结构化地开发方法则是将复杂的问题比如业务功能，信息流动等等逐步有序分解到可解决的程度。概括起来就是自顶向下、逐层分解。它必须具备一些假定，问题域是可以被直接从需求中定义的，问题域是有限的，问题通过逐层分解是可以被解决的。这显然有些过于理想化了。
举例来说，如果面对一个十分庞大而且复杂的系统，分析是一个十分浩大的工程，分解层次越多，得到的结论以及需要处理的信息越多，又有更多需要进一步细分的模块，如果被这些枝枝蔓蔓所迷惑，则有可能一叶障目，从而导致项目失败。
而且，往往客户也不知道自己到底需要什么，我现在的系统有什么问题？怎样的新系统能使我满意？而如果在实现没有很好的理解客户真正的需求，一旦开始整个项目，重新定位的成本将是可怕的。
结构化的开发方法对于人与机的界限是分明的，系统是一个过程集，人有人做事的流程与功能，机器有机器接受传递的数据和执行调用的方法。

OO
作为当前炙手可热的方法论明星“面向对象”似乎有着各种优点，比如类的封装与继承可以更好的实现抽象、模块化、内部信息隐藏等等，不同对象之间联系依靠接口来实现。面对问题域，面向对象的方法首先从问题域中抽象出可以理解的一种描述或解释--“类”，然后进行观测，看这个解释所对应的（或者说实例化的）对象是否符合在现实世界的对应事物。显然，比起结构化的方法，面向对象的方法对于开发者抽象事物，把握本质的能力要求要更高一些。
由于采用封装的方式，采用面向对象的方法可以将错误控制可追溯的小范围内。但若是在定义阶段，对于问题理解有误，或者抽象的方式并不正确，之后的类继承程度过高，修改的代价也是巨大的。

题外话

写到这里突然想到一个题外的问题，结构化开发方法有各种开发平台，各种优秀的面向过程的编程语言，面向对象的开发方法也有各种平台与语言，然而目前的计算机并没有脱离冯诺依曼模式，也就是说即使是用面向对象的程序设计语言，在面向对象的开发方法的思路下，最终的执行依旧是顺序执行，然而面向对象的语言又多了各种继承各种接口以及对Runtime的搭建，执行速度显然会比面向过程的语言更慢一些。面向对象未来的发展会怎样呢?

另外一个问题就是，并不是开发项目的每一个类都可以完全从现实世界里抽象出来的,所以有时候有的例子就有些不是依照现实生活经验抽象出来的，而是依照面向对象方法的习惯性思维抽象出来。

 

总之
两个开发方法并不是对立的，也不是绝对有优有劣的。放在不同的环节中，或者不同的情况下，可以做出不同的选择。比如即使你使用面向对象的开发方法，在分析数据处理信息流向的时候也可以使用结构化的分析方法，因为此二者更具有问题的确定性，按一定步骤层层分解可以更好的把握整体结构以及减少出错机会。总之在合适的时候选择合适的方法，一切方法都只是你完成自己工作，企业实现自己既定的组织目标的工具。