稍事休整后，大家重新团结在以冒号为中心的周围。

问号再度发问：“编程范式与设计模式都是一种抽象的软件思想，都有一套具体的实现方法。单从字面上看，‘编程’与‘设计’、‘范式’与‘模式’的区别似乎也不太大。它们究竟有什么不同呢？”

“这个问题有点意思。”冒号颔言，“设计模式一般针对某一特定场景的问题，而编程范式针对的是广泛得多的问题领域，通常有一整套的思想和理论体系，具有全局性、系统性和渗透性，这一点在五大重要范式中显得尤为突出。因此，编程范式更普适更抽象，涉及的深度和广度也是设计模式难以比拟的。”

引号不免有些疑问：“但事件驱动式不是也能作为设计模式吗？”

冒号解疑：“这倒并不矛盾。同样的思想用在整体系统的结构设计上，则称为架构模式；用在局部模块的细节实现上，则称为设计模式^[1]；用在引导编程实践上，则称为编程范式。”

句号的武侠瘾又犯了：“设计模式好比组合套路，能在一些特定场合下克敌制胜；编程范式则好比武功门派，博大精深且自成体系。”

“很形象的比喻。”冒号赞赏道，“设计模式是遵循设计原则的一些具体技巧，以保证代码的可维护性、可扩展性和可重用性为目的。它重在设计，对编程语言一般没有要求^[2]。编程范式则不同，对编程语言往往有专门的要求。通常所说的某某范式的语言，即指该语言对该范式在语法上有明确充分的支持，不需要借助其他的范式或工具。事实上，语言本来就是围绕其所倡导的核心范式来设计的^[3]。”

逗号询问：“如果一种语言不支持某种范式，那么还能用这种范式编程吗？”

“语言不直接支持范式，只是说明它不属于该范式的语言，但还是可能求助工具来应用该范式。比如元编程可以借助Yacc或ANTLR来完成，AOP可以借助一些库或框架来实现。”冒号道，“正是依靠语言和工具的支持，编程范式得以建立起一套独特而完善的抽象机制和方法体系，从而为所倡导的世界观与方法论奠定基石。”

叹号请求：“能不能帮我们理清一下思路，把学过的范式一并汇总比较？”

不一会儿，众人面前呈现出一张表格，地毯似的覆盖了整个投影屏（如表4-1所示）——

叹号怔了怔，好似被一张巨大的烙饼给噎住了。

冒号并不急于讲解，欲以静制动。

果然，逗号沉不住气了，问道：“在第一栏的编程范式及其代表语言中，为什么并发式的代表语言没有Java和C#，只有Erlang和Oz？”

“Java和C#虽然在语法和核心库中为并发编程提供了不少支持，但真正将并发范式融入基本设计理念的语言还得数Erlang、Oz这些较为冷门的语言。”冒号解释，“类似地，比起Java、JavaScript等语言来，C#和VB.NET在语言设计上对事件驱动式编程给予了更多的关注^[4]，因而更具代表性。”

问号发现：“第三栏‘关键突破’的提法很特别啊。”

冒号轻捶桌面以示强调：“一种编程范式之所以能独树一帜，关键在于它突破了原有的编程方式的某些限制，带来革命性的新思维和新方法，进一步解放了程序员的劳动力。这便是范式的核心价值所在。”

引号如获至宝：“这张表格浓缩了范式的精华，既是对此前知识的总结，也是对今后编程的指导，实在太有用了！”

句号显得更为冷静：“有其长必有其短。我们了解了每种范式的长处，是不是还应该了解它们各自的短处？”

冒号开始对各个范式逐一数落：“过程式编程的数据与代码脱节，不方便维护；函数式和逻辑式的开发效率一般比过程式高，但运行效率和语言表现力则有所不如；对象式编程用于数学计算、符号处理等对象特征淡薄的领域，在心理上缺乏认知基础，在运行效率上不如纯过程式，在开发效率上不如函数式；并发式编程增加了代码的复杂度，加重了程序员的负担；泛型式编程影响了代码的可读性，过度使用模块还可能造成代码膨胀（code bloat）^[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呢。”

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

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

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

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

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

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