一切观点都是从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在"没有银弹"中提出"所有软件
活动包括根本任务——打造构成抽象软件实体的复杂概念结构,次要任务——使用
编程语言表达这些抽象实体".软件活动必须用规范的软件工程来约束,卓越的设计,
明确的需求,通畅的交流,透明的管理才是真正的解决之道,也就是所谓的根本任务.
在一日千里的软件业,新技术,新开发工具,新算法层出不穷,但他们对软件产业的
影响都只是有限的.看到这一点,足以改变很多人的观点.作为学习者,为什么我们
要花时间去完成那些次要任务,而忽视掉跟产业相关的真正核心的部分呢?
我的观点,已经很明确了,那就是作一个切实的软件工程的实践者.用成熟的
方法论明确需求,用灵活的设计满足需求,我不追求技术,我只关注重要的部分,
我要用自己的实践经验来探清软件的真谛!
