1.5 开发技术——实用还是时髦？

“现在我们具体介绍一下编程范式。”冒号忽然顿住，隐觉一抹失望从众人脸上掠过，问号更是欲言又止，便鼓励他开口。

问号略显迟疑：“您说编程范式是一种心法，那框架、设计模式还有架构呢？”

“原来如此！”冒号心下了然，“让我说说你们最想听些什么吧。”

众现不信之色。

冒号说道：“一种是具体而实用的，最好能立马解决学习和工作中的问题；一种是时髦而花哨的，管它有用没用，不学点心里就是不踏实。”

众人虽觉此话有些尖刻，细想起来也有几分道理，但老冒明知而不为，不走群众路线，偏去扯什么劳什子的范式——当然，直接谈OOP倒是不错的。

“自以为懂的未必真的懂，自以为不懂的未必真的不懂。” 冒号玩起了玄学，“有些概念和技术即使背得烂熟，甚至用得烂熟，那也不代表真正掌握；有些概念和技术看起来很新奇，却不过是新瓶装旧酒。”

叹号颇不服气：“用得烂熟都不算掌握，难不成只有发明概念和技术才算掌握？”

“哈哈，那倒不必。”冒号笑道，“用得烂熟不等于用得恰到好处，能解决问题不等于没有后顾之忧。”

逗号问道：“那掌握的标准是什么？”

“许多应聘者喜欢在简历中言必称精通某某语言、某某技术云云，大多不必面试即知其大言炎炎——倘若真的精通，他自当应聘更高的职位。”冒号有感而发却又似不着边际，“任何概念和技术都不是孤立的，如果不能在纵向的时间和横向的联系中找准坐标，便似那群摸象的盲人，各执一端却又自以为是。”

众人心想，老冒虽言辞旦旦却有凿空之嫌，一节课下来，天马行空的扯了不少，真刀真枪的一个也无，该不是只会纸上谈兵吧？

句号紧扣主题：“您为何选择谈编程范式，而不是框架、设计模式还有架构呢？难道它们真如您所说只是时髦而花哨的东西吗？”

“我可没这么说。”冒号矢口否认，“但在弄清一样东西存在的意义之前就随众跟风，早晚会跟丢的。我先问问你们：什么是框架（framework）？它与一般的库（library）和工具包（toolkit）有何不同？”

引号应答：“框架就是一组协同工作的类，它们为特定类型的软件构筑了一个可重用的设计。与库和工具包不同之处在于前者侧重设计重用而后两者侧重代码重用。”

“嗯，有点标准答案的味道。”冒号夸道，“如果吹毛求疵的话，框架并不限于OOP，可以是协同工作的类，也可以是协同工作的函数。一个足够复杂的应用软件开发，为确保快速有效，通常采取的方式是：在宏观管理上选取一些框架以控制整体的结构和流程；在微观实现上利用库和工具包来解决具体的细节问题。框架的意义在于使设计者在特定领域的整体设计上不必重新发明轮子；库和工具包的意义在于使开发者摆脱底层编码，专注特定问题和业务逻辑。”

问号提出问题：“框架与库和工具包看起来很相似——都是一些代码集合，都提供一些API（应用编程接口），是什么使得它们不同呢？”

“问得好！”冒号赞言，“框架与工具包最大的差别在截然相反的设计理念上：库和工具包是为程序员带来自由的，框架是为程序员带来约束的。具体地说，库和工具包是为程序员提供武器装备的，框架则利用控制反转（IoC）^[1]机制实现对各模块的统一调度从而剥夺了程序员对全局的掌控权，使他们成为手执编程武器、随时听候调遣的士兵。”

叹号苦着脸：“程序员原来就是一小卒子啊！”

“哪个将军不是从小卒做起的？”冒号反问道，“不错，框架是在语言的语法规则之外施加于程序员的又一层枷锁，但没有规矩不成方圆。正如行军打仗，讲究排兵布阵，程序员就是那兵，框架就是那阵。”

句号说：“可不可以这么理解，框架就是一些人——也就是框架设计者，把一个软件开发中最甜的部分啃掉了，剩下部分留给下面的人？”

“从某种意义上说，是这样。”冒号点点头。

逗号很不甘心：“我就想啃最甜的部分。”

“当心别把牙给崩掉。”冒号笑道，“不是打击你，首先你还没那本事；其次即使你有本事也未必有机会；最后即使有本事也有机会，重新设计框架也未必是好的选择。就说大名鼎鼎的Struts吧，哪怕你设计出比它更高明的框架也难以被采用，因为前者早已成为Java平台上网络开发的事实（de facto）标准，公司很容易从市场上招到懂Struts的程序员，不必培训即可上手，成本低见效快。过去许多公司都有自己的网络框架，但最后大多都放弃了，并不是因为Struts更优秀，而是因为它更普及。毕竟大多数软件开发是以金钱而不是技术为中心的。”

问号提议：“您能谈谈设计模式和架构吗？”

冒号侃侃而谈：“与框架与库和工具包不同，设计模式（design pattern）和架构（architecture）不是软件产品，而是软件思想。设计模式是软件的战术思想，架构是软件的战略决策。设计模式是针对某些经常出现的问题而提出的行之有效的设计解决方案，它侧重思想重用，因此比框架更抽象、更普适，但多限于局部解决方案，没有框架的整体性。与之相似的还有惯用法（idiom），也是针对常发问题的解决方案，但偏重实现而非设计，与实现语言密切相关，是一种更底层更具体的编程技巧。至于架构，一般指一个软件系统的最高层次的整体结构和规划，一个架构可能包含多个框架，而一个框架可能包含多个设计模式。”

引号愈发疑惑：“这些不是都很重要吗？”

“当然都很重要。不过——”冒号话锋一转，“在没有打好基础前，架构只是空中楼阁，因此不可能现在谈它。至于框架，不同的应用领域有不同的框架，如表现层的Struts、业务层的Spring、持久层的Hibernate等等，即使相同领域的框架也有多个选择，更不用说不同的语言框架还不一样，从何谈起？再说框架其实一点也不高深，完全可以无师自通，关键是领会思想，多学习多实践。说到设计模式，一共就那么几十个，一本‘四人帮’（GoF）^[2]的书足矣，自己慢慢去啃，又何须多谈？简言之，一个谈之过早，一个无从谈起，一个不必多谈。”

下面开始交头接耳窃窃私语起来。

“知识的学习有几种方式：一种靠记忆，一种靠练习，一种靠培养。就拿英语学习来说吧，学单词，单靠记忆即可；学句型、语法，光记忆是不够的，需要勤加练习方可熟能生巧；而要讲出地道的英语，光记忆和练习是远远不够的。从小学到大学，甚至博士毕业，除了英语类专业的学生外，大多数人英语练了一二十年，水平如何？不客气但很客观地说：一个字，烂；两个字，很烂；三个字，相当烂！口语甚至连一个英语国家的三岁小孩都不如。”冒号越说越激动，“原因只有一个，那就是国内的英语教学方式严重失策。教学总是围绕单词、词组、句型、语法转，缺乏对语感的重视和培养，导致学生只会‘中式英语’。同样道理，一个惯用C语言编程的人也许很快就能写一些C++程序，但如果他只注重C++的语法而不注重培养OOP的语感，那么写出的程序一定是‘C式C++’。与其如此，倒不如直接用C呢。”

句号悟道：“您是想告诉我们，学习编程范式能增强编程语言的语感？”

“一语中的！”冒号庆幸总算没有白费口舌，“语感是一个人对语言的敏锐感知力，反映了他在语言方面的整体上的直觉把握能力。语感强者，能听弦外之音，能说双关之语，能读隽永之作，能写晓畅之文。这是一种综合的素质和修养，其重要性是不言而喻的。那么如何培养语感呢？普通的学习和训练固不可少，但如果忽视语言背后的文化背景和思维方式，终究只是缘木求鱼。编程范式正体现了编程的思维方式，因而是培养编程语言的语感的关键。现在如果我开始介绍范式，你们还有意见吗？”

众人受了鼓动，个个把头摇得跟拨浪鼓似的。

冒号语重心长地说：“既然范式关乎语感，就需要慢慢的培养和渗透，不可能一蹴而就，因此有些地方不太明白也没关系。现在只是撒下一些种子，慢慢的会生根发芽，直至长成大树。那些设计模式、框架甚至架构等等看似神秘高深的东西，都会自然而然地在这棵大树上结出果实。到那时，你们个顶个的都是内外兼修的武林高手了。怎么样？大家准备好了吗？”

“准备好了！”众人齐声道，求知的目光再度点燃。

“准备好了就下课吧。”冒号狡笑着，“下节课，下节课我们再谈。”