一切观点都是从Structual Programming VS Object-Oriented Program开始.
结构化编程和面向对象编程最大的区别在什么地方?从历史看来,他们几乎都是 同时起步(甚至结构化在应用领域最初还领先于OO),所以可以公允地认为它们 曾经,仍然处于同一层次,知是两种不同的编程方法而已.(在这里编程不是仅指 Coding,而是指软件工程的life-cycle).最大的区别在什么地方,我认为是视角 不同.优秀的结构化把编程的"对象"看作一个个模块,这些模块中数据和操作是 分开的,但既成了模块,也就完成了一定的封装和抽象.以前经常说,用C就可以 实现OO的编程,现在想想当时错了,因为面向对象的特点是数据和操作本质上是 一个整体.结构化确实也可以实现把数据和操作封装在一起,但那成了耦合,不利 于重用.比如我用结构体来代表一个"对象",大家知道界面是纯数据(字段),然后 定义几个方法对结构进行操作(并把结构体作为方法的参数),当时觉得特别灵活, 因为如果要扩充哪个"对象",只需对结构体稍加修改,可是这样编程的结果恰恰 是那几个方法处于很尴尬的境地,因为他们被这个结构体紧紧地耦合住了,很难 扩展到其它类似的结构体.所以先前定义的结构体不是面向对象中的类,至少很 牵强.总结出以前的错误,可以看出,没有必要用OO的观点来应用于结构化领域. 他们的封装各有特点,各有所长.编程是用来解决实际问题的,所有的考量都应该 是来自于问题空间的反馈.问题空间又是多样的,有的时候需要把数据和操作绑 定,有的时候或许并不需要.
上面这段话的意思是,从我们学习编程的经历看,大都是先结构化,再到OO,这 种过渡过程很容易让人产生一种误会,即OO是从结构化优化而来的(所谓青出于 蓝胜于蓝),OO总是强于结构化的.现在,我想强调它们的平等性,然后来解释我 所认为的OO最显著的优越性.
前面说过,问题空间是多样的,另外,它还是变化的,如何应对变化,或者说,如 何用最小的代价来应对变化.引用一个常用的原则,就是"发现变化,封装变化", 在结构化中,要封装新的变化,我们很可能要做的是写一个新的方法或新的模块, 这样的变化一多,李铁都受不了.而在OO中,我们用一个接口来封装变化的对象, 在这个接口上,实现各种变化(即得到接口的各种含语义的子类),我们对这些变 化的操作应该都是面向这个接口的,于是又隐藏了变化的细节(不用针对各种变 化分别编程).类似的例子还有很多,面向对象领域的专家们很擅长撰写类似的 "神话",但它却不是神话,就发生在我们的身边,值得进行深刻的研究.我一直 在想,为什么面向对象具有这么多优点,却直到80年代才成为主流.也许,人类 需要更丰富的抽象才能得到它,也许他的易用行还有待考察.
在不懂OO时,很喜欢标榜自己是一个 OO-Programmer,可当我似乎理解了它,却只希望作一个自由的Programmer. 软件业面临的问题,不是某一个新兴技术就可以解决,不是一个面向对象就可以 解决,不是一个独立的软件工程就可以解决.不管是做Programmer,还是作Architect, 拘泥于某一方面,就只有死路一条.因此我选择用灵活的技术,适当的技术来使 自己的软件生存.将来如果做到软件工程管理,也尽量用务实,灵活的管理办法.
当然,在设计方面,面向对象仍然是我的首选,因为我最熟悉它,它确实也可以 解决所遇到的大多数问题.我象很多人一样,憧憬着自己拥有架构优良的软件财富, 可是,在我们拥有足够的设计能力之前,这种憧憬很难实现.很多时候,我们对着复 杂的问题无从下手,勉强设计出的东西,却有着天生的残疾.唯一的办法,只有孜孜 不倦的学习,用经验和创新来突破这些障碍.在这里,不得不提到设计模式.
从教育的角度分析,设计模式就是专家经验,共你学习和引用.从应用的角度分 析,它是解决方案,对应着情景,可重复性,可传授性等关键要素.后者甚至比方案 本身更重要.设计模式可以帮助我们了解一个优良设计完成的全过程,理解面向对 象编程的诸多原则,从而加强我们的设计能力.如果上面的阐述还不足以让您认识 设计模式,可以想想C语言的数据结构.我确实很反对把设计模式也当作一个"神话", 说白了,它是组织数据和操作的方案,GOF的"Design Patterns"中涉及的23种模 式甚至可以浅显地认为是23种特殊的数据结构.对于模式的理解,应该打破观念的 束缚,如果一个东西对应了"问题,场景,解决方案,可重复性,可传授性,名称"等要 素,他就是一种模式,你把它记在脑中或纸上,充分理解它,便成为了你自己的模式. 所以学习设计模式应该以一种开放,自由的心态,与自然世界展开充分对话.
充分利用设计模式,是一个不错的想法,但若想要用设计模式来构造自己的软件 体系,则是不切实际的,甚至容易陷入过度工程的误区.因为软件体系是一个复杂 的整体,又可以用模式语言表达的部分,也有无法用模式语言表达的部分.谈到构架 系统,我们需要更多的学习.这些学习逐渐从软件工程出发,需求分析,UML,RUP等等. 完备的方法学可以培养和释放创造性的思维,直到一个普通人拥抱逐渐完善的系统.
前段时间困惑地思索"什么是软件" 的问题,今天又得到了新的启示. 启示一:软件说到底还是一个工程学,它在冥冥中必定存在着合理的解释. 启示二:软件的复杂性来自于需求的变化,因为有人的参与而无法控制,参透它的 本质也很难奏效. 现在看来,谈"软件是什么"还为时过早,它还必须经历漫长的"规范化过程",为解决 她带来的方方面面的难题制造正式的方案.Brooks在"没有银弹"中提出"所有软件 活动包括根本任务——打造构成抽象软件实体的复杂概念结构,次要任务——使用 编程语言表达这些抽象实体".软件活动必须用规范的软件工程来约束,卓越的设计, 明确的需求,通畅的交流,透明的管理才是真正的解决之道,也就是所谓的根本任务. 在一日千里的软件业,新技术,新开发工具,新算法层出不穷,但他们对软件产业的 影响都只是有限的.看到这一点,足以改变很多人的观点.作为学习者,为什么我们 要花时间去完成那些次要任务,而忽视掉跟产业相关的真正核心的部分呢?
我的观点,已经很明确了,那就是作一个切实的软件工程的实践者.用成熟的 方法论明确需求,用灵活的设计满足需求,我不追求技术,我只关注重要的部分, 我要用自己的实践经验来探清软件的真谛! 
|