冒号调整了焦点：“鉴于目前专注的范式是OOP，参数多态最好放在以后的GP专题再作探讨。除非特别说明，下面提到的多态专指子类型多态。谈到这类多态，就不得不提及抽象类型。谁来说说，究竟什么是抽象类型？”

冒号抬手内扬，摆出了对练的姿势。

叹号率先抢攻：“抽象类型指的是至少含有一个抽象方法的类型。”

冒号轻松化解：“在C++中这句话尚可勉强成立，但在Java和C#中则大不尽然：一个类即使没有一个抽象方法也可以被申明为抽象的；一个没有任何成员的空接口或称标记接口同样属于抽象类型。”

“抽象类型是指无法实例化的类型。”逗号发起二次进攻。

冒号见招拆招：“Java中的Math类也不能实例化，原因是它只有private构造器，并且没有一个能返回实例的静态方法。C#中的Math类是静态类，同样不能实例化。”

问号纵身而上：“抽象类型指能且只能通过继承来实例化的类型。Math类是final类，无法被继承。最主要的是，它的价值体现在它的静态方法上，压根儿就没有实例化的必要。”

冒号借力反打：“为什么要强调无法实例化呢？”

引号一旁助攻：“一个抽象类型代表着一个抽象概念，而抽象概念自然是无法具化的。比如你无法实例化抽象的形状，但可以实例化长方形、三角形等具体的形状；无法实例化抽象的水果，但可以实例化苹果、桔子等具体的水果。”

“很官方的说法。这就好比将继承关系说成‘is-a’关系一样，理论上虽通俗易懂，实践上却不足为训。”冒号收起架势，“要说抽象，Java和C#中的Object类可谓包罗万象，该够抽象了吧？不照样实例化？列表（list）与映射（map）是抽象的还是具体的？在C++中它们是具体类型，而在Java和C#中它们却是抽象类型^[1]。这又是为什么？”

一连串的反问让大家陷入沉思。

“相比其他编程范式，OOP更贴合客观世界，人们经常用打比方的形式来描述和理解OOP的一些概念和思想。这本身并无不妥，但一定要保持清醒的头脑：浅显的比方只是门槛前的台阶，借之或可拾级入门，却无法登堂入室。”冒号谆戒道，“天下之理皆同，天下之人皆同，故凡学问殿堂之前皆一般景象：入门者众，入室者寡。本班的目的便是，引导诸位从徘徊于编程之门左右的人群中越众而出，早达内室。”

“那就成了传说中的内室弟子吧？大伙在门边转悠很久了，头都发晕了，师父还是快些领我等入室吧。” 逗号近乎戏谑地恳求。

冒号一笑：“我可算不得你们的师父，只不过是个闻道在先的师兄而已。”

一直没有出手的句号忽然开腔：“抽象是个相对概念，一个类型是否是抽象的完全取决于设计者对它的角色定位。如果想用它来创建对象，它就是可实例化的具体类型；如果想用它来作为其他类型的基类，它就是不可实例化的抽象类型。”

“这才击中了要害！”冒号不禁喝彩道，“整理一下你的观点：具体类型是创建对象的模板，抽象类型是创建类型的模块。一个是为对象服务的，一个是为类型服务的。显然，后者的抽象性正是源自其服务对象的抽象性。就拿刚才的实例来说，模板方法模式中的Authenticator类是抽象的，是为创建子类型SimpleAuthenticator、Sha1Authenticator等服务的；策略模式中的Authenticator类是具体的，是为创建对象服务的，但它合成的两个接口KeyValueKeeper和Encrypter又是为创建算法类型服务的。值得注意的是，不要把抽象类型与抽象数据类型（ADT）混为一谈，后者的抽象指的是类型的接口不依赖其实现。或者说，抽象数据类型的核心是数据抽象，而抽象类型^[2]的核心是多态抽象。”

问号想让概念更明确些：“抽象类型就只有接口（interface）和抽象类（abstract class）两种吗？”

“在Java和C#中基本上是这样，但在C++中这两种类型没有显式的区别^[3]。”冒号，“此外，动态OOP语言如Ruby、Python、Perl、Scala、Smalltalk等还至少支持mixin和trait中的一种类型。mixin直译为‘混入’，trait直译为‘特质’，为避免翻译上的问题，今后我们还是采用英文术语。这两种类型大同小异，为简便起见，下面以mixin类型为代表^[4]。它们的出现是为了弥补接口与抽象类的一些不足，更好地实现代码重用。我们知道，接口的主要目的是创建多态类型，本身不含任何实现。子类型通过接口继承只能让代码被重用，却无法重用超类型的实现代码。抽象类可以重用代码，可又有多重继承的问题。Java和C#不支持这种机制，C++虽支持但有不少弊端。”

引号奇道：“这个问题上节课不是已经解决了吗？用合成来代替继承啊。”

冒号解释：“合成是一种解决办法，但也不是没有缺陷。首先，合成的用法不如继承那么简便优雅，这也是许多人喜欢用继承的主要原因；其次，合成不能产生子类型，而有时这正是设计者所需要的；再次，合成无法覆盖基础类的方法，也无法访问它的protected成员；最后，却可能是最大的缺点是：合成的基础类只能是具体类型，不能是抽象类型^[5]。”

逗号不明所以：“这能算是缺点吗？”

“如前所述，具体类型的主要任务是创造新对象，如果用作合成或继承的基础类，等于是又承担了原本抽象类型的任务——创造新类型。这不仅有越俎代庖之嫌，而且这两个任务往往也是冲突的。我们曾提出，一个类的服务应该有纯粹性和完备性。一方面，人们希望创造的新对象无所不能，因此更看重服务的完备性，倾向它包含尽可能多的功能；另一方面，人们又希望创造的新类型有所不依，因此更看重服务的纯粹性，倾向它包含尽可能少的功能。”冒号擘肌分理，“妥协的结果是，一个新类型往往只用到基础类型的部分功能，却可能受到其他功能变动的影响。虽然这种影响在良好的封装之下会大大削弱，但也难以完全消弭。”

句号思索片刻，已明其意：“换句话说，以具体类型为代码重用的基本单位，难免颗粒度过大？”

“然也！”冒号的手在空中挽了个花，“其实作为抽象类型的接口也有类似的尴尬：对它的客户类来说，它承诺的服务是多多益善；对它的实现类来说，承诺越多负担却越重。如果能有这样一种可重用的模块，既不像具体类型那样面面俱到，又不像接口那样有名无实，也没有抽象类的多重继承之弊，岂不妙哉？”

“想必就是mixin了！”叹号眼中闪过一道光芒，旋即又暗淡下来，“只可惜Java并不支持啊。”。

“Java不支持就没兴趣了？” 冒号听出他的话里有话，“要成为优秀的程序员，千万不能画地为牢、自我禁锢。始终要保持一颗开放的心，不要拘于某些语言或范式，也不要囿于某些概念或技术。”

叹号的耳根有点发热。

“陌生的理论和技术开始总是拒人千里，不过一旦你了解其问题来源，它们会慢慢变得和蔼可亲起来。”冒号循循善诱，“既然具体类型和现存的两种抽象类型均有不足之处，mixin的产生便合情合理了。它是具体类型与接口类型的一种折衷，既可有抽象方法，也可有具体方法。这一点类似抽象类，但又没有抽象类的多重继承问题。举例来说，Ruby中的Comparable就是一个简单却很典型的mixin。”

问号插话：“Java中也有Comparable接口啊。”

冒号道出其中差异：“Java中的Comparable和C#中的IComparable只有一个抽象的比较方法，而Ruby中的除了有类似的抽象方法——比较（<=>）之外，还提供了小于（<）、小于等于（<=）、等于（==）、大于（>）、大于等于（>=）和介于（between?）等六种具体方法。显而易见，多出的方法均可通过唯一抽象的比较方法来实现。”

引号一点即通：“如此一来，重用Comparable的类只需实现一个抽象方法，便可自动拥有另外六个有用的功能。这既满足了客户类的需求，又不增加实现类的负担。”

“买一送六，这买卖划算！”逗号来劲了。

冒号双眼微眯：“更划算的买卖是Ruby中Enumerable。任何包含该mixin的类只要实现一个遍历方法each，便可免费得到二十多个有关遍历和搜寻的方法。如果再实现比较方法<=>，还可获赠排序和最值方法。相比Java中Enumeration和Iterator接口，优势历然。”

问号很好奇：“为什么称为mixin呢？”

冒号述说由来：“冰淇淋中经常会掺混一些薄荷、香草、巧克力之类的调味料和花生、坚果之类的小零碎，人们管它们叫mix-in。后来被借用来表示一种抽象类型，主要有如下特点：一、抽象性和依赖性：本身没有独立存在的意义，必须融入主体类型才能发挥作用；二、实用性和可重用性：不仅提供接口，还提供部分实现；三、专一性和细粒度性：提供的接口职责明确而单一；四、可选性和边缘性：为主体类型提供非核心的辅助功能。”

“这些特点与风味添加料还真的颇为神似。”叹号想着想着，嘴里不自觉地咂摸了一下。

“虽然C++、Java和C#在语法上尚不支持mixin，但C++可通过多重继承、Java和C#可通过合成和接口来分别模拟mixin。不仅如此，借助切面式编程（AOP），Java和C#甚至可完全实现mixin；借助泛型式编程（GP），C++也能通过模板更好地实现mixin^[6]。”冒号点到为止，“就此我们重温前面提到的两个观点。一是编程范式之间的合作性：mixin属于OOP的范畴，但其他编程范式如切面式、泛型式以及二者背后的元编程都能与之相通；二是设计与语言的相关性：C++、Java和C#以及其他诸如Ruby、Python等动态语言对mixin有着不同的支持方式，这在一定程度上会影响系统的OOP设计。”

引号憧憬道：“语言是在发展的，说不定哪天Java也会支持mixin的。”

冒号以实相应：“Java的动态小兄弟Groovy在1.6版已经开始支持mixin ，而C#3.0也新引入了对mixin更友好的语法特性^[7]。”

逗号提了一个长期困惑大家的问题：“每当一个新技术出现，我就觉得很矛盾：不追怕落伍，追吧又怕落空。如何判断一个它是昙花一现，还是大势所趋呢？”

“任何技术都是在赞美与批判中成长起来的，预测它们是流星还是恒星绝非易事。就拿OOP来说，上个世纪六十年代就出现了支持OOP的语言^[8]，但直到九十年代中后期它才真正成为主流的编程范式。这段时间恐怕比大多数人的程序员生涯还长吧。再说mixin，其实并非今日的重点，介绍它的目的不是盲目追新，而是希望透过其背后的需求驱动点，重新审视现有技术。至于它今后会不会为主流语言所接纳，反倒不是那么重要了。如果一定要我给个建议，那就是八个字：‘不执一法，不舍一法’。”冒号以禅语作答，“软件技术这棵大树经过多年的快速成长，早已枝蔓丛生。欲臻不执不舍之境，当如开班导言中所说：究其根本以知过去，握其主干以知现在，察其生长点以知未来。我之所以倾向于用抽象的方式来谈论技术，正是因为抽象的东西更接近根、更接近干、更接近生长点，从而更普泛深刻，也更稳定持久。”

句号借机问道：“您认为抽象比具体更重要？”

“抽象与具体无所谓孰高孰低，它们只是功用不同而已。”冒号轻轻晃了晃脑袋，“正所谓：必先以术养道，而后以道御术。也就是说，在学习时应注重从具体知识中领悟抽象思想，在应用时应注重用抽象理论来指导具体实践。类似地，软件开发也是如此：从具体需求中构建出抽象模型，再根据抽象模型来完成具体实现。因此，在设计阶段抽象类型尤为关键，而在实现阶段则是具体类型更为重要。”

问号表示理解：“假如从具体需求直接跨到具体实现，省去中间的抽象建模过程，那还用得着架构师和分析师吗？”

“话虽不错，但疑似倒果为因。”冒号洞若观火，“是否有必要抽象建模，关键看项目需求。如果需求简单而稳定，一步到位又何尝不可？甚至软件的开发效率和运行效率还更高——为劈几根细柴而磨刀，值吗？如果需求复杂而多变，引入抽象方有‘磨刀不误砍柴工’之效。毕竟抽象不是目的而是手段，对它片面的追求反会导致过度的设计。”

众人这才发现，给老冒戴顶“抽象派”的帽子是有些冤枉他了，应该是“抽象现实派”的。

冒号续道：“为进一步认识抽象类型，我举个非常实用的例子。它只适用于C++，而不适用于Java和C#。如果你对这一点感到遗憾的话，不要忘记我们的原则：具体实例永远是为抽象思想服务的。”

幻灯一闪，现出一段C++代码——

/** 一个不可复制的类 */
class NonCopyable
{
protected:
    // 非公有构造函数防止创建对象
    NonCopyable() {}  
    // 非公有非虚析构函数建议子类非公有继承
    ~NonCopyable() {}
private: 
    // 私有复制构造函数防止直接的显式复制和通过参数传递的隐式复制
    NonCopyable(const NonCopyable&);
    // 私有赋值运算符防止通过赋值来复制
    const NonCopyable& operator=(const NonCopyable&); // copy assignment
};

/** NonCopyable的一个私有继承类 */
class SingleCopy : private NonCopyable {};

/** 测试代码 */
int main()
{
    SingleCopy singleCopy1;
    SingleCopy copy(singleCopy1); // 编译器报错：企图复制singleCopy1

    SingleCopy singleCopy2;
    singleCopy2 = singleCopy1; // 编译器报错：企图复制singleCopy1
    return 0;
}

冒号讲解道：“有些对象是不希望被复制的。比如一些代表网络连接、数据库连接的资源对象，它们的复制要么意义不大，要么实现困难。由于C++的编译器为每个类提供了默认的复制构造函数（copy constructor）和赋值运算符（assignment operator），要想阻止对象的复制，通常做法是将这两个函数私有化。引入NonCopyable后，它的任何子类将自动拥有不可复制的特性。这样为开发者节省了代码编写量，还免掉了相应的文档说明，使用者也一望而知其意，可说是一石三鸟。虽然NonCopyable从语法上说不是抽象类，但从本质上看是一种类似mixin功能的抽象类型。”

引号考量一番后说道：“单就它的功效而言，的确非常符合mixin的四大特点，只是它的子类用的是私有继承，而不是类继承或接口继承。”

“你说得很对。可问题是，我们并没有要求mixin或者trait一定要通过继承的方式来重用啊？事实上，有些mixin甚至可在运行期间产生，还能克服继承的静态缺陷。即使采用继承，一般也不满足‘is-a’关系。你总不能说草莓冰淇淋是一种草莓吧？”冒号淡淡地说，“先前你们总结出抽象类型有两个特征：需要继承和无法实例化，但它们并非本质，关键还是它的目的——为类型服务。提供可被继承的超类型只是一种服务方式，却非唯一的方式；无法实例化只因它不是为对象服务的，禁止实例化不过是语法上的加强，目的是让用户在编译期间就能发现用法错误。其实，即便NonCopyable类的构造函数是公有的，也不会有人去实例化。原因很简单，它的价值只有通过子类才能体现，这是由其抽象的本性所决定的。”

逗号有些奇怪：“为什么在Java中就没有类似的对象复制问题呢？”

“这是一个非常基础的问题，请容我下次再回答你。”冒号破天荒地没有立即解疑，“以下重点还是放在接口和抽象类上面，我们称之为基本抽象类型，以别于mixin、trait等其他抽象类型。我们先从语法上简单地对比一下这两种类型。”

屏幕上显示出一张表格（如表10-1所示）——

冒号简明扼要地总结：“C#的语法与Java的稍有不同，但二者在接口与抽象类的关键区别上还是一致的：接口不能提供实现但能多重继承，抽象类则正相反；接口只能包含公有的、非静态的、抽象的方法成员^[9]，抽象类则无此限制。”

问号言明难处：“从语法上区分它们并不难，难的是从设计上区分它们。”

逗号实话实说：“按照上节课‘提倡接口继承，慎用实现继承’的方针，应该倾向用接口而非抽象类。但总觉得接口太虚了，没有抽象类实在。”

引号反驳：“要说实在，具体类型更实在啊。”

叹号坦言：“在编程中经常需要用到标准的或第三方的类库，可查起API来经常是左一个接口右一个接口的，迟迟不见具体类型现身，心里哪个急啊！”

冒号打了个比方：“如果到包子铺买包子，作为客户你也许会认为包子是具体类型，但对提供包子的人来说它却是抽象类型。他一定会问你：是要肉包、菜包还是豆沙包？是要蒸包、煎包还是小笼包？他的铺子开得越专业，给你出的选择题越多，众口难调嘛。同样道理， 要建一个高度可重用的类库，一些接口是必不可少的。”

句号悟道：“接口的意义就在于：提供者不是擅作主张，而是推迟决定，让客户选择实现方式。”

“言之有理！类似地，抽象类的意义就在于：父类推迟决定，让子类选择实现方式。‘推迟’二字道出了抽象类型除创建类型之外的另一功用：提供动态节点。如果是具体类型，节点已经固定，没有太多变化的余地^[10]。反过来，要使节点动态化，一般通过多态来实现。由此，抽象类型常常与多态机制形影不离。”冒号稍加引申，“就说前面的验证类吧，用模板方法模式实现的Authenticator类将关键的方法交给子类SimpleAuthenticator或Sha1Authenticator处理，用策略模式实现的Authenticator类将关键的方法交给内嵌接口KeyValueKeeper和Encrypter的实现类处理。后者的两次接口继承比前者的一次实现继承多了一个动态节点，因而更加灵活。这也是为什么一个需要（M×N）个实现类，一个只要（M+N）个的原因。当然，这也不是完全没有代价的。比如要创建一个用SHA-1算法加密的验证类实例，两种方法对比如下——”

模板方法模式：new Sha1Authenticator()
策略模式：    new Authenticator(new MemoryKeeper(), new Sha1Encrypter())

冒号指点着黑板：“显然，后者无论是使用上还是性能上都比前者稍有不如。但权衡利弊，多数时候它仍是更好的选择。”

“包子铺的包子用料种类越多、做法越多，买一个包子越费事。但只要不到饿得发昏的地步，大家还是更喜欢花样更多的包子铺。看来我也不该再抱怨类库的接口过多了。”叹号心下释然。

“大家再看看这个电脑主板，开过机箱攒过机的人应该对它并不陌生。”冒号终于亮出了蓄藏已久的道具， “上面密密麻麻地布满了各种元件，那是它的实部，而我们关注的是它的虚部——各种插槽和接口，包括CPU插槽、内存插槽、PCI插槽、AGP插槽、ATA接口、PS/2接口、USB接口以及其他林林总总的扩展插槽等等。这些接口的存在，使得主板与CPU、内存条、外围设备以及扩展卡等不必硬性焊接在一起，大大增强了电脑主机的可定制性。”

引号受到启发：“主板与其他硬件就好比一个个的具体类型，那些插槽和接口就相当于一个个的接口类型。所有的硬件以接口为桥来组装合成，以机箱为壳来封装隐藏，一个新的具体类型——具有完整功能的主机便产生了。”

“比喻非常到位！” 冒号很满意，“不过准确地说，与接口类型对应的不是物理接口，而是接口规范。如果仅仅是物理接口，只能保证该接口适用于某种特定型号的硬件产品，却不能保证同时适用于其他型号或者其他类型的硬件。以大家熟悉的USB（Universal Serial Bus）接口为例，它能接入各种外部设备，包括鼠标、键盘、打印机、外置硬盘、闪存和形形色色的数码产品。这当然不是偶然的，因为所有厂家在生产这些硬件时均遵循了相同的业界标准——USB协议规范。换言之，任何一个与USB接口兼容的设备，都可看作是实现了此接口的具体类型，而主机对该设备的自动识别能力则可看作一种多态机制。”

“这下我更深刻地理解那句话了：接口继承不是为了重用，而是为了被重用。”句号品味道，“比如一个鼠标，可以有串行接口、PS/2接口、USB接口或者无线接口，还可以同时拥有多个不同类型的接口。无论怎样，它本身都是完整的产品，根本不需要重用主机上的其他硬件，它实现某些接口的目的完全是为了能被主机所用。”

逗号意识到：“看样子，硬件设计也需要OOP思想呢。”

“相比软件设计师，硬件设计师往往能更好地贯彻OOP的理念。”冒号加强了语气，“他们的对象化概念更清晰更自然，因为硬件模块比软件模块更实在更具体；他们更注重设计，因为硬件比软件的修改成本大得多；他们更注重设计重用，因为硬件重新发明轮子的成本普遍很高；他们更注重实现重用，因为无法在举手之间完成‘复制-粘贴’工作；他们更注重接口明确、封装完好，因为把内部的接口或结构暴露在外不仅难看，还容易带来缠绕、磨损、短路等问题；他们采用合成和接口来组装模块，因为硬件没有类似实现继承的机制。”

“看起来我们真得向硬件设计师取经了。”叹号有些信服了。

冒号旧话重提：“我们曾对OOP有过这样的描述：如果把OOP系统看作民主制社会，每个对象是独立而平等的公民，那么封装使得公民拥有个体身份，继承使得公民拥有家庭身份，多态使得公民拥有社会身份。补充一下，其中的继承主要指类继承，多态主要指接口继承带来的多态。经过这段时间的学习，大家对此有何见解？”

问号发表看法：“广义封装让每个类成为独立的模块，从而让每个对象具备了个体身份。狭义封装又进一步地把类的接口与实现分离，从而让每个对象具有显著的外在行为和隐藏的内在特性。继承机制可使一个类成为其他类的子类或父类，从而确立了对象在类型家族中的身份。至于多态嘛，嗯。。。”

问号努力想抓住若隐若现的头绪。

句号接过话头：“一个公民的社会身份是指他在社会中所处的地位和扮演的角色。比如，一个人在学校里是学生，在公司里是职员，在商店里是顾客，他真正的个体身份往往是被掩盖的。同样地，一个对象在与外界联系时，通常不以其实际类型的身份出现，而是在不同的场合下以不同的抽象类型的身份出现。我想，这大概就是多态带来的社会身份吧。”

“这种社会身份的意义何在？”冒号不动声色地问。

句号接着回答：“社会身份既是一种资格也是一种义务。比如在列车上有人得了急病，可以通过广播找医生。人们不用事先知道来者的具体个人身份，只要他是医生，就会放心地让他第一时间去救人。”

“这个比喻很恰当。”冒号赞道，“不用事先知道个人身份，不正说明广播呼叫的对象是一个多态的抽象类型吗？同理，当一个具体类型显式继承了一个接口，它的对象便拥有了个体身份之外社会身份：有资格以该接口的形式与外界打交道，也有义务履行该接口的职责。”

“咦，那为什么把社会身份归功于多态而不是继承呢？”问号发出疑问。

冒号释疑：“继承自然有功劳，毕竟子类型多态要建立在它的基础上。但如果没有多态机制，要确保一个对象的实际方法而不是其超类型的方法被调用，必须将其还原为具体类型，从而使社会身份变得几乎有名无实。”

问号憬然醒悟。

冒号继续深入：“对象每多一种社会身份，便多一条与外界交流的渠道。为什么遮遮掩掩地不肯以本来面目示人呢？非是羞于见人，盖因一般的具体类型在公共场合是不为人知的，只有少数核心库里的核心类是例外。即使侥幸被认识，也难被认可，因为那会以代码的复杂度和耦合度为代价。社会身份则不然，它远比一般的个体身份更容易被接受。”

逗号举出例证：“这就好比上课得有学生证，上班得有工作证，上火车得有火车票，上飞机得有登机牌。只要不是炙手可热的公众人物，很多场合都是认牌认证不认人的。”

“道理人人都懂，可总有不少人以为自己编写的类都是明星大腕，大有‘天下谁人不识我’的豪迈，无牌无证就敢到处乱窜。更有甚者，不用多态就算了，连封装也不要，简直是在裸奔嘛。”冒号揶揄道。

全班笑不可仰。

冒号恢复肃容：“谈到这里，我们不能不再次提到‘针对接口编程’的基本原则。它有一种建立于数据抽象之上的形式，能让用户只关心抽象数据类型的API接口而无视其具体实现。不过，它至少有两大局限。其一，虽然在接口不变的情况下，实现代码的改变不会影响客户代码，但仍需要重新编译，对于需要头文件的C++来说则需要更多的编译链接时间。其二，虽然相同的接口可以有多种实现方法，但它们不能同时并存，更无法动态切换。于是，另一种建立于多态抽象之上的形式应运而生。它把抽象数据类型隐藏在抽象类型的背后，从而提升了抽象接口。同一个抽象接口允许有多种实现并存，且能动态切换，新增、删除或修改某种实现也不会导致其他代码的修改或重新编译。方才我们从主体类的角度来看，它的对象尽量以社会身份参与社会活动；现在再从客户类的角度看，它会尽量召集有社会身份的对象。两相结合，以社会身份而非个人身份作为公民之间联系的纽带，正是针对接口而非实现来编程的社会现实版。”

问号有所顾虑：“可是，有不少具体类型并没有实现任何接口，也就没有社会身份。”

“排除设计不良的因素，没有抽象超类型的具体类型最常见的有两种可能。一种是与世隔绝，一辈子几乎足不出户，至多在小圈子里活动。典型的有非公有类、内部类、局部类等等。一种是名满天下，他的脸就是一张天然名片，他的个人身份也就是社会身份。典型的有基本数据类型、字符串类型、日期类型等通用数据类型以及特定领域的通用数据类型。可见，个人身份与社会身份并无绝对的界限。同样，家庭身份与社会身份也有交合之处，正如名门望族也可成为社会身份一样。典型的有Java IO库中的InputStream和OutputStream、Reader和Writer，以及UI库中的Component和JComponent等等。”冒号信手拈来，“因此我们谈到的社会身份，不必拘泥于接口，甚至不必限于抽象类型，关键是该类型是否具备了足够的通用性和规范性、稳定性和独立性、灵活性和专业性。还是应了那句话：抽象不是目的而是手段。再拿现实社会说事，每种社会身份都代表了个体与社会缔结的一种契约，它有如下的特点：独立而稳定——先于个体而存在，且不随个体的变化而变化；公开而权威——为人所知、为人所信；规范而开放——制定的协议标准明确，且允许个体在遵守协议的前提下百花齐放。毫无疑问，推行契约制将使社会大受其惠。首先，相同身份的个体可相互替换、新型个体可随时加入，而且不会影响整体框架和流程，保证了系统的灵活性和扩展性。其次，整体不因某一个体的变故而受冲击，保证了系统的稳定性和可靠性；最后，个体角色清晰、分工明确，保证了系统的规范性和可读性。”

引号非常注重概念：“社会身份所代表的契约对应的正是规范抽象吧。”

“每种身份都是规范抽象的结果。” 冒号推而广之，“具体地说，个体身份对应的规范抽象借助封装，以数据抽象（data abstraction）的形式出现；家庭身份对应的规范抽象借助继承，以类型层级（type hierarchy）的形式出现；社会身份对应的规范抽象借助多态，以多态抽象（polymorphic abstraction）的形式出现。至此，我们分别从行为和规范两个角度分别诠释了OOP的三大特征与公民的三大身份之间的关系。这也非常合乎情理：一个合理设计和实现的类，其对象的行为与规范本应保持一致。”

句号欲印证自己的想法：“我的理解是，接口是一个携带契约的角色标签，接口继承的作用就是静态地为对象贴上该标签，而多态机制的作用就是动态地让对象发挥该角色。因此，要赋予对象某个角色，就应该让相应的类去继承相应的接口。”

“你的前半部分表述得非常精当，后半部分则稍有瑕疵。”冒号评论道，“接口可用来代表角色，但角色却不一定要通过接口。正如你提到的，接口继承是静态的，而角色却可能是动态的。比如学生毕业后变成职员，职员升迁后变成经理等等。对于静态类型语言来说，这类问题的解决单靠接口继承是不够的，还需要利用合成等手段，或者利用前面提到的其他抽象类型如mixin或trait。”

叹号仍有疑惑：“接口的意义已经很清楚了，那抽象类呢？它们的区别真的很大吗？”

“我们已经从语法上比较了它们的区别，那些只是表象的东西。如果对语言规则的理解仅仅停留于语法层面，那么它更多体现为对实现的束缚。只有提升到语义层面，它才更多体现为对设计的保障。”冒号保持一贯高举高打的风格，“从语义上看，抽象类与接口的区别，并不比它与具体类的区别小多少。”

叹号错愕不已：“怎么可能？抽象类与接口好歹都是抽象类型啊。”

冒号反诘：“为什么不说抽象类与具体类好歹都是类呢？”

叹号一时无语。

“先看段历史吧。”冒号幽幽地说，“开始C++是没有抽象类型的，直到1989年C++ Release 2.0发布前的最后一刻，Bjarne Stroustrup才力排众议引入抽象类。从C++的前身C with Classes 开始算起，其间已经整整十年了。即便如此，它的意义在当时仍不为大多数人所认识。推出一个看似小小的语法特征竟会如此艰难，恐怕远远超出诸位的想象吧！有人幻想只通过看语法书就能完全领会语言的精髓，又与痴人说梦何异？”

冒号的声音渐渐激昂起来。

逗号为自己找到了安慰：“难怪当初学到抽象类时，总感到只知其意而不知其用。”

冒号紧接着说：“抽象类的出现，让两种不同角色的类在语法上有了明确的界定：具体类描述对象，重在实现；抽象类描述规范，重在接口。这种分工降低了用户与实现者之间的耦合度，大大减少了代码的维护成本以及编译时间^[11]。由于抽象类不是为了创建对象，它的实例化自然是没有意义的。又由于它是接口规范，在子类没有实现其所有规范之前，是不能实例化的，否则规范岂不成了一纸空文？在没有抽象类的语法之前，要实现类似的功能，唯一的办法是：在本该抽象的方法被调用时强行中止程序。烦琐丑陋不说，还只能在运行期间捕捉错误。在纯虚函数（pure virtual function）——相当于Java和C#中的抽象方法——被引入之后，任何含有抽象方法的类都是抽象类，编译器将保证它不会被实例化。”

问号连连点头：“从这个角度来理解抽象类的语法，一切都顺理成章了。不过，抽象类与接口的区别好像还是没有看到。”

谈到兴头，冒号出言更如下阪走丸：“从具体类中分离出抽象类是一次质的飞跃，从抽象类中进一步地分离出接口则是另一次飞跃。Java推出接口类型之时同样饱受质疑，最终还是经受了实践的考验，后又为C#所采纳。其实最初C++的抽象类是为了定义一组协议并强令各子类遵守，实质上正是Java和C#中的接口所起的作用。但在协议规范的实现过程中，可能会产生一些不完全实现类。允许这种类的存在固然是一种灵活的举措，但必须认识到它们与纯规范的抽象类已判若云泥。打个比方，如果把对象看作产品，把具体类看作一个制作产品的模具，那么接口就是模具的规格标准，而抽象类是在模具加工过程中产生的半成品。接口与抽象类无法实例化，模具规格与模具半成品也不能直接制作产品；一个具体类可以有多个接口，一个模具也可有多个不同方面的规格；一个具体类至多只能继承一个抽象类，一个模具也至多只能在一种模具半成品的基础上直接加工。”

引号细加回味：“如果具体类、抽象类和接口分别对应于模具、模具半成品和模具规格，那后两者的区别的确比前两者的区别还大。可是假如一个抽象类完全没有任何实现呢？抛开多重继承的限制，它与接口又有何区别呢？”

冒号辨析其别：“一个抽象类可以没有任何实现，但也随时可以加入实现。接口则不同，永远都不能有实现代码。这正是引入关键字interface的目的，明明白白地表明：此乃规范集合所在，杜绝任何自以为是、画蛇添足的实现。初看似乎不合常理：这不是自缚手脚、自废武功吗？殊不知自由源于自制。许多人为了贪恋一点点代码重用，总忍不住把一些实现放在本该只是规范的地方。一来，这模糊了规范与实现的界限，背离了接口与实现相分离的设计初衷。要知道，再完美的实现都有改动的余地，将其捆绑到规范中只会增加不稳定因素；再完美的实现也不应该影响其他的实现，先入为主只会降低灵活性。二来，带有实现的抽象类无法用于合成，必须通过类继承才能起作用，而实现继承的弊端我们已经见识过了。在有些情况下，规范的实现比较复杂，需要渐进实现，保留一些中间状态的抽象类也是合理的，但最初的接口最好保留。总不能因为有了模具半成品，就抛弃模具规格吧？以Java Collections Framework为例，既规范了Collection、Set、List、Map等接口，又为这些接口提供了抽象类和具体类，从而给了用户三种选择：直接利用具体类、扩展抽象类、直接实现接口，方便程度递减而灵活程度递增。”

句号进行反思：“我在想，为什么以前对接口总有本能的排斥心理？原因在于：满脑子更多想的是怎么让程序工作，而不是想怎么让程序工作得更好。因此更重视代码实现，比较忽视规范设计。”

众人皆有同感。

“确实，在缺乏设计观念的人看来，使用接口和脱裤放屁差不多。”冒号轻笑道，“特别需要注意一种常见的说法：接口是为了克服Java或C#中抽象类不能多重继承的缺点。这句话具有相当大的误导性，因为该处的多重继承是指多重实现继承，而接口甚至连单重实现继承都做不到！许多人对接口与抽象类的认识之所以模糊不清，原因是他们习惯于从定义和语法中寻找表象的答案，不习惯从本源和语义上进行本质的分析。然而不可否认，毕竟接口与抽象类提供了相似的抽象机制，在实践中往往确难抉择。因此光从语法上对比二者的差别是远远不够的，需要进一步在语义上进行对比（如表10-2所示）——”

冒号展开叙述：“先从本性上看：接口是一套功能规范集合，因此相同的接口代表相同的功能，多表示‘can-do’关系，常用后缀为‘-able’的形容词命名，如Comparable、Runnable、Cloneable等等。接口一般表述的是对象的边缘特征^[12]，或者说一个对象在某一方面的特征，因此能在本质不同的类之间建立起横向联系。由于一个对象可拥有多方面的角色特征，故而可有多种接口。与之相对地，抽象类是一类对象的本质属性的抽象，因此相同的抽象基类代表相同的种类，多表示‘is-a’关系，常用名词命名。抽象类一般表述的是对象的核心特征，只能在本质相同的类之间沿着继承树建立起纵向联系。由于一个对象通常只有一个核心，故而只能有一种基类。再从目的上看：接口是为了规范重用，让一个规范有多种实现，看重的是可置换性；抽象类主要是为了代码重用^[13]，能逐级分步实现基类的抽象方法，看重的是可扩展性。”

叹号追问：“演变指的又是什么呢？”

冒号答道：“严格说来，演变不属语义范畴，属于语法规则的一个推论。在系统演变过程中，接口与抽象类的表现差异很大。接口由于是被广泛采用的规范，相当于行业标准，一经确立不能轻易改动。一旦被广泛采用，它的任何改动——包括增减接口、修改接口的签名或规范——将波及整个系统，必须慎之又慎。抽象类的演变则没有那么困难，一则它在系统中用得没有接口那么广泛，更多地是家庭身份而非社会身份；二则它可随时新增域成员或有默认实现的方法成员^[14]，所有子类将自动得以扩充。这是抽象类的最大优点之一。不过接口也有抽象类所不具备的优点，虽然自身难以演化，但很容易让其他类型演化为该接口的子类型。例如，JDK5.0之前的StringBuffer、CharBuffer、Writer和PrintStream本是互不相关的，在引进了接口Appendable并让以上类实现该接口后，它们便有了横向联系，均可作为格式化输出类Formatter的输出目标。”

问号还留有一个疑点：“现在接口与抽象类之间的差异是越来越清晰了，我只是有一点一直没想通：标记接口究竟有什么用？它一个方法都没有，也就谈不上规范，也无法利用多态机制，继承这类接口又有何意义呢？”

逗号随口说：“这就好比有些社会身份是光挂名头不干事的虚衔，不足为奇。”

冒号回应道：“先需澄清一点，一个类型的规范不限于单个的方法，类型整体上也有规范，比如主要目的、适用场合、限定条件、类不变量等等。另外，接口的目的是为了产生多态类型，不能只看到‘多态’而忽略‘类型’。一个接口哪怕没有一个方法，也是有意义的。首先，接口是一种类型，有严格的语法保障和明确的语义提示，这也是静态类型的优势所在。让一个具体类继承特定接口，既凸显了设计者的用意，也授予用户针对性地处理该类型的权力。比如java.util.EventListener接口为所有的事件监听器提供了统一的根类型。其次，有时需要对某些类型提出特殊要求、提供特殊服务或进行特殊处理，而这些并不能通过公有方法来办到，也没有其他有效的语言支持。标记接口可担此任，成为类型元数据（metadata）的载体。比如给一个类贴上一个java.io.Serializable的标签，它的对象便能被序列化^[15]，具体工作由JVM来完成。用户也可以通过自定义私有的writeObject 、readObject等方法来定制序列化方式。值得指出的是，当标记接口仅仅用于元数据时，更好的办法是采用属性导向式编程（@OP），Java中的annotation、C#中的attribute即作此用。”

逗号摸了摸后脑勺：“原来标记接口并非虚有其名，还是在偷偷地干实事呢。”

冒号见时候已到，准备落下帷幕：“至此，我们探讨了OOP中最基本的机制——封装、最独特的机制——继承、最重要的机制——多态。在今天的课结束之前，请大家每人用一个关键词来形容自己眼中的OOP，并作简要说明。”

引号说：“责任——在契约化的公民社会中，最重要的是对自己、对家庭、对社会的责任感。”

问号说：“变化——采用封装以防个人之变，慎用继承以防家庭之变，采用多态以防社会之变。”

逗号说：“分合——数据与运算结合，接口与实现分离。”

句号说：“抽象——无论是封装、继承还是多态，都是施诸众对象之上的抽象机制。”

叹号说：“虚伪——用封装来掩盖内心，用多态来掩盖外表，提倡继承责任却不提倡继承财富！”

冒号欣赞道：“不错不错，虽然角度各异，但均深中肯綮。我也大可安心下课了！”

众人也乐得打道回府。

当冒号迈着不变的步伐出现在教室时，手上有了一点变化：左手仍拎着笔记本包，右手却多了一样东西。大家定睛一看，原来是个电脑主板，不由得暗自纳闷：难道软件课改成了硬件课？

冒号照例直入主题：“上节课我们对继承的利弊作了详细的分析，其中最重要的观点是：继承的主要用途不是代码重用，而是代码被重用。这依赖于两个前提，一个是在语义上遵循里氏代换原则，另一个是在语法上支持多态（polymorphism）机制。因此不妨说，对于静态类型语言来说，继承是多态的基础，多态是继承的目的。”

问号忍不住问：“为什么要强调静态类型呢？”

“还记得鸭子类型^[1]吗？那就是一种不依赖于继承的多态类型，也是动态类型语言一大优劣参半的特色。”冒号提醒道，“静态类型语言中的多态是动静结合的产物，将静态类型的安全性和动态类型的灵活性融为一体。它一般有两种实现方式：一种利用GP（泛型编程）中的参数多态（parametric polymorphism），一种利用OOP中的包含多态（inclusion polymorphism）或称子类型多态（subtyping polymorphism）。从实现机制上看，二者的不同之处在于何时将一个变量与其实际类型所定义的行为挂钩。前者在编译期，属于早绑定 （early binding）或静态绑定（static binding）^[2]；后者在运行期，属于迟绑定 （late binding）或动态绑定（dynamic binding）。从应用形式上看，前者是发散式的，让相同的实现代码应用于不同的场合；后者是收敛式的，让不同的实现代码应用于相同的场合。从思维方式上看，前者是泛型式编程风格，看重的是算法的普适性；后者是对象式编程风格，看重的是接口与实现的分离度。尽管二者从范式到语法、语义都大相径庭，但都是为着同一个目的：在保证必要的类型安全的前提下，突破编译期间过于严苛的类型限制。对于既是静态类型语言又是静态语言、既支持OOP又支持GP的C++、Java和C#而言，多态机制是保证代码的灵活性、可维护性和可重用性的终极武器。为了说明问题，我们看一个简单而实用的例子：编写一个类，让它能储存用户名和密码，以作今后验证之用。”

叹号一愣：“这题是不是太简单了？还有别的要求吗？”

冒号摇摇头。

引号却认为：“要求太少反而不好做。比如是把数据放在内存、还是文件或者数据库？密码以明文还是密文的形式存储？”

句号提出：“无论是数据的存放方式还是密码的加密方式，都不应该硬编码。”

“循此思路，我们就来编写一个可重用的抽象类。”冒号投放了一段Java代码——

/** 一个可以验证用户名和密码的类  */
abstract class Authenticator
{
    /** 保存用户名和密码  */
    final public void save(String user, String password)
    {
        if (password == null)
            password = "";
        store(user, encrypt(password));
    }

    /** 验证用户名和密码  */
    final public boolean authenticate(String user, String password)
    {
        String storedPassword = retrieve(user);
        if (storedPassword == null) return false; // 无此用户
            
        if (password == null)
            password = "";
        return storedPassword.equals(encrypt(password));
    }

    /** 保存用户名和加密过的密码  */
    protected abstract void store(String user, String encryptedPassword);

    /** 从用户名获取相应的加密过的密码  */
    protected abstract String retrieve(String user);

    /** 给明文单向（one-way）加密，默认不加密  */
    protected String encrypt(String text) { return text; }
}

冒号解说道：“该抽象类有两个public接口，一个用来保存，一个用来验证。它们用final修饰符来禁止子类覆盖，因为真正的扩展点是三个protected方法。其中store和retrieve是抽象的，encrypt有一个平凡实现。以此为基础，再根据实际需要来编写子类，具体实现这三个方法。”

幻灯片转到下一页——

import java.util.Map;
import java.util.HashMap;

/** 一个简单的验证类，数据放在内存，密码保持明文  */
class SimpleAuthenticator extends Authenticator
{
    private Map<String, String> usrPwd = new HashMap<String, String>();

    @Override protected void store(String user, String encryptedPassword)
    {
        usrPwd.put(user, encryptedPassword);  
    }

    @Override protected String retrieve(String user)
    {
        return usrPwd.get(user);  
    }
}

“我们利用HashMap来储存数据，密码保持明文。这大概是最简单的一种子类了。”冒号仿佛在轻轻地把玩着一件小物什，“为安全起见，最好还是将密码加密。于是我们设计了稍微复杂一点的子类——”

import java.security.MessageDigest;

/** 一个安全的验证类，数据放在内存，密码经过SHA-1加密  */
class Sha1Authenticator extends SimpleAuthenticator
{
    private static final String ALGORITHM = "SHA-1"; // SHA-1算法
    private static final String CHARSET = "UTF-8"; // 避免依赖平台

    @Override protected String encrypt(String plainText)
    {
        try
        {
            MessageDigest md = MessageDigest.getInstance(ALGORITHM);
            md.update(plainText.getBytes(CHARSET));
            byte digest[] = md.digest();
            // BASE64编码比十六进制编码节省空间
           //为简便起见用到了非标准的API，因此以下代码有警告 
            return (new sun.misc.BASE64Encoder()).encode(digest); 
        }
        catch (java.security.NoSuchAlgorithmException e)
        {
            throw new InternalError(e.getMessage());  // 不可能发生
        }
        catch (java.io.UnsupportedEncodingException e)
        {
            throw new InternalError(e.getMessage());  // 不可能发生
        }
    }
}

逗号质疑道：“不是具体类不宜被继承的吗？怎么Sha1Authenticator类却继承了具体类SimpleAuthenticator？”

冒号略表赞许：“很高兴你没有忘记这个原则。不过考虑到Sha1Authenticator类需要覆盖父类的encrypt方法，这么做也是情有可原的。当然最好选择让该类直接继承抽象类Authenticator，但作为示例代码，我们还是希望它简洁一些，不想让过多的细枝末节掩盖核心主干。下面是测试代码——”

public class TestAuthenticator 
{  // 为避免额外依赖，没有采用JUnit等单元测试工具
    public static void main(String[] args)
    {
        test(new SimpleAuthenticator());
        test(new Sha1Authenticator());
    }

    // 测试给定的Authenticator 
    private static void test(Authenticator authenticator) // 子类型多态
    {
        test(authenticator, "user", "password");
        test(authenticator, "user", "newPassword");
        test(authenticator, "admin", "admin");
        test(authenticator, "guest", null);
        test(authenticator, null, "pass");

        authenticator.save("scott", "tiger");
        assert(!authenticator.authenticate("scott", "TIGER")); // 大小写敏感
        assert(!authenticator.authenticate("SCOTT", "tiger")); // 大小写敏感
    }

    private static void test(Authenticator authenticator, String user, String password)
    {
        authenticator.save(user, password);
        assert(authenticator.authenticate(user, password));
    }
}

引号觉得眼熟：“这不是上节课讲的模板方法模式吗？”

“正是此公。”冒号确认，“该模式的核心思想是：固定整体框架和流程以保证可重用性，留出一些子类定制点以保证可扩展性。在测试代码的两个test方法中，传入的参数是Authenticator类，但数据存放和密码加密的方式是在运行中才确定的，即先后遵照SimpleAuthenticator类和Sha1Authenticator类的实现。这就是我们所说的子类型多态的效果——让不同的实现代码应用于相同的场合。假设没有多态机制，这种效果就只能靠if/else或switch之类的条件语句才能实现，非常地痛苦。”

冒号的眉头皱成了粗体的“川”字。

“还有更好的方法吗？”句号察言观色，断定老冒还留有后手。

果不其然，冒号的眉毛立刻又舒展开来，中气充沛地应道：“有！诸位请看——”

// 键值对的存取接口
interface KeyValueKeeper
{
    public void store(String key, String value);
    public String retrieve(String key);
}

// 加密接口
interface Encrypter
{
    public String encrypt(String plainText);
}

class Authenticator
{
    private KeyValueKeeper keeper;
    private Encrypter encrypter;

    public Authenticator(KeyValueKeeper keeper, Encrypter encrypter)
    {
        this.keeper = keeper;
        this.encrypter = encrypter;
    }

    public void save(String user, String password)
    {
        if (password == null)
            password = "";
        keeper.store(user, encrypter.encrypt(password));
    }

    public boolean authenticate(String user, String password)
    {
        String storedPassword = keeper.retrieve(user);
        if (storedPassword == null) return false;

        if (password == null)
            password = "";
        return storedPassword.equals(encrypter.encrypt(password));
    }
}

冒号加以引导：“如果仔细比较两种设计，就会发现它们很相似。后者只不过把前者对子类开放的接口合成为自己的两个成员。再看接口的实现类——”

class MemoryKeeper implements KeyValueKeeper
{
     private Map<String, String> keyValue = new HashMap<String, String>();

    @Override public void store(String key, String value)
    {
        keyValue.put(key, value);  
    }

    @Override public String retrieve(String key)
    {
        return keyValue.get(key);  
    }
}

class PlainEncrypter implements Encrypter
{
    @Override public String encrypt(String plainText)
    {
        return plainText;
    }
}

class Sha1Encrypter implements Encrypter
{
    private static final String ALGORITHM = "SHA-1";
    private static final String CHARSET = "UTF-8"; 

    @Override public String encrypt(String plainText)
    {
        try
        {
            MessageDigest md = MessageDigest.getInstance(ALGORITHM);
            md.update(plainText.getBytes(CHARSET));
            byte digest[] = md.digest();
            return (new sun.misc.BASE64Encoder()).encode(digest); 
        }
        catch (java.security.NoSuchAlgorithmException e)
        {
            throw new InternalError(e.getMessage());
        }
        catch (java.io.UnsupportedEncodingException e)
        {
            throw new InternalError(e.getMessage());
        }
    }
}

逗号比较后得出结论：“MemoryKeeper与SimpleAuthenticator、Sha1Encrypter与Sha1Authenticator除了超类型和方法访问修饰符外，其他毫无二致。”

屏幕滚动出另一段代码——

public class TestAuthenticator
{
    public static void main(String[] args)
    {
        test(new Authenticator(new MemoryKeeper(), new PlainEncrypter()));
        test(new Authenticator(new MemoryKeeper(), new Sha1Encrypter()));
    }	

    private static void test(Authenticator authenticator) // 隐含子类型多态
    { /* 同上，略 */}
}

“测试代码区别也不大，只是Authenticator的多态性更加隐蔽。”冒号如是说。

叹号挑剔说：“后一种创建实例稍显麻烦一些。”

“但它是以小弊换大利。”冒号朗声而道，“首先，后者用的是合成与接口继承，比前者的实现继承更值得推荐，理由在上堂课业已阐明。其次，假设共有M种数据存取方式，包括内存、文件、数据库等等；共有N种加密方式，包括明文、SHA-1、SHA-256、MD5等等。按第一种设计，需要（M×N）个实现类；按第二种设计，只要（M+N）个实现类。这还只是两种变化因素，假如需要考虑更多的因素，二者差距将更大。比如增加编码方式：加密后的数据可以选择费空间省时间的十六进制编码、费时间省空间的BASE64编码、省时间省空间却包含非打印字符的原始形式等；比如增加安全强度：引入salt、nonce或IV等^[3]；比如增加密码状态：已生效密码、未生效密码、已过期密码等等。对比下面的UML类图，孰优孰劣更加一目了然。”

众人眼前出现了两幅图——

图10-1. Authenticator的UML类图（模板方法模式）

图10-2. Authenticator的UML类图（策略模式）

冒号指着屏幕问：“图二不仅比图一少了三个实现类，而且可重用性也更高。大家说是为什么？”

引号应答：“图一中的九个Authenticator的子类只能作为验证类来重用，而图二中六个实现类不仅可以合作完成验证类的功能，还能分别单独提供键值存储和加密字符串的功能。”

冒号作出肯定：“这就是职责分离的好处。存储与加密本是两样不相干的工作，必要时可以合作，但平时最好分开管理，符合‘低耦合、高内聚’的原则。”

问号注意到图中的注释，遂问：“第二种采用的是策略模式？”

冒号颔首：“简单地说，策略模式（strategy pattern或policy pattern）的基本思想是：把一个模块所依赖的某类算法委交其他模块实现。比如Java中的Comparable和Comparator、C#中的IComparer就是比较算法的接口，当一个类的某个方法接收了此种类型的参数，实质上就采用了策略模式。”

逗号不以为奇：“这岂非很平常？”

“你认为设计模式真的高不可攀吗？”冒号反问道，“包括模板方法模式，你们很可能也在编程实践中采用过，只不过相交不相识罢了。”

句号看出：“模板方法模式与策略模式非常神似，都是把一个类的可变部分移交给其他类处理。”

“照你这么说，绝大多数设计模式都是神似的，这也是为什么我们不专门谈设计模式的缘故。GoF设计模式是OOP大树上结出的硕果，在你心中培养的OOP成熟之前，匆忙缔结的果实多半是青涩弱小的。”冒号忠告，“我们也不会对设计模式避而不谈，但凡提及都是水到渠成的产物。再说回这两种设计模式，虽然有相通的思想，也能解决相同的问题，在稳定性与灵活性之间都取得了某种平衡，但还是各有侧重的。模板方法模式突出的是稳定坚固的骨架，策略模式突出的是灵活多变的手腕。不妨拿国家政策作比：一个强调对内要稳，老一辈制订了大政方针，下一代必须在坚持原则的前提下进行完善；一个强调对外要活，不能或不便自行开发的技术不妨从国外引进。”

叹号一乐：“哈！设计模式上升到了政策模式。”

冒号抽丝剥茧：“正如模板方法模式可看作控制反转的特例，策略模式与依赖注射（Dependency Injection）也异曲同工。第二个Authenticator所依赖的两个功能KeyValueKeeper和Encrypter，就是是通过构造方法‘注射’进来的^[4]。当然策略只是一种特殊的依赖，是自内而外的——将算法抽出来外包；依赖注射的机制更复杂、涵盖面更广，是自外而内的——从外部嵌入定制功能。后者被广泛地用于框架应用之中，尤以Spring Framework和Google Guice为代表。”

引号听得起劲：“这下热闹了，设计模式、框架与OOP范式全搅和到一块了。”

“还有GP范式呢。”冒号顺接话题，“让我们再用C++的模板来实现一下Authenticator类吧。没有继续采用Java，是因为它的泛型仍离不开子类型多态。”

说着，他换上了C++代码——

#include <string>
#include <map>

using namespace std;

template <typename KeyValueKeeper, typename Encrypter>
class Authenticator
{
private:
    KeyValueKeeper keeper;
    Encrypter encrypter;
public:
    void save(const string& user, const string& password)
    {
        keeper.store(user, encrypter.encrypt(password));
    }

    bool authenticate(const string& user, const string& password) const
    {
        string storedPassword;
        if (!keeper.retrieve(user, storedPassword)) return false;

        return storedPassword == encrypter.encrypt(password);
     }
};

class MemoryKeeper
{
private:
    map<string, string> keyValue;
public:
    void store(const string& key, const string& value)
    {
        keyValue[key] = value;  
    }

    bool retrieve(const string& key, string& value) const
    {
        map<string, string>::const_iterator itr = keyValue.find(key);
        if (itr == keyValue.end()) return false;

        value = itr->second;  
        return true;
    }
};

class PlainEncrypter
{
public:
    string encrypt(const string& plainText) const { return plainText; }
};

class Sha1Encrypter
{
public:
    string encrypt(const string& plainText) const { /* 省略代码  */ }
};

namespace
{
    template <typename K, typename E>
    void test(Authenticator<K, E> authenticator) // 参数多态
    { /* 省略代码  */ }
}

int main()
{ 
    test(Authenticator<MemoryKeeper, PlainEncrypter>());
    test(Authenticator<MemoryKeeper, Sha1Encrypter>());
    return 0;
}

“以上代码与Java版的策略模式代码很相似，主要的区别是把KeyValueKeeper和Encrypter两个接口换成了模板参数。由于模板是在编译期间实例化的，因此没有动态绑定的运行开销，但缺点是不能动态改变策略^[5]。”冒号分析道，“至此，我们通过一个验证类的三种解法，分别展示了三种形式的多态：基于类继承的多态、基于接口继承的多态和基于模板的多态。它们殊途同归，都能让代码更简洁、更灵活、可重用性更高、更易维护和扩展。”

问号想到一个问题：“C语言既没有子类型多态也没有参数多态，又如何保证高质量的C程序呢？”

冒号眉梢轻挑：“C语言有指针啊，C++、Java和C#的多态在底层就是用指针实现的。C中的函数指针比Java中的接口更加灵活高效，当然对程序员的要求也更高。”

引号蓦地记起：“重载不也是一种多态吗？”

“刚才所说的多态都属于通用多态（universal polymorphism）。此外，还有一类特别多态（ad-hoc polymorphism），常见有两种形式。一种是强制多态（coercion polymorphism），即一种类型的变量在作为参数传递时隐式转换成另一种类型，比如一个整型变量可以匹配浮点型变量的函数参数。另一种就是重载多态（overloading polymorphism），它允许不同的函数或方法拥有相同的名字。特别多态浅显易懂，其重要性与通用多态也不可同日而语，故不在我们关注之列。只是要注意一点，正如子类型应遵守超类型的规范，同名的函数或方法也应遵守相同的规范。如果为贪图取名方便而滥用重载，早晚因小失大。”冒号告诫道。

逗号突发奇论：“一个多态类型的对象可以在不同的类型之间变来变去，是不是叫‘变态类型’更生动些？”

“我看你就属于典型的变态类型。”句号乘机拿他开涮。

全班哈哈大笑。

去年3月的一个下午，过于明媚的春光唤醒了一份久违的情怀，书摊上的一本《青年文摘》便成了合宜的载体。与其说是为了阅读，不如说是为了回忆——对20年前读书心境的回忆。孰料读罢开篇，怀旧之窗随即悄然关掩，一扇求新之门却戛然开启。那是一篇人物介绍，讲述一位籍籍无名的年轻人是如何因撰写博客而声名鹊起的。抚卷思之，网络平台已成大众舞台，人人皆可登台献技，自己何不前去一试？心念甫动，顿感技痒难耐，当晚寝不安席，于辗转反侧之中磨出了一本书的轮廓。

尽管钟书先生认为鸡与蛋应为松耦合关系，但一只来历不明的鸡确会招致人们对其产品可靠性的怀疑。故而在介绍《冒号课堂》的创作思路之前，先自我介绍一番。1986年我怀揣着成为数学家的梦想，考入武汉大学数学系。7年的大学生涯在浑浑噩噩中度过，毕业后在广州一所高校教了3年的高等数学。在混沌与迷茫中挣扎了10年，终于不堪蹉跎，1996年赴美攻读数学博士。始料不及的是，在大洋彼岸不仅没能一圆数学之梦，反倒从一个未曾碰过鼠标的电脑排斥者变成了一名IT工作者。“罪魁祸首”正是电脑和Internet，它们潜移默化地改变了人们的生活和思维方式，我亦未能幸免。1998年开始选修计算机课程，两年后拿到硕士学位，并在华尔街的一家软件公司找到了工作。2004年年底，选择回国发展，再度主导了人生的一次急转弯。回到广州后，顺利地进入了一家著名的外企。平淡而安逸的生活似乎注定与我无缘，不久又转去一家小公司作技术总监。如果用一句话来描述自己的职业生涯，那便是：数学是我的初恋情人，计算机是我的终生伴侣。无论成败，都是命运与人生双向选择的结果。

本书的创作虽出偶然，却也有其必然性。一方面，市面上的计算机书籍多为拼凑之作，且不少带有应试教育的痕迹。另一方面，论坛上充斥着各种谬言妄论，人们或目空一切，或人云亦云；每当争论一起，常常硝烟弥漫，出言无状者甚众。如此诸般，不忍卒睹。深感激浊扬清之必要，此念一直郁积于心，终至一朝爆发。自知虽无澄清玉宇之力，唯奢念带来一缕清风。

《冒号课堂》采用对话体，是为了借不同背景、不同水平、不同性格的人物之口，多层次、多维度、多角度地展现知识的内涵与活性。人物皆以标点符号命名，是为了塑造让人过目不忘的形象：冒号善解释，引号善引用，问号善提问，逗号善缓冲，叹号善感叹，句号善总结。此外，6个标点符号还对应着每小节的6个部分：冒号是正文讲解，引号是文献参考，问号是问题列表，逗号是补充插语，叹号是精华预览，句号是本节总结。与一般纯技术类图书不同，本书非常强调学习方法和学习精神的重要性。在内容组织上也一反常规，以思想为主、以知识为辅，以抽象为主、以具体为辅，以范式为主、以语言为辅。人们常把书籍比作一种食物，其实书籍也是一种药物。一本书应当同时提供两种价值：一种是让人获取正确知识的食用价值，一种是让人抛弃错误观点的药用价值。《冒号课堂》更侧重后者，这多少给读者带来一定的阅读障碍，因为抛弃往往比获取更加困难。此外，全书涉及的知识点较多，覆盖的知识面较广，一些流行的语言或技术反被刻意地淡化。假如读者没有足够的计算机理论和实践基础，难免会感到一些困难和不适。古语有云：“学然后知不足”，认识到不足何尝不是学习的一种收获呢？从另一面说，假如读者发现书中疏谬，还请不吝赐教，本人将不胜感激。坦而言之，随着写作的深入，自得之心日敛，惴惴之心日甚，正应了上面古语的后半句：“教然后知困”。

本书的完成首先需要感谢3位母亲：我的母亲、我太太的母亲、我女儿的母亲。没有她们默默无闻的支持和帮助，冒号课堂只能在梦中开班。还要感谢博文视点的周筠老师对本书的大力支持和关怀；白爱萍编辑负责而又耐心，不厌其烦地和我讨论一个个文字和版式的细节；博文的陈宜、杨小勤、陈琼、徐定翔、许莹、胡文佳等编辑也以同样的热情带给我很好的出版体验。我从其他亲友和网友那里也得到了许多热情的鼓励和有益的启示，是他们让虚拟的课堂变得真实和生动。

郑晖

2009年8月24日于广州

“剩下四种动态语言，我们将之归为后台脚本语言。”冒号说着画了张图（如图6-1所示）——

图6-1. 常用编程语言的分类

引号听得仔细：“我记得您开始是把这些语言划分为C族静态语言、非C族静态语言和动态语言三类的。”

冒号解释：“那是按语法来划分的，偏重理论；现在是按应用来划分，偏重实践。”

句号旋即联想到：“这种分法貌似三层架构——前台语言对应表现层；平台语言和后台脚本语言对应业务逻辑层；系统语言对应数据层。”

“的确有几分神似，但千万不可混淆。”冒号提醒道，“三层架构（three-layer architecture）是模块设计上的逻辑划分^[1]；而这里是按语言应用范围进行的物理划分——与用户交互的是前台语言，与机器交互的是系统语言，介于其中的为前台提供服务同时又需要底层系统服务的是后台语言。”

逗号询问：“后台语言又细分成平台语言与后台脚本语言？”

“这是基于程序（program）与脚本（script）、静态与动态而分的。”冒号进行说明，“其实Perl，PHP，Python和Ruby都有自己的虚拟机（virtual machine），从这种意义上说它们也可作为平台语言。但在实际应用中，它们没有Java平台和.NET平台那种整合凝聚力和核心作用，通常作为轻量级的解决方案。”

问号想探个究竟：“这是由于它们都是动态语言的缘故吗？”

冒号回答：“理论上动态语言同样能承担大型应用，但实践上它们多作为粘合语言或用于中小型应用。用句时髦的话来形容，暂时还是主流的配角或非主流的主角。毕竟在运行效率、类型安全、可用资源、开发工具、技术支持等方面，它们与Java、C#相比尚有一定差距。另外它们同属‘草根’语言，虽有开源社区的大力支持，在影响力上与后者未可同日而语。”

叹号揣测：“说不定在不久的将来，动态语言也会成为主流的主角。”

“世易时移，殊难逆料。但有一点可以肯定，语言的发展趋势一定是动静结合、刚柔并济。”冒号断言，“一方面以Java和C#为代表的静态语言中嫁接了动态语言的枝条；另一方面以Java和.NET为代表的平台与动态语言的交壤地带也在逐步扩大。比如JRuby允许Ruby与Java之间互相调用，类似的还有Jython、IronRuby、IronPython等等。此外值得一提的是，动态语言最活跃的舞台当数LAMP，L-A-M-P。”

引号接茬：“L是Linux，A是Apache，M是MySQL，P是PHP。这四大组件形成了一个完整的开源网络开发平台。”

冒号补充道：“P也可指Perl、Python，甚至Ruby。”

逗号调侃：“可惜Ruby的‘R’比‘P’多了一根尾巴。”

“有人为了自圆其说，干脆让P表示‘Programming language’，这下所有语言都囊括其中了。老外就喜欢玩这种首字母缩略（acronym）的文字游戏，尤其LAMP正好还有‘灯’的含义，寓意开源世界的一盏明灯，他们一定更得意了。”冒号语带调笑，“前面我们曾提及，网络应用是生长动态语言最肥沃的土壤，而LAMP就是这块土壤上搭建的平台。作为网络平台，LAMP以其开放灵活、开发迅速、部署方便、高可配置、安全可靠、成本低廉等特色而与Java平台和.NET平台鼎足三分，尤其受中小企业的欢迎。LAMP中Linux是操作系统，Apache是Web服务器，MySQL是数据库系统，而我们当下最关心的是‘P族语言’：PHP、Perl、Python还有Ruby。”

问号建议：“作为动态语言，它们的共性上节课已经谈了不少，能说说它们的个性吗？”

“它们的个性极为鲜明：Perl凝练晦涩，Python优雅明晰，Ruby精巧灵动，PHP简明单纯。先看老大哥Perl，它博采众家之长，综合了C语言的结构、sed的正则表达式、AWK的关联数组（associative array）、Lisp的表（list）和Unix Shell的命令，此外还有借鉴了一种语言，你们知道是哪种吗？”冒号忽然卖了个关子。

叹号猜想：“应该是某种OOP语言吧。”

“Perl中确有不少C++的影子，但它的对象模型在5.0以后才引入，典型的半路出家，远不如前面的特征那么自然。与其说是一种自然而然的发展，不如说是在OOP潮流裹挟下的一种身不由己的迎合。真正深入骨髓的借鉴是自然语言。”冒号给出了答案，“我们提过，Perl的发明者Larry Wall是一名语言学家，他认为程序语言应该与自然语言一样，简洁自然、易读易写、表达多样、不拘一格。Perl还有不少的格言或哲学，使得编程语言一改严谨刻板的面孔，散发出浓郁的人文气息。”

逗号幽了一默：“我见过Perl的代码，人文气息没闻出来，但我怀疑有乙醚气息——看一会就觉得晕晕乎乎的。”

众人大笑。

“有人仅用一行Perl代码就实现了RSA算法，你看了那还不得当场晕倒啊？”冒号打趣道，“Perl的各种魔符好似一把把锋利的剪刀，做起文本裁剪之类的工作来游刃有余。这是它最大的长处，当初Perl就是Wall用来做Unix系统管理的，以后在CGI上的广泛应用也得益于此。这也赋予Perl极强的粘合力，因而有‘internet上的胶带（duct tape）^[2]’的说法。它又号称瑞士军刀，精练而复杂，实用而强大。但Perl过于灵活自由，缺乏规范，影响了程序的可读性、一致性、整洁性和可维护性。不熟悉该语言的固然如读天书，熟悉语言而不熟悉问题的也颇费思量。相比之下Python被认为是Perl有力的挑战者，不仅在于它天然的OO设计和丰富的类库，更重要的是它对程序员友好度大大超过Perl。Python也有一系列的被称为禅（Zen）的哲学，不少与Perl是针锋相对的。比如：Perl认为做一件事可以有多种方法，而Python认为一件事应该最好只有一种方法；Perl追求语言的表现力，Python追求简单优雅；Perl喜欢隐性暗示，Python强调显性明示；Perl强调紧凑，Python强调松散； Perl的语法和语义丰富，Python的语法和语义简单而类库丰富。或许Python最让人不习惯的是它对空白符敏感性。”

引号感到惊奇：“对空白符敏感？这个倒真怪异。”

冒号见惯不怪：“虽然有点违反习惯，但非常符合Python一贯的规范简洁的风格——一方面从语法上保证了良好的编码风格；另一方面，每个代码块不再需要起始的大括号或begin/end之类的，减少了的代码行数。顺便插一句，另外一种优雅的语言Haskell同样对空白符敏感，或许优雅正是来自对细节和规范的重视吧。此外许多人抱怨Python中的自引用self太多，殊不知这也是它倡导显式表达的一种体现。总的看来，Python主要的问题还是在性能效率上不尽如人意。”

叹号好奇地问：“Ruby怎么样？据说它将取代Java。”

“不要轻言‘取代’二字。”冒号规诫道，“Java没有取代C++，也不会被Ruby取代，至多只是一种再分配。不过Ruby的确是门很可爱的语言，兼具Perl的表现力和Python的可读性。Ruby背后最具特色的理念是：关注程序员使用语言时的感受超过语言本身的功能。通俗地说，兵器的称手比锋利更重要；文雅地说，应给予程序员更多的人文关怀。就拿代码块（block）和迭代器（iterator）来说，虽然均非Ruby首创，但其语法最为赏心悦目。类似的例子比比皆是。Ruby的元编程能力特别强，也是它高度灵活的一种体现，但并不是所有人都喜欢这种风格。Ruby的主要弱点有两个：一个与Python类似，在性能上还有待提高；另一个是它的线程由用户空间（user space）而不是内核空间（kernel space）来管理^[3]，不能充分利用多核或多CPU。真正让Ruby变得炙手可热的是web应用框架 Ruby on Rails（RoR）的成功，它们还催生了Java平台上的Groovy语言和Groovy on Grails框架。RoR奉行的CoC（Convention over Configuration）和DRY（Don’t repeat yourself ）原则以及MVC架构看似了无新意，但与Ruby结合之后，便如一只猱身而上灵猫，立刻衬托出Java和.NET大象般的身影。”

逗号有些怀疑：“框架竟然捧红了语言，框架真有这么重要吗？”

“如果web应用中动态页面较少或业务逻辑不复杂，框架的价值并不大。以前CGI编程就是往Perl之类的代码中嵌入HTML代码，如同Java中的Servlet；PHP则单纯地在HTML代码中插入PHP代码，如同早期的JSP。没有MVC，也不管什么三层架构，更没有ORM。但是——”冒号拖了个转折音，“一旦业务逻辑变得复杂，开发人员增多，手工作坊式编程开始捉襟见肘，引入框架这个流水生产线来提高生产力便是大势所趋。”

句号不解：“我想Perl、Python和PHP一定也有不少框架，Java中的框架更是泛滥成灾，何以独独RoR脱颖而出？”

冒号作出分析：“正值web2.0和敏捷开发（agile development）的概念流行之际，RoR将AJAX与Ruby组合在一起成为绝佳的回应。以前各种web应用框架是不少，但在RoR之前轻量级套餐式解决方案并不多。Perl中的Catalyst、Python中的Pylon还有PHP中的CakePHP等应是效仿之作。因此RoR出现的时机可说是不早不晚，正当其时。此外，Perl和PHP由于过于流行，反而有不少的历史包袱，人们习惯了将表示逻辑和业务逻辑编织在一起。至于Java企业解决方案，框架太多，搭配组合更多，增加了选择的难度。即使采用最常见的轻量级SSH（Struts+Spring+Hibernate）组合，维护起来也比RoR繁杂得多。”

叹号愈发担忧：“听这意思，Java还是危险啊！”

“言之过早。”冒号不以为然，“首先RoR还有待进一步检验，目前无论是应用广度还是深度上尚无法与Java相提并论；其次Java在性能、安全等方面还是有不少优势，而这些对于大型和关键性的应用来说尤为重要。即使在中小型web应用中，RoR较之PHP还远为不及。”

问号接下话题：“PHP为何如此流行？”

“因为它简单、专一。”冒号答得很干脆，“与Python和Ruby一开始就定位通用语言不同，PHP是专为网络而生的。同早期的Perl相似，PHP起初主要起文本过滤器的作用，只不过Perl多处理文件流（file stream），而PHP多处理套接字流（socket stream）。PHP的语法简单，且为网络应用度身定造，受到网络开发人员的追捧当在情理之中。它虽很实用很流行，但并不完美。比如：变量名大小写敏感而函数名大小写不敏感；函数命名规则不一致；不支持namespace和unicode^[4]；与Perl一样，它的对象模型不是先天的，直到PHP 5才真正完善；对线程支持不足；相比Perl、Python和Ruby，它的功能稍显单薄等等。”

引号突然想起：“我记得您在第一堂课提到PHP还能用于桌面应用。”

“不仅PHP，Perl、Python还有Ruby，都能作为前台语言来开发命令行或图形界面的应用。同样地，VB、Delphi和JavaScript也能作为后台语言。现代的程序语言既有自己的专长，又向通用化和全能化发展，以争取更多的生存空间。试想一下，现代的程序员又何尝不是如此呢？”言及于此，冒号收住话题，“语言简评告一段落，还有不少既有趣又有用的语言，在此就不一一评说了。我们看到，每种编程语言都有其独特的惯例用法和哲学理念，它们与编程范式一道形成了语言的编程风格。体悟愈深者编程语感愈强，思维与语言愈交融无碍，渐从必然王国走向自由王国。”

逗号满怀憧憬：“那是不是一种人剑合一的境界？”

“或许人器合一更准确吧，程序员可不能只会一种兵器哟。”冒号故意抠他的字眼，“现在请大家每人写一句对本节课的感言。”

众人沉思片刻，齐齐挥笔而就——

叹号——没有最好的语言，只有最合适的语言。

问号——没有糟糕的语言，只有糟糕的程序员。

逗号——没有一种语言是万能的，只会一种语言是万万不能的。

引号——废除对语言的宗教信仰，建立对语言的哲学思维。

句号——编程就是在人脑和电脑之间寻找最佳平衡点的过程。

冒号读罢大悦，顺手一掌拍出五记马屁：“精彩之极！可谓字字珠玑、句句联璧啊。兹决定，给诸位的奖赏是——立时下课！”

众人欣然领赏而去。

稍事休息后，冒号切换了话题：“接下来简单聊聊Visual Basic和Delphi。”

叹号略带得色：“Visual Basic最好用了，建个窗体，从工具箱中拖些控件，再定义一下它们的属性和行为，搞定！”

冒号点点头：“VB最大的优点就是易学易用、上手快开发快，对非计算机专业人士尤其具有吸引力。”

引号咬文嚼字：“言外之意，VB对于专业人士就不那么合适了？”

“恐怕也不好这么说。”冒号打了个哈哈，“当然简单易用不是没有代价的，随便拖放一个控件，就生成了一大堆代码，程序员的发挥余地自然受限，代码效率也难以保证。不过VB多用于前台的可视化开发，对运行效率要求相对较低，因此还是很有市场的。另外，VB进化到VB.NET后，从单纯的事件驱动式的编程范式发展为对象式、泛型式和函数式等多种范式，越来越强大、越来越严格也越来越复杂，不再是人们戏称的‘玩具语言’了。”

逗号插话：“用Delphi来开发图形界面不也很快吗？”

冒号接过话来：“正因为它们擅长可视化快速应用开发（RAD），才常常作为前台语言来使用。事实上，它们不单单是语言，也是开发环境。没有IDE，人们照样能写C、C++、Java、Perl等代码，但恐怕很少人会抛开IDE去开发VB或Delphi程序。Delphi又称Object Pascal，前身是教学语言Pascal，VB的前身是入门语言BASIC（Beginner’s All-purpose Symbolic Instruction Code），故而均具有易学易用的特点。”

问号要求：“能否比较一下二者的优缺点？”

冒号回应：“引用Computerworld的评论：‘Delphi让复杂的事情变得简单，VB让简单的事情变得更简单’。Delphi优秀的VCL框架使得它作为前台语言略胜一筹；更高的运行效率使得它同样能胜任后台工作；VB仅限于Windows，而Delphi可移植到Linux下的Kylix；对指针的支持则是便利与复杂的双刃剑。反过来，VB的学习曲线更短；如果专注微软技术，VB更便于扩展开发包括MS Office在内的应用程序，VB.NET更能充分利用.NET平台上的资源；不过VB版本更新较快，在紧跟时代的同时，也给程序员带来恼人的兼容性问题。”

句号再次体会到：“正如在Java和C#中作选择一样，平台是语言选择的一个重要因素。”

“说得没错。”冒号表示认可，“由于BASIC是微软的起家语言，VB的门槛又低，同时VB.NET也是.NET的一部分，它的前景还是乐观的，有些不利的是微软明显把重心放在C#上。谈到Delphi，不得不提Borland公司。这位曾经的软件巨人开发了无数经典的产品，却因经营不善而日渐没落，不久前将子 公司CodeGear连同包括Delphi在内的产品贱卖给了他人^[1]。”

“也许，从当初Delphi的首席架构师Hejlsberg被微软挖走的那一天起，这样的结局就已注定了。”冒号不由得轻叹一声，惋惜之情溢于言表，“这再次说明技术的成功并不意味着商业的成功，同时语言的发展与背后支持的公司也是休戚相关的。Borland和微软是两面最好的镜子。”

叹号听出弦外之音：“看来Delphi前景不妙啊。”

冒号不置可否：“这也很难说，毕竟Delphi的铁杆拥护者也不少。不过随着基于internet的应用日趋广泛，桌面应用受到网络应用的猛烈冲击，VB和Delphi的市场份额必然都会有所下降。在以网络为中心的企业解决方案中，作为平台语言的Java和C#是两棵比肩而立的大树，在它们周围生长着郁郁葱葱的动态语言的小草。”

话题自然而然地转到了动态语言。

引号看了看笔记：“按计划，是不是该谈动态语言Perl、PHP、Python、Ruby 和JavaScript了？”

冒号说道：“在这些语言中，JavaScript是个异类，虽然也有服务器端的JavaScript（SSJS），但用得最多的还是在客户端。从这种意义上说，它也是一种前台语言。”

逗号微有疑惑：“您是说将它与方才的VB和Delphi并列？”

“有一点不同的是，JavaScript必须与HTML、CSS、XML和XSLT等语言配合才能完成前台工作。”冒号作了补充。

问号似乎明白了：“您指的就是流行的AJAX技术吧。”

“不完全是。”冒号轻轻摇了摇头，“动态HTML技术（Dynamic HTML，简称DHTML）照样可以胜任前台事务，事实上以前B/S应用^[2]都是靠它来完成浏览器端工作的。DHTML在静态标记语言如HTML、XHTML等的基础上，添加客户端脚本语言如JavaScript、VBScript等，并辅以样式语言如CSS。不少人以为动态HTML与动态网页是同义词，但实际上前者的动态效果来自客户端，后者的动态效果还会来自服务端。至于AJAX（Asynchronous JavaScript And XML），比DHTML无非多了个XHR （XMLHttpRequest） 的API。XHR最大的功用是能与后台服务器进行异步通讯，从而实现页面的局部刷新^[3]，而在此之前类似的效果只能通过IFrame来实现。正是这种异步技术，大大提升了用户体验，使得网页效果开始前所未有地逼近桌面效果。虽然它并非一项新技术——早在2000年的IE5便实现了，但真正流行开来还只是近几年的事。”

引号不无担忧：“目前富客户端技术层出不穷，JavaScript的前景如何呢？”

冒号给了一颗定心丸：“JavaScript在网页技术中的主流地位在很长时间内恐怕都难以撼动。相比其他的RIA（Rich Internet application）技术，如Adobe的Flex、微软的Silverlight、Sun的JavaFX等，以JavaScript为核心的AJAX技术最大的优势在于：标准、普及、成熟；不需安装插件，只要浏览器支持JavaScript即可；因其文本特征而对搜索引擎更加友好。”

叹号谈及他的感受：“JavaScript给人的感觉是：看起来很简单，写起来很随意，用起来很头痛。”

“原因是多方面的。”冒号谆谆而言，“从JavaScript语言本身来说，其弱类型和动态语言的特征给了程序员更多的自由，也带来更多的混乱；基于原型（prototype-based）的OOP特征远不如基于类(class-based）的OOP那样为人熟知；缺乏丰富的API；不同的浏览器不同的版本之间兼容性差。更主要的是，JavaScript一直被严重低估和误解，自视甚高的程序员往往不屑去编写网页，大多数JavaScript代码由不那么专业的程序员编写。此外IDE与调试工具的缺乏也给开发带来掣肘。这些都加深了人们对JavaScript的简单随意乃至丑陋难用的印象。其实JavaScript作为一门动态语言，集过程式、对象式、函数式、事件驱动式、元编程等于一身，其强大和优雅绝对是超乎想象的。它宛如一只神奇的魔袋，乍看平淡无奇，却总能变出意想不到的宝贝。各位若有机会深入地学习和运用JavaScript，定知我所言非虚。”

问号追问：“JavaScript最大的缺点是什么？”

“最大的缺点是起了个极无个性的名字。”冒号半开玩笑地说，“为了沾Java的光，Netscape愣将LiveScript改成JavaScript，带来不少混乱。”

引号也注意到：“书店、图书馆常常将JavaScript的书与Java的放在一起。”

冒号话锋一转：“谈论JavaScript的缺点并没有什么实际意义，因为一时半会还没有同类的替代品。VBScript仅限于微软的IE，在追求跨浏览器和强调标准的今天是不具备竞争力的。ActionScript具有强大的多媒体功能，但必须借助Flash插件，与JavaScript应该是互补共生的关系。另请记住：待友之道，贵在放大其优点而缩小其缺点，对待语言亦当如是。这既是一种态度，也是一种境界。”

句号发现一个有趣的现象：“初级程序员往往偏爱前台编程，中级以上的偏爱后台编程，有些人则认为只有底层编程的才是真正的高手。”

冒号解释道：“前台编程涉及面专，绚丽花哨的界面更容易让初涉编程者产生成就感；后台编程涉及面广，需要深厚的技术积累和缜密的设计思维；底层编程涉及面深，给人神秘莫测之感。然大道相通，难者亦易，易者亦难。设计一个用户友好的界面与设计操作系统的一个模块，一边是与人直接打交道，一边是与机器直接打交道，孰难孰易、孰轻孰重，焉能一概而论？”

见冒号说得铿锵有力，问号虽不忍置喙，然终难掩疑窦：“用C写操作系统的内核难道不比用VB做一个图形界面难得多吗？”

“不可否认，系统编程的门槛确实要高得多，需要程序员具备更多的硬件和操作系统知识和更强的编程能力。”冒号以退为进，“它最大的挑战在于：在相对贫乏的软件资源和相对简陋的开发环境下，能高效、安全地管理包括CPU、内存等在内的系统资源。再说前台编程，虽然入门容易，要想登堂入室却是大为不易。且不说VB、Delphi和JavaScript各具奥妙，连看似简单的HTML和CSS中也蕴含着种种奇思妙想。得道者化腐朽为神奇，离道者化神奇为腐朽，凡事皆然。当然前台最大的挑战还不在代码编写，而在界面设计。软件最终是为人服务的，如果没有良好的用户体验，无论背后的设计如何高明、算法如何精妙，用户也是不会买账的。”

叹号充分表示理解：“一个女孩无论多么蕙质兰心、冰雪聪明，如果相貌丑陋、脾气古怪，我也是不会买账的。”

逗号故意把脸一沉：“岂有此理，竟然自比为人家的用户！”

众人嘎嘎而笑。

问号仍有不解：“界面设计不是美工的职责吗？”

“美工设计的一般是静态的视觉界面，更重要的是动态的交互界面。相貌再好，脾气不好也不行啊！”冒号顺手拾起了叹号的比方，“虽然近来出现了交互设计师的职位，专门负责UI / UE（User Interface / User Experience），但毕竟不是每个公司都有的。即便有，程序员如果缺乏充分的认识，也难以达到设计要求。这可是融美学、心理学、统计学、计算机科学等等于一体的高难度的技术活儿啊！”

问号心底泛起的串串疑问的泡泡渐渐开始消散。

逗号提出：“现在应该到了Java时间吧。”

冒号顺水推舟：“下面谈论的重心从刚才的系统语言转到平台语言——Java和C#。”

问号听得一头雾水：“平台语言？Java不是平台无关的语言吗？”

“平台的意义很广，可以是硬件平台，可以是软件平台，也可以是二者的结合。”冒号解释道，“你说的‘平台’主要指硬件和操作系统平台，而我说的‘平台’指的是运行环境平台。当然这两种平台是密不可分的，Java与C#之所以能独立于前一种平台，正因为它们自带了后一种平台。具体地说，Java运行于以Java Virtual Machine（JVM） 为核心的Java平台，而C#运行于以Common Language Runtime（CLR）为核心的.NET平台。”

句号打了个比方：“这就好比在不同的山路上铺设相同的沥青，车子跑到哪儿都没区别了。”

“是这么个理儿。”冒号表示同意，“从传承的角度看，二者皆为基于C++之上的改进，剔除了其中易于出错或不易掌握的语法特征。我们先来看看它们区别于C++的共同之处。首先，二者均编译成与机器无关的托管码（managed code）或称字节码（bytecode），运行于虚拟机（virtual machine）之上。其次，禁用或限用指针并支持自动垃圾回收，由此极大地解放了程序员的生产力。起初这种做法并不是没有争议的，但随着机器性能的提高以及软件规模的扩大，对软件的健壮性、安全性和生产率的要求超过了对运行效率的要求，屏蔽指针和自动内存管理逐渐得到认同。尽管如此，指针运算和手动内存管理对于系统软件和在性能、实时性方面要求极高的软件还是必不可少的。因为这个原因，C#还是留了一手：允许标有修饰符unsafe的代码包含指针操作。”

引号较起真来：“这是否意味着C#也能作为系统语言呢？”

“或许吧。”冒号淡淡地说，“C#的胃口很大，上管天、下管地、中间还要管空气。企业级应用和桌面应用自不必说，底层应用也不放过。早在2003年，微软研究院就开始了用C#开发的名为Singularity的操作系统研究项目，另外还有SharpOS、Cosmos等开源操作系统。虽然它们目前仅用于研究，但不难看出C#的勃勃野心。说起来这也不新鲜，1998年Sun就搞了个针对嵌入式系统的JavaOS，可惜没能成功，后为Java ME所取代。”

轮到叹号糊涂了：“刚才还说Java和C#是平台语言，怎么又同C和C++一样当系统语言来用了呢？”

冒号释疑：“Java可通过JNI调用C、C++等程序；C#可通过P/Invoke访问系统API，加之保留了指针操作，用于系统编程更加方便。其实一种语言胜任多种领域并不难，难的是在每个领域都独占鳌头。可问题是，有谁不乐见自己支持的语言被广泛应用呢？无论是微软还是Sun，他们都会竭尽所能地将自己的语言扩张到每个角落。程序员作为语言的用户，虽然很多时候并没有选择语言的权力，但心中要有杆秤，可不要轻易被商家的广告迷惑啊。”

逗号不无自嘲地说：“秤倒是有一杆，就是不太准啊！”

有人“噗哧”笑出声来。

“多学习、多实践、多体悟，秤的精度自然会提高。” 冒号鼓励道，“如果自己没有足够的鉴别商品能力，建议从商家的竞争对手那里获取真实的信息。要看Java的优点，不要听Sun的一面之词，可以看看微软的C#模仿了Java的哪些特征，因为模仿是最高的赞扬；要看Java的缺点，可以看看C#摈弃了Java的哪些特征，可以听听微软对Java的批判——虽然可能过激，但一般也不会太离谱。此法同样适用于包括C#在内的其他语言。”

句号有所感慨：“这既是程序员之幸——语言之间可以互相取长补短，共同进步；也是程序员之不幸——往往不得不在众多语言中作艰难选择，或者多花精力学更多的语言。”

冒号一边点头一边接着说：“下面继续看看Java与C#的共性。借着刚才的话题，我们来看看C#与Java是如何互相学习的。”

引号举手插问：“C#到底更接近C++还是Java？”

“这是个有趣的问题。不妨这么说：C#看起来更像C++，用起来更像Java。C#借鉴了包括Java、C++、Delphi等在内的语言特征，其中Java的影响最大，但由于微软与Sun在Visual J++上的过节，宁愿强调与C++的关系而淡化与Java的关系^[1]。C#的设计者Hejlsberg以前是Delphi和Visual J++的架构师，在一次访谈中首先声明C#不是Java的克隆，但从此话本身和他本人的背景都暗示了与Java千丝万缕的联系。例如，C#采用了大量与Java相同或相似功用却不同拼写的关键字。”冒号投影出一张表格（如表6-1所示）——

“这是Java与C#关键字的不完全对照表。中立地看，C#的关键字似乎更简明，但明显避嫌的意义大过改进的意义。关键字只是一个缩影，那么C#究竟从Java那里学到了什么，相比于C++又有什么优势或特点呢？”冒号切换了幻灯片——

问号就势而问：“Java向C#又借鉴了什么呢？”

冒号答道：“在Java1.5的增强特征中，有不少C#的影子。如增强版的for循环；可变长参数（varargs）；自动装箱（autoboxing）；类型安全的枚举（typesafe enum）等等。此外，支持元数据的的注释（annotation）与C#的特性（attribute）大同小异，C#从Delphi中引入的属性（property）也出现在Java 7的提案中。”

逗号双手一摊：“这么多相同之处，不如合并算了。”

“很傻很天真的想法。等它们合并了，估计世界也大同了。”冒号笑言，“它们之间的差别也不容忽视。C#重新捡起了C++中被Java抛弃的一些特征，可谓是对C++的否定之否定——除了支持引用类型（reference type）外，还支持值类型（value type）^[2]；除了按值传递（pass-by-value）外，还可按引用传递（pass-by-reference）；支持操作符重载（operator overloading）；在一定条件下保留指针和指针运算；所有的方法默认是非虚的（non-virtual）；访问权限默认是私有的（private）；将关键字‘extends’和‘implements’统一为‘：’；支持预处理指令（preprocessor directive）；C#4.0还将引入可选参数（optional parameter）等等。公允地说，这些大都为明智之举。”

引号追问：“C#有什么独到之处吗？”

“C#并非一味地效仿其他语言，也有创新之举。曾在Visual J++中加入的委托（delegate）和相关的事件（event），如今可以堂而皇之地用在C#上，再不用担心被Sun告了。”冒号语带调侃，“C#还是第一个支持组件导向（Component-Oriented）的C族语言。除此之外，C#支持索引器（indexer）、版本控制（versioning）、XML注释、特色指令如#region、特色关键字如checked、yield等等，还引入了查询句法（query syntax）、匿名类型（anonymous type）、扩展方法（extension method）等新特征。还有一点不得不提，C#对函数式编程的支持力度逐渐加大：1.0的delegate可作为头等函数（first-class function），2.0的匿名delegate可作为闭包，3.0又引入了Lambda表达式，几乎可号称函数式语言了。及至C#4.0，进一步向动态语言靠拢，将引入关键字dynamic以支持动态类型和动态操作。”

叹号眉头微蹙：“听起来C# 比Java复杂多了，好像大杂烩。”

“当初Java对C++的改革的一个重要原则是：让语言变得简单而有亲和力，降低程序员门槛，提高软件生产效率。但如今Java已经不那么简单了，C#则更复杂，在某些方面较之C++也不遑多让。” 冒号语调转强，“以前人们试图在语言的威力（power）和生产率（productivity）中寻求最佳平衡点，现在似乎更想鱼与熊掌兼得。”

问号再次提问：“Java与C# 最大的区别是什么？”

“虽然同为平台语言，二者的设计理念还是有所不同的。Java的目的是让一种语言在多种平台上运行^[3]，而C#（.NET）的目的是让多种语言在一种平台上运行^[4]。”冒号钟爱这种具有对称美的对比，“虽然理论上以C#为核心的.NET平台可以用在任何操作系统上，但千万不要指望微软会心甘情愿地提供Windows之外的实现^[5]，原因不言自明。而Sun的Solaris无法与Windows抗衡，最大的王牌就是Java语言，当然会致力于跨平台和面向Internet的应用，对桌面应用的投入相对较少。另外，Sun不像微软那样控制着包括C#、VB、C++/CLI、J#、JScript.NET等在内的多种语言，对跨语言的热情度相应也低得多。尽管Java能与Groovy、JRuby、JPython等以JVM为基础相互调用，不过与其说这是Java的初衷，不如说是自然发展的结果。因此两个平台语言，一个重在语言，让语言向平台扩散；一个重在平台，让平台来凝聚语言。在此并不想对两公司的商业策略评头论足，而是认为了解这种背景会对理解语言特征及其发展趋势有所裨益。编程语言绝非象牙塔中之物，实乃技术和商业合力推动的结果。”

逗号拖着怪腔：“原来如彼！”

众人大笑。

句号深思后问道：“可不可以这么理解：如果开发仅限于Windows平台的应用，C#是更好的选择，它一方面与Windows系统存在天然的纽带，另一方面可有效地利用.NET的包括ASP.NET、VB.NET、ADO.NET、Windows Forms、WPF、WCF、WF等在内的各种软件资源；如果开发不限于Windows的企业应用，则选择Java更合适？”

冒号微微颔首：“有一定道理，平台的确是语言选择的一个考虑因素。不过说起可利用的软件资源，Java毫不逊色。除了形形色色的开源框架和工具外，与动态语言如Groovy、Scala、Ruby、Python等也能严丝合缝。作为平台语言，Java和C#均有极为丰富的资源和极强的整合能力，背后又有大公司不遗余力的支持和推广，理所当然地成为大型企业应用的主流选择。”冒号匆匆作结，“关于Java与C#的比较暂时谈到这里^[6]，由于时间关系，我们不可能面面俱到，难免挂一漏万。许多概念术语只是点到为止，具体细节留待以后展开，暂且按下不表。总而言之，每种语言都为解决问题提供了一定的途经，C++、Java和C#的不同之处在于：C++提供了一马平川的大路，也提供了陷阱密布的小道；Java则在大路上铺设水泥，同时封锁了捷径小道；C#同样填平了大路上的坑坑洼洼，但把一些小道上‘此路不通’的牌子悄悄换成了‘此路危险’。”

教室里，学员们正热火朝天地讨论着流行的编程语言。冒号推门而入，仿佛沸水锅里被浇了一瓢冷水，立刻平静下来。

冒号笑吟吟地看着大家：“怎么不讨论了？”

众人齐道：“该您了！”

“首先需要声明的是，本课评论编程语言，乃是应众位之邀，实非本意。”冒号变得严肃起来，“因为这种评论，不可避免地会带上个人色彩，容易产生误导。有道是，通禅悟道者拈花不语，坐井观天者蛙鸣鼓噪。”

众人迅速自动对号：合着我们就是一群蛤蟆。

“这样一来，我的处境就很尴尬了。”冒号自嘲着。

有人在幸灾乐祸地偷笑。

“也罢，即使作蛙鸣，至少也要先跳出井来。”冒号毅然决然地加入了蛤蟆的行列，“要谈，就旗帜鲜明地谈，该赞叹的就赞叹，该鄙视的就鄙视。说些你好我好大家好之类不痛不痒的话，倒不如不说。”

叹号一拍大腿：“好，这样才够痛快！”

问号忍不住问：“您究竟打算比较哪些主流语言呢？”

冒号回答：“就谈谈第一堂课提到的最流行的十二种语言吧。按语法特征可将它们分为三类：C族静态语言五种——C、C++、Java、C#和D；非C族静态语言两种——VB和Delphi；动态语言五种——Perl、PHP、Python、Ruby 和JavaScript 。”

叹号表示怀疑：“这么多种语言怎么比较得过来？”

冒号解释：“我们主要比较第一类的C族语言，这些也是今后学习的重点，其他的只是泛泛而谈。”

引号猜测：“因为他们更重要？”

“可以这么说。”冒号直截了当，“毋庸讳言，在当今的主流语言中，C族语言应用范围之广、使用人数之多、影响力之巨都是其他类语言所无法比拟的。它们之间的关系从名字上就能看出：C语言的前身是B语言；其后是C++；Java曾被称为C++++–，意思是在C++上增点东西再减点东西；C#中#就是四个叠起的加号^[1]；最后D语言干脆在字母上进行升级。”

句号推断：“B语言、C语言、D语言，下一个该D++、D#或E语言了。”

谁知冒号却说：“E语言已经有了，与Java的语法很像。甚至F语言也有了，但不是C族语言，而是Fortran族的。这不，微软还在.NET平台上推出了F#语言，不过这里的F指的是‘Functional’，即函数式。”

逗号向往着：“不如直接搞个终极的Z语言，成为全世界程序员的唯一指定语言，多省事！”

“这难度不亚于全人类共用一种语言。”冒号笑道，“愿望是美好的，我们还得面对现实。不扯远了，你们先谈谈一下这些C族语言各自的特点吧。”

众人心想：老冒怎么跟国足一个毛病，老喜欢回传，就是不直接射门，真是急煞人也！

问号拣了个软柿子：“C语言是C族老大，又是唯一的纯过程式语言，当然与众不同啦。”

引号一板一眼：“C++在过程式的基础上又引入对象式和泛型式，同时保持了C的高效性和底层开发能力。”

逗号接道：“Java既继承了C++的优点，又克服了C++的复杂性，虽然底层开发能力有所减弱，但具备平台无关性。”

句号不紧不慢：“C#兼具C++与Java各自的优点，但效率上不如C++，跨平台方面不如Java。”

叹号后悔嘴慢：“剩下一个最陌生的D语言，在第一堂课之前还真没听说过，怎么挤上主流语言位置的？我想。。。呃，它总该比C++要高级吧。”

冒号评价：“各位谈得虽然简单了些，也算八九不离十吧。下面我稍微展开些来讲。”

此时众人有一个共同的愿望，希望老冒这次能痛快地单刀赴会、直捣黄龙。

冒号似乎看出大家的心思，开始口若悬河：“关于C语言，前面多次提到。这是一把历久弥新的宝剑，一旦出鞘，依旧寒光逼人，锋利无俦。有了它，便如战将有了佩剑，平添一分独闯敌营的胆气。尽管以现代的眼光来看，它存在不少缺点，但即使抛开C语言辉煌的历史不谈，单就其以如此高龄在诸多后辈冲击之下仍屹立不倒而论，让人无法对其多加苛求。”

逗号提出异议：“但语言不是让人崇拜的，而是让人运用的。一门语言无论过去如何荣光，如果不适应现代发展趋势，还是可能被淘汰。”

“说得非常好！”冒号竟然鼓起掌来，“迄今为止本课堂对于具体知识的讲授不算太多，但一直提倡独立思考，不要盲从权威。如果你们能做到这一点，本班的目标也就实现了一半。回头再说说C语言，它源自Unix操作系统的开发，以其良好的抽象性和可移植性取代了汇编语言作为系统开发语言。因其简洁实用、灵活高效，很快从系统领域发展到其他领域而成为通用语言。随着新兴语言的崛起以及硬件性能的大幅提高，C语言的缺点也日益显著：过于宽松的类型检查、容易出错的内存管理、相对贫乏的语言特征等等。虽然自身还在发展，它的市场份额日益减少乃是不争的事实。但在相当长的时间内，它在其所擅长的领域里仍会占举足轻重的一席之地。如果C能借鉴C++的 命名空间、重载、异常处理和STL等非OOP的特征，它的生命力绝不会比任何OOP语言弱。附带说一句，C虽然没有直接支持OOP的语法，但经过适当的设计还是能实现OOP的^[2]。”

引号咨询道：“关于C语言的学习，您有何建议？”

“精读K&R的《The C Programming Language》，此书不过200多页，堪称C语言的剑诀。其中的R即Dennis Ritchie，是C的创造者，同时也是Unix的缔造者之一，是真正的大师。如今的大师，同博士、教授、院士等头衔一样，严重地通货膨胀了。”冒号不无感慨。

问号尖锐地问：“C++既保持了C的底层开发能力，又引入了OOP，C的处境想必更加艰难吧？”

冒号坦承：“这是不假。C++成功的一个重要因素是对C语言的兼容，由此吸引了大批的C程序员。但这不是没有代价的，C++在兼容C的同时也保留了C的许多缺陷。Java成功的地方有很多，一个不容忽视的因素是它彻底摆脱了与C兼容的桎梏。由于C++对C的改革不彻底，又过于庞杂，并且效率上不如C，这使得C仍有其生存空间。略有讽刺意味的是，对C++批判最激烈的往往来自C的社区，比如Linux之父Linus Torvalds就曾激烈地批判过C++。”

“Linus？那可是我的偶像呢！”叹号惊讶道。

冒号劝诫：“如果你因为是他的粉丝而后悔学C++，那就是为他人的偏执买单，不管那人名气有多大。”

句号指出：“C++最为人诟病的地方有：语法过于复杂，学习曲线陡、开发效率低；支持的范式过多；OOP不彻底；反射（reflection）功能不足；支持指针操作导致安全隐患；没有自动垃圾回收，容易内存泄漏；没有线程支持；没有丰富的标准库支持图形界面、网络编程等。”

“罪状不少哇！这些说法都有一定道理，但有些也有失公允。且听我一一道来。”冒号当起了辩护律师，“C++比较复杂这点没错，Stroustrup说过一句耐人寻味的话： 一种语言不够复杂是因为它还不够成熟。成人肯定比儿童复杂，因为他要承担更大的责任。大家不妨看看Java从1.0到即将问世的7.0、C#从1.0到即将的4.0的发展过程，是否应证了这一点？当然C++的复杂度的确高于其他语言，但如果不执着于奇技淫巧，它绝非高不可攀。C++的开发效率相比Java与C#，差距主要在两个方面：一是标准库不够完善，二是需要手工回收垃圾。关于前者，的确是C++的一大软肋，标准库竟然连企业应用中最常用的图形界面、网络编程、数据库处理、多线程等都不能涵盖，严重障碍了生产力。其实C++也有苦衷，不像Java和C#那样有大公司的鼎力支持，只靠效率极为低下的标准委员会来维护。98年的一个标准直到03年还在修订，下一个标准至少要到09年。连Stroustrup都在哭穷，声称没有足够的人力和时间来开发标准库，可为何广受赞誉的Boost库至今仍徘徊在标准门外？考虑到Boost的创办人大多出自标准委员会，其他无此背景的类库恐怕更难登C++之大堂了。相比之下D语言更惨，虽然天生丽质，苦无豪门青睐，只好一直待字闺中。”

叹号感慨：“金钱才是技术的最大推动力啊！”

“话糙理不糙。”冒号也很无奈，“再来谈谈有关自动垃圾回收的问题。在C++中，程序员也不是非得手工清理垃圾不可的。更好的办法是遵循RAII的惯用法（idiom）^[3]，通过智能指针（smart pointer）来解决内存释放问题。”

逗号听不明白：“什么是RAII？”

“RAII是Resource Acquisition Is Initialization的缩写，直译为‘资源获取即初始化’。”冒号解释，“其实更准确的叫法应该是RRIF（Resource Release Is Finalization），即‘资源释放即终结化’^[4]。其思想是：将资源的取放与某一对象的生命周期绑定，初始化对象时获取资源，终结化对象时释放资源。用户代码不再直接管理资源，只需控制相应的对象即可。这样代码得以简化，资源的有效性也得以保障，并且还是异常安全的（exception-safe）^[5]。”

问号猜想：“在Java中没有这种用法，是因为它已经有了垃圾回收器吗？”

冒号摇摇头：“问题的关键不在这里。资源不只限于内存，还包括文件、线程锁、数据库连接等等，这些都不是垃圾回收器所能解决的。看看Java的数据库应用代码吧，对于那些频繁出现的被try/catch/finally包裹的resultset.close()、statement.close()、connection.close()，你是习以为常呢，还是不胜其烦？C#的设计者显然意识到这一点，专门提供了using语句来简化释放资源（IDisposable）的代码。”

逗号眼睛一亮：“如果采用RAII的技巧，这些都可以省去了吗？”

冒号再次摇头：“可惜Java不像C++或D那样，能在栈（stack）上创建对象。栈对象有一个特点，一旦超出其作用范围，便自动释放内存。在此之前会调用析构函数（destructor），后者继而调用释放资源的代码。”

几声叹息清晰可闻。

冒号续道：“另一方面，尽管自动垃圾回收机制逐渐为大众所接受——据说C++0x也将部分地支持它——但这种机制也存在缺陷。比如一个Java程序如果在某一时段极耗内存，由于自动垃圾回收的不定时性，不能保证及时清理内存，可能会抛出OutOfMemoryError的错误。对于内存有限的系统或实时系统来说，这绝对是一个致命的软肋。C++不支持自动垃圾回收，正是基于这些方面的考虑。Stroustrup非常顾虑自动垃圾回收带来的时间和空间上的过多开销，并且担心它会影响C++完成其所肩负的底层任务。另外，千万不要以为有了自动垃圾回收机制就一劳永逸、万事大吉了。Java程序一样会有内存泄漏，其几率甚至可能比C++的更大，因为C++程序员对此更有戒心，而Java程序员大多被惯坏了，环保意识要淡薄得多。”

问号直奔要害：“您如何看待C与C++中的指针？”

冒号欣然接招：“指针是C与C++最大的特色，其他语言要么不支持，要么支持得有限。C与C++可以说是成也指针，败也指针。用得好可以是削铁如泥的神兵利器，用得不好则可能是自我毁灭的罪恶渊薮。但由于二者定位于系统语言，而指针对于底层操作是必不可少的。同样道理，二者的数据类型的转换比其他静态类型语言更自由，也是源出于此。”

句号总结：“能力越大，责任越大，风险越大。”

“正是此意！”冒号重重地敲了一下桌子，“此话既适用于编程语言，也适用于程序员。至于C++缺少对反射功能的支持，也是因为追求效率，不愿在元数据上花时间和空间。说到C++支持的范式过多，程序员过于自由，代码不标准难维护，这就如同埋怨餐馆提供的菜式过多以致难以摆出一桌酒席一样可笑。最后，指责C++不是100％OOP的说法更是荒谬至极。OOP又不是金子，含量越高越好。试图把一切都装进OOP的箱子里的想法无异于削足适履。典型的如Java中的Math类，逻辑上压根儿就不存在什么Math对象，清一色的static方法和常量就是最好的讽刺。在C++中只要在math的namespace中定义一些自由函数就可以了，自然而简洁。作为一个佐证，Java于J2SE5.0引进了静态导入（static import）机制^[6]，C#也在2.0增加了静态类^[7]（static class），不仅在形式上简化了代码，也在思维上容忍了非OOP的过程式。”

引号发觉：“您好像把对C++所有的责难都化解了。”

“可恨之人必有可怜之处嘛。”冒号俗语反用，“其实C++仍有不少亟待改进之处，D语言就是很好的启示。D语言的提供了可控制的垃圾回收器；支持线程同步；支持动态数组（dynamic array）；支持嵌套函数（nested function）；支持契约式设计（design by contract）；废除了C与C++ 中令人头痛的头文件（header file）等等。这些都是C++程序员梦寐以求的特征。”

逗号很奇怪：“为什么D语言名气这么小？”

句号吟道：“千里马常有，而伯乐不常有，大腕伯乐更稀有。”

众乐。

冒号拔高了调门：“既然系统语言主要为底层系统的开发服务，这就决定了它们的理念是：优化机器的时间而不是人的时间，优化机器的记忆而不是人的记忆；假设编译器是愚蠢的而程序员是聪明的，因此赋予程序员更多的权利、义务与责任。无视这种背景和理念而去与其他语言相较，完全是不着筋节，不值一哂。当然这并不排斥系统语言用于应用开发，尤其是C++和D语言。需要强调的是，常见的‘C/C++’的说法很不科学。C与C++虽有千丝万缕的联系，但一个简单，一个复杂；一个纯过程式，一个集过程式、对象式、泛型式和元编程于一体。貌合神离，不宜混为一谈。”

叹号一个问题憋了半天，不吐不快：“我有一个问题：如今电脑性能这么高，C与C++如此强调程序的性能和效率还有必要吗？”

“绝对有必要！”冒号斩钉截铁，“其一、纵向看，用户的耐心与电脑的性能成反比，早年一个386人们就满足了，如今却忍受不了586；以前16M内存就不错了，现在1G都嫌小。其二、横向比，占用资源过多、运行相对缓慢的软件竞争力也低。其三、在一些应用领域如人工智能、大型计算等方面，普通电脑的性能还远远不能满足要求，超级计算机的存在就是明证。其四、仍有些程序跑在资源有限的主机上，比如嵌入式系统。”

引号再次要求：“能推荐一些C++方面的书吗？”

冒号直言相告：“学好C一本书足矣，学好C++即使推荐十本仍有遗珠之憾。可以说C++是苦了编程者，甜了著书人。开个小书单：初级——《C++ Primer》和《Thinking in C++》；中级——《The C++ Programming Language》和《Effective C++》系列；高级——《The C++ In-Depth》系列。这里还要特别推荐一下《The Design and Evolution of C++》，从中你可以看到 C++的设计和演变的来龙去脉，极具启发性。其他的C++精品书籍还有不少，恕不一一列举了。C++是匹无辔无鞍的野马，看似桀骜不驯，若能顺性而御，必能足踏飞燕，行千里而不劳。”

“最后该谈谈你们最为关心的语言问题了。”冒号环视一番，众人眼球的瓦数显见增大，“如果说编程范式是一种文化，那么编程语言更像是一种宗教——尽管它本不该是。每种流行的语言都有大批忠实的信徒，随时可能与其他的信徒发生宗教战争。”

逗号深有同感：“周围和网上关于语言的争论从来不绝于耳，志不同道不合者动辄恶语相向。”

提起这些，冒号不免有些忿忿然：“这些信徒或准信徒们认为他们所崇拜的语言鹤立鸡群，远比其他语言高明得多，恨不得成为全天下程序员的通用语言。对其他语言的使用者，或居高临下地同情，或不屑一顾地讥讽。无知与偏见总是相辅相成的，他们中的绝大多数顶多熟悉一两种语言，其他的或浅尝辄止、或道听途说，却敢妄评优劣，岂不可笑之极？”

引号点头称是：“是啊，没有深入的了解，怎会有深入的比较。”

冒号进而尖锐地指出：“从心理学上分析，一个人在某种观点形成后，会通过自我的暗示和倾向性的证据不断地强化这种观点，并对其他观点本能地选择性失明。这背后折射的其实是一种懒人心态——认定自己掌握的语言是最好的，便不必费事再学其他语言了；这更是一种弱者心态——无论是耿耿忠心的铁杆卫士，还是振振有词的辩护律师，一旦丧失自我批判的勇气和精神，声嘶力竭的挞伐只能反证他们的偏狭浅薄与自信缺失。”

冒号刻意借辛辣十足的嘲讽再次传递精神的信号。

叹号道出苦衷：“只是真正掌握好一门语言已殊为不易，同时掌握几种就更难。学完一种语言再看另一种，怎么都觉得别扭。”

“这就是第一堂课所说的‘学会’与‘会学’的差距。”冒号挑明要害，“每种语言都有天然设计上的不同，当你用得很别扭时，恰恰说明没有真正掌握。正如刀法以劈为主，枪法以扎为主，你若反其道而行之，刀扎枪劈，能不别扭吗？如果愣拿双节棍当单节棍使，恐怕没砸到别人倒先砸晕自己了。可见不是兵器问题，而是招法问题。”

下面隐约传来周杰伦《双截棍》的调子。

问号注意到：“似乎不只是初学者，大师们也会对一些语言提出过尖锐的批评。”

冒号引用道：“C++的发明者Bjarne Stroustrup说过这样一句话，语言只有两种：一种怨声载道，一种无人问津（There are only two kinds of languages: the ones people complain about and the ones nobody uses）。”

众笑。

句号有所体会：“一种语言如果用者甚众，自有其可取之处。没有一种语言是完美的，爱之深者尚苛之切，何况其余者乎？”

冒号忽然问：“你们知道对一种语言最大的批判是什么吗？”

众人纷纷摇头。

“那就是发明一种与此语言有类似功用的新语言。”冒号语速放缓，“Stroustrup认为Simula太慢、BCPL又太底层，于是发明了C++；Gosling觉得C++用得不爽，于是发明了Java；微软恼恨Java，于是请Hejlsberg发明了C#；Matsumoto用了两年多的C++仍不顺手，于是发明了Ruby。如此这般，不一而足。”

叹号无奈地说：“那是牛人的批评方法，常人怎能办到？”

“没有能力发明语言，就老老实实地用别人的吧。”冒号酷酷地说，“对待一门语言的态度应该是：与其抱怨争执，不如扬长避短。”

引号顺势道：“按这种说法，编程语言的发展史就是一种批判史咯？”

冒号祭起辩证法：“从另一个角度看，发明一种语言也是对先前语言的一种最高的赞美。C++之于C，Java之于C++，C#之于Java，都是后者对前者的一种承认，哪怕是极不情愿的承认。批判与赞美，继承与发展，谓之扬弃。”

众人心想，语言课又改哲学课了。

冒号续道：“对于编程语言还有一种论调：语言只是一种工具，哪种都差不多。”

逗号接茬：“是啊，经常在论坛上看到一些高手这么说。”

“一群伪高手，是工具就差不多？能拿锤子当刀使吗？”冒号嗤之以鼻，“过分拔高一种语言与抹煞语言之间的差别是两种极端，皆为秕言谬说。图灵奖获得者Alan Perlis曾说过：如果一种语言不能影响你对编程的看法，那么就不值得去了解。试想，一种没有独特魅力的语言如何吸引程序员趋之若骛？了解这些独特之处对于编程往往至关重要，如果沿袭以前语言的做法，会显得不伦不类甚至可能铸成大错。”

问号要求：“能说得具体点吗？”

冒号举例：“有人说，学C++要先学C；还有人说，学会了C，C++就不在话下了。”

叹号一惊：“难道不是吗？”

冒号解释：“其实C++的真正来源是Simula而不是C，向下兼容C只是因为C效率高、普及广。换句话说，C++与C形同而神异。学会了C当然对C++有一定帮助，但若不能理解C++的OOP思想，那么C的背景反而是一种障碍。”

逗号想当然：“C++与Java都是OOP语言，差别该不大了吧？”

冒号再次否定：“不同编程范式的语言差别固是不可以道里计，即使同一范式的语言也是千差万别。一个纯粹的C++程序员用Java编程，会非常不习惯没有指针运算、没有内存控制、没有运算符重载、没有自由函数等等。一个纯粹的Java程序员用C++编程，会极度不适应相对贫乏的标准库；会困惑于指针、引用、数组、字符串还有头文件等的用法；会毫不吝惜地在堆（heap)上创建新对象，并且从来不去释放它们。这些概念或用法都是贯穿整个程序始终的，差别能不大吗？”

叹号听罢叹曰：“做一个好的程序员还真不容易。”

“如果容易，我们开这个班做什么？” 冒号笑道，“提一个问题，程序员最不能离开的应用软件是什么？”

逗号顺嘴道：“当然是IDE了。”

引号纠正：“应该是编辑器，有些程序员用vi甚至记事本来写程序。”

冒号插一句：“有人还在命令行下写程序。”

叹号眼瞪得溜圆：“怎么可能？”

冒号眉毛一挑：“当然可能，一些简单的程序完全可以在命令行下完成，然后重定向（redirect）到一个文件中或者直接编译执行。这种情况虽有些极端，对于那些离开IDE就没法编程的人来说更是不可思议，但至少说明编程离开编辑器还是有可能的^[1]。”

句号突然明白了：“是编译器！”

“不错，是编译器或解释器。”冒号作了一点修正。

问号有点茫然：“为什么谈这个呢？”

“因为编译器或解释器是语言实现的标志。”冒号提高了声调，“我想借此说明一个简单的道理：对一个程序员而言，编程语言乃立身之本。许多人偏偏本末倒置，常常为在IDE、框架、设计工具等中挖掘到某些新功能而欣喜不已，或者津津乐道于各种语言的优劣高下，却对正在使用的语言中大量的宝藏视而不见，与执金碗而行乞者何异？这些人若有幸拜关公为师，他们最艳羡的一定他的赤兔马和青龙偃月刀，或许还会抹红脸蓄长须什么的，就是不太愿学他的盖世武功。”

引号质疑：“我明白您是想修研强调内功的重要性，但似乎有些唯语言论，设计思想不是更重要吗？”

冒号补充道：“我所谈的语言，自然不是孤立的语法和用法，也包括背后的编程范式和设计思想。当然更高层的架构设计可能会脱离具体的语言，但那不在考虑之列，因为我们谈论的主体是程序员，而不是架构师。”

提到架构师，众人神往之情油然而生。

冒号看透了大家的心思：“架构师并没有多么神秘，他们也是从程序员过来的。也不要以为架构师就不关心语言了，相反需要对语言有更广博、更深刻的认识。理想的架构师应当如文学大师，既有恢弘大气的构思，又有细腻深刻的笔法；应当如统军大帅，既有运筹帷幄的韬略，又有冲锋陷阵的武功。那些在语言与低级之间、设计与高级之间毫不犹豫地划等号的人，多半高不成低不就，既不懂语言，也不懂设计。”

逗号仍有疑惑：“语言真有那么重要吗？IDE的一些集成工具可以辅助生成许多代码，或许到了某一天，拖拖鼠标、画些UML图之类的，程序就大功告成了。”

冒号哈哈一笑：“这不就是元编程吗？元编程也是用语言实现的。且不说你描绘的美景是否可能，即便实现了，程序员的任务也是用更高级的语言做更高级的编程——还是离不开语言。别忘了，技术含金量是与工资含金量成正比的，你永远需要比别人多一门扎实的功夫。程序员这门职业，你选择，你担当。好了，闲话打住，欲知在下如何评价各种编程语言，且听下回分解。”

众人听兴正浓之际，课堂却在说书式的结语中戛然而止了。

叹号急不可耐地问：“现在可以谈动态语言了吧？”

冒号感言：“曾几何时，动态语言还只是陪太子读书的角色，那时候它们的名字是‘脚本语言’。近来却迅速崛起，俨然有与静态语言分庭抗礼之势。”

问号忍不住问道：“动态语言与脚本语言是一回事吗？”

“相比动态语言定义上的模糊，脚本语言的概念还是比较明确的。”冒号回避直接给出答案，“脚本（script）的提法，是为了区别于一般的程序（program）。Perl的发明者Larry Wall不愧为语言学家，对此有一个精彩的说法：‘A script is what you give the actors, a program is what you give the audience’。直译为：脚本是给演员看的，节目是给观众看的。此言妙在一语双关——program兼有‘节目’和‘程序’的意思。”

句号领会其意：“这里的演员指的是程序员，观众指的是用户。换言之，程序是为终端用户服务的，而脚本是为程序员服务的。”

“正解！”冒号肯定道，“脚本最常见的形式是壳脚本（shell script），在非Unix类的操作系统中也称为批处理文件（batch file）。”

“批处理文件倒是很熟悉，壳脚本听起来就怪怪的。”逗号嘀咕着。

“那是因为你在Windows的世界里长大，听不惯Unix的方言。”冒号一语道破缘由，“操作系统的内核称为核（kernel），出于安全考虑不便直接与用户交互，因此裹上一层壳（shell），即人们常说的命令行解释器（command line interpreter）。壳脚本是在壳上运行的脚本，扩展了命令行下可执行的命令。它最初主要是内建（built-in）命令的组合，用于系统程序的调度，是系统管理员的必备武器。其后，壳脚本也发展到用于应用程序的调度、连接、调试等，成为粘合（glue）语言。”

逗号不禁有些疑问：“难道一般的程序语言如C之类的不能作此用吗？”

引号回应道：“这些语言通常需要‘编写－编译－链接－运行’的循环过程，十分繁琐。脚本语言编写后即可运行，快捷方便得多。”

冒号点点头：“不错，既然脚本主要用于整合其他程序，本身并不占用太多的资源，同时逻辑也不太复杂，因此脚本语言注重简洁、实用，语法要求不那么严格，性能上的要求也不高。除壳脚本外，还有一些专用于文本处理（text processing）的语言或工具如AWK、sed和grep等，多用于读写配置文件和日志文件、过滤处理各种程序的输入和输出，对于整合各种程序也非常实用。随着对脚本语言需求的增长，其局限性日益突出，以Perl为代表的高级脚本语言便应运而生了。Perl在壳脚本、AWK、sed的基础上，融合了命令式的C与函数式的Lisp的特征，渐渐成为最流行的脚本语言之一。”

问号注意到：“JavaScript是浏览器端的脚本，来路似乎有些不同。”

冒号解释道：“除了命令行程序外，脚本语言在其他的应用程序中也身影频现，如图形界面应用、多媒体应用、网络应用等。尤其是网络应用，成为滋生和繁荣脚本语言最肥沃的土壤。例如：Perl非常广泛地用于网络服务器端的CGI编程；PHP更是专为动态网页而设计的语言；Ruby虽与Java同岁，但真正开始风行得益于网络应用框架Ruby on Rails的成功；至于JavaScript，长期被边缘化为网页设计人员的语言，是web2.0的新宠AJAX真正将其带入程序员的视线。”

逗号有些好奇：“什么时候脚本语言变成了动态语言呢？”

“尽管动态语言并无确切的定义，但不是所有的脚本语言都能称作动态语言的——比如Bash之类的壳脚本语言（shell script language）；另一方面，也不是所有的动态语言天生就是为脚本服务的——比如Lisp^[1]。不妨这么理解，脚本语言以语言的实际用途为标志，动态语言以语言的语法特征为标志。”冒号回答，“单从用途上看，一个脚本语言如果不再局限于命令行工具和粘合工具，从专用语言发展为通用语言，并能胜任复杂的应用开发，或许更有资格归为动态语言。”

句号发现：“动态语言似乎对字符处理都特别擅长。”

冒号道：“脚本语言与一般程序一个不同之处是，它一般是面向字符而非数值的，因为字符是最通用的接口，正好发挥其粘合作用，而数值运算对性能要求较高，多由核心程序来完成。动态语言继承了这个特点，并且除了正则表达式（regular expression）外，为字符串、数组、列表、集合、映射等常用结构提供了丰富简洁的运算，远比静态语言依赖于库（library）的方便自然得多。”

叹号问：“我们清楚了脚本语言中‘脚本’的来历，那动态语言中‘动态’又体现在何处呢？”

“问得好！”冒号闻言，正中下怀，“再从用法上看，动态语言能在运行中增加或改变数据结构、函数定义、对象行为或指令流程等。如果说动态类型语言的动态体现在类型上，动态语言的动态则体现在结构和功能上。相比而言，静态语言虽然也可能实现同样的效果，但既不方便也不自然^[2]。另外不容忽视的一点是，动态语言大多是开源的，其本身的发展也更具动态性。”

引号非常注重理论：“动态语言的语法特征有那些？”

“动态语言秉承的一个理念是：优化人的时间而不是机器的时间。为提高人的生产率，宁肯牺牲部分的程序性能或者购买更高配置的硬件。由于硬件相对于人件一直在贬值，该理念便有了合理的现实基础。”冒号讲述着，“从语法上看，动态语言为了更好地粘合来自不同系统、不同语言的程序，对类型的要求一般不如静态语言那么严格，代码更加简洁自由，故而多为动态类型的和弱类型的，天然支持泛型式编程。当然这不是绝对的，比如Groovy也支持静态类型，Scala完全是静态类型的，Python一般认为是强类型的。大多数动态语言支持eval函数，能动态执行任意字符串形式的代码，并有丰富的反射（reflection）机制，天然支持元编程。动态语言很多还支持包括高阶函数（high-order function）和闭包（closure）等在内的函数式编程。此外，大多动态语言也支持对象式编程，如Python、Ruby、Perl 5、PHP 3等。”

句号补充道：“许多动态语言还支持过程式编程和并发式编程，简直把主要的编程范式一网打尽了！”

“其实Python、Ruby和Groovy等还可以进行切面式编程，这对于支持元编程的动态语言来说非常自然，因为切面式编程一般都是通过元编程来实现的。”冒号进一步指出，“而逻辑式编程语言的代表Prolog，同样有动态语言的特征。至于事件驱动式编程嘛，对支持callback的语言来说都不是难事。”

引号高兴地看到：“九大编程范式无一漏网啊！”

叹号较为感性：“静态语言给人的感觉是沉稳持重，而动态语言则活泼轻快。如果同时用静态语言和动态语言编程，岂不培养出双重人格？”

“程序员本就是双重人格的。”冒号淡淡地说，“你总结得没错，两类语言的风格的确大相异趣：待静态语言披盔戴甲、备马抬枪之际，动态语言已衣袂飘飘，长剑出手了。不过，如果是应付强敌的长期大规模作战，静态语言还是有优势的。”

引号听声辨音：“这意味着动态语言不适用大型应用开发吗？“

“这么说未免有些武断。”冒号并不同意，“诚然，动态语言的语法比较宽松，相对容易出错。但也有人辩称，动态语言的代码量少于相应的静态语言，bug应该更少。有人认为动态语言调试不如静态语言方便，有人却说随着IDE的日益强大，出错几率和找错成本也在减少。谈到运行效率，动态语言虽然多为解释型语言（interpreted language），但许多也提供了与Java类似的字节码编译（bytecode compilation）甚至JIT编译(just-in-time compilation)。动态语言在某方面甚至还更胜一筹：譬如一个类的接口如果发生变动，在静态语言中所有该类的子类和一些相关类都可能需要重新编译、连接，这在大型应用中是非常耗时的，而动态语言则大可不必，这当然不足为奇——在它眼里类结构本来就是能动态改变的。除此之外，越是大型的程序，越耗费人力和时间成本，客户需求的变化也越大，因而对程序的灵活性、适应性和开发周期提出了更高的要求。动态语言在这些方面比静态语言更有优势，并且还能作为快速原型（rapid prototyping）开发的工具。”

“快速原型开发？”问号一脸的疑惑。

冒号简作介绍：“这是一种软件开发的方式。举例来说，为了快速搭建一个系统，以适应不断变化的客户需要，可以先采用开发效率更高的动态语言。在交付时再将其转化为编译型的静态语言。如果系统对性能的要求不高，这种转化至多是局部的。有的干脆一字不易，不仅省了当下的时间，以后维护起来也更方便。”

逗号耍起了贫嘴：“这就叫：替补变成了主力，配角变成了主角，媳妇熬成了婆婆。”

叹号开始担忧起来：“听您这意思，动态语言优点突出而弱点并不突出，这样下去静态语言还有市场吗？”

冒号坦然道：“动态语言小快灵的风格的确吸引了越来越多人的注意，也渐渐走入静态语言的世界。Java平台和.NET平台不仅为Ruby和Python等动态语言铺设了跑道，而且为培植诸如Groovy等动态语言提供了土壤。同时，Java和C#本身也融进了越来越多的动态特征。”

句号断言：“静态语言这种融合性结合内在的安全性、稳定性，以及较高的性能、成熟度和接受度，都决定了它不可能被动态语言完全取代。”

“对！”冒号坚定地表示赞同，“当脚本语言披上动态语言的彩衣，昔日不起眼的毛毛虫便羽化成蝶，开始飘舞在众人追逐的目光之中。但静态语言也绝不会淡出人们的视线，它如矫健的苍鹰，依然有搏击长空的雄力。程序员只要保持严谨的作风和开放的心态，既有稳如泰山的马步，又有一跃凌空的飞腿，静如处子，动如脱兔，如履平地般游走于高高的梅花桩上，绝无跌落之虞。”

一股豪情在众人心中荡漾开来。

冒号看了看时间，敛起眼中精光，同时收起话匣：“关于动态语言，今天还是先简单谈到这里吧。”

待教室平静下来，冒号再度开腔：“在谈论动态语言之前，最好先澄清一下它与动态类型语言之间的区别。”

叹号讶然道：“它们不是一回事吗？一直以为动态语言是动态类型语言的简称呢。”

“有亲戚之名，却无血缘之亲。名称上相似，加之动态语言绝大多数确是动态类型语言，造成混淆实属在所难免，但二者之间并无必然联系——动态语言不一定是动态类型语言^[1]，动态类型语言也不一定是动态语言^[2]。”冒号飞跑的舌头几乎绊蒜，同时把众人的脑子搅成了一锅粥。

见势不妙，冒号改用迂回战术：“我们不妨再谈开些，大家对数据类型是如何理解的？”

逗号随口道：“数据类型不就是数据的种类吗？”

众人暗笑：说了跟没说差不多。

冒号说道：“数据类型包含两个要素：一个是允许取值的集合，一个是允许参与的运算。例如int类型在Java中既定义了介于-2³¹和2³¹ – 1之间的整数集合，也定义了该集合上的整数所能进行的运算。现在的问题是：数据类型的意义何在？”

句号回答：“限定一个变量的数据类型，就意味着限制了该变量的取值范围和所参与的运算，这从一定程度上保证了代码的安全性。”

冒号追问：“还有吗？”

句号略作思考后说：“用户自定义的数据类型，如C中的结构和Java中的类或接口，赋予数据以逻辑内涵，提高了代码的抽象性。”

“精辟！”冒号赞道，“数据类型既有针对机器的物理意义，又有针对人的逻辑意义。前者用于进行底层的内存分配和数值运算等，后者用于表达高层的逻辑概念。既然类型如此重要，类型检查就必不可少了^[3]。所谓动态类型语言（dynamic typing language），正是指类型检查发生在运行期间（run-time）的语言。”

“那静态类型语言（static typing language）自然是类型检查发生在编译期间（compile-time）的语言咯。”引号接话道。

冒号回应：“一般的说法是这样，但我更愿意将‘编译期间’四个字改为‘运行之前’，否则容易让人误解为静态类型语言一定是编译型语言（compiled language）。”

问号问道：“是否可以这么说：静态类型语言需要变量声明，而动态类型语言则不需要？”

“这话只对了一半。”冒号评论，“动态类型语言固然不需要显式的变量声明（explicit declaration），一些静态类型语言有时也不需要。典型的如ML、Haskell之类的函数式语言，编译器可以通过上下文来进行类型推断（type inference）。另外，C#从3.0起也开始支持局部变量的类型推断。”

“如何进行类型推断？”问号有点丈二和尚摸不着头脑。

冒号打了个比方：“假设‘+’号只限于同类型的数据运算，那么从表达式a + 1中可以推出a是整型变量，从b + 1.0中推出b是浮点型变量，从c + “1”中推出c是字符串型变量。这些变量不必事先声明，但一旦类型被推断确定后，便不再更改。由于这些推断都是在程序运行之前进行的，因此仍属于静态类型。它既有动态类型的简洁性，又不失声明式静态类型的安全性，可谓裁长补短啊。”

叹号有些羡慕地说：“还是动态类型语言好，不仅不必声明变量，而且一个变量在不同地方还可以代表不同类型，多省事多方便啊！”

冒号微微颔首：“虽然这种机制也有为人诟病之处，但不可否认，动态类型语言的确有它的优势：简明、快捷、灵活，并且天然具有泛型（generic）特征。值得一提的是，动态类型有一种被称作鸭子类型（duck typing）的形式。”

逗号感到有趣：“鸭子类型？很滑稽的名字。”

“这种类型通俗的说法是：如果一个对象既会走鸭步又会呷呷叫，何妨将其视作鸭子呢？”冒号说着投影出一段Ruby代码——

class Duck                      #会叫会游的鸭
    def shout
        puts '呷呷呷'
    end
    def swim
        puts '鸭泳'
    end
end

class Frog                      #会叫会游的蛙
    def shout
        puts '呱呱呱'
    end
    def swim
       puts '蛙泳'
    end
end

def shoutAndSwim(duck)          #让一只会叫会游的家伙边叫边游
    duck.shout
    duck.swim
end

shoutAndSwim(Duck.new)          #让一只鸭边叫边游
shoutAndSwim(Frog.new)          #让一只蛙边叫边游 

冒号继续讲解：“在Smalltalk、Python和Ruby等动态类型的OOP语言中，只要一个类型具有shout和swim的方法，它就可以为shoutAndSwim所接受。这在C++、Java、C#等静态类型语言中是不可能的^[4]，除非鸭和蛙在同一继承树上，或者二者均显式实现了一个包含shout和swim的公用接口。”

句号敏锐地指出：“C++是静态类型语言，但它的模板也可实现类似功能，并不需要引入继承关系。”

“说得很对！但请接着看下去。”冒号又放出一段投影——

class Cock                      #会叫不会游的鸡
    def shout
        puts '喔喔喔'
    end
end
 
class Fish                      #会游不会叫的鱼
    def swim
        puts '自由泳'
    end
end

def shoutOrSwim(duck, flag)     #让一只会叫或会游的家伙叫或游
    flag ? duck.shout : duck.swim
end

shoutOrSwim(Cock.new, true)     #让一只鸡叫
shoutOrSwim(Fish.new, false)    #让一只鱼游 

“这里鸡没有swim的方法，鱼没有shout的方法。若采用C++的模板，shoutOrSwim是无法通过编译的。但在支持Duck 类型的语言中，只要在运行期间不让鸡swim、让鱼shout——除非你突发奇想——一切平安无事。”冒号作了个OK的手势。

“动态类型语言真是越看越可爱。”叹号简直垂涎欲滴了。

“Duck类型的哲学是：名义不重要，重要的是能力，颇有些实用主义的味道。这种非继承性多态为软件重用开启了新的窗口，同时也埋下了一些陷阱。由于Duck类型的接口组合是隐性的，其使用者需要比普通interface更小心以避免误用；其维护者也需要更小心以避免破坏客户代码；另外它也可能造成滥用——将一个会叫会游的家伙放进池塘看起来不算坏主意，但如果一艘轮船趁机也轰隆隆地开了进来，事情恐怕就不那么美妙了。”

众皆莞尔。

“再来看看静态类型语言的好处：由于在运行之前进行了类型检查，一方面代码的可靠性增强，符合‘发现错误要尽早’的原则；另一方面编译器有可能藉此优化机器代码以提高运行效率，同时相比前者节省了运行期的耗费在类型检查上的时间和空间。此外，变量类型的声明彰显了编程者的意图，有辅助文档的功效。”冒号一五一十地介绍着，“两种类型的体制可以用两种法律原则来类比：静态类型检查类似‘疑罪从有’的有罪推定制——在被证明合法之前是非法的，动态类型检查类似‘疑罪从无’的无罪推定制——在被证明非法之前是合法的。至于如何取舍，套用一句话：‘Static Typing Where Possible, Dynamic Typing When Needed’。不妨理解为：尽可能守规则，必要时求变通。”

句号俏皮地说：“规则如裤带，过于宽松和过于束缚都不好。”

问号提出新问题：“动态类型语言与弱类型语言有何不同？”

冒号喟言：“它们也常常被混为一谈，但类型的动静与强弱完全是正交的两个概念。静态类型语言中，有强类型的Java，也有弱类型的C；动态类型语言中，有强类型的Smalltalk，也有弱类型的JavaScript。前者以类型的绑定（binding）时间来划分，后者以类型的约束强度来划分。通常弱类型语言（weakly-typed language）允许一种类型的值隐性转化为另一种类型^[5]。举个例子，1＋”2″在VB中等于3——第二个字符串转化为整数；在JavaScript中等于”12″——第一个整数转化为字符串；在C中则等于一个不定的整数值——第二个字符串作为地址来运算。这样似乎很有趣很方便，但程序容易藏污纳垢，滋生臭虫（bug）。与此相对地，强类型语言（strongly-typed language）着意贯彻类型控制，为保障数据的完整性和代码的安全有效性，一般不允许隐性类型转换^[6]。如果一定需要类型转换，必须是显性转换，一般通过我们熟知的铸型（cast）来完成。”

引号想起：“好像还有一种所谓的类型安全语言？”

逗号紧紧抱着头，仿佛害怕裂开。

“类型按安全性来划分，可分为类型安全语言（type-safe language）和类型不安全语言（type-unsafe language）。类型检查的目的就是为了避免类型错误（type error）^[7]，即杜绝因类型问题而产生的错误或不良代码。如果一个类型系统能完全做到这一点，它就被称为类型安全的。虽然尚存争议，但一般认为强类型语言对类型控制更严格，因而是类型安全的，弱类型语言是类型不安全的。类型安全固然对保障程序的合理性和可靠性十分重要，但若过于严苛，程序也就失去了活力，正所谓‘水至清则无鱼’啊。” 冒号有条不紊地解说着，“至此，我们已论及数据类型的三种划分方式。需要说明的是，这些划分并非泾渭分明的^[8]，更多的是定性而非定量的描述，甚至没有公认统一的定义。但了解它们，对我们理解编程语言和编程原则是大有裨益的。”

新课开始了，冒号一反常态，并没有直奔主题：“在谈论新话题之前，先请诸位畅所欲言，谈谈这段时间的学习感受。”

叹号表情有点复杂：“通过前面的学习，让我长了不少见识，只是——”

“但讲无妨。” 见叹号有些吞吞吐吐，冒号鼓励道。

“只是觉得有点——纸上谈兵。”叹号鼓足勇气说出心里话。

引号不以为然：“我倒觉得应该更深入地去了解编程范式，现在有了一些感性认识，但还非常肤浅，希望以后能进一步展开。”

逗号挺实在：“有些地方似懂非懂，听起来挺费劲的，直到情景编程才觉得轻松了些。以后可不可以多谈些具体的编程知识、编程技巧和编程经验？”

句号拍了拍他的肩膀：“你想学的是招法，老冒传的是心法。”

逗号不服：“没有招法再多心法也白搭——光说不练假把式。”

句号反驳：“只关注招法，境界永远得不到提升——光练不说傻把式。”

“二位请暂停争论。”冒号把头转向问号，“你怎么看？”

问号很干脆：“管它心法还是招法，能解决问题的就是好法。”

“你倒滑头，整个一白猫黑猫论嘛！”冒号哈哈一笑，“首先，编程范式绝非中看不中用的屠龙之术，它有助于我们更快速地掌握、更深刻地理解、更纯熟地运用编程语言，故有心法之谓。其次，心法只有通过招法才能落到实处，也只有通过招法才能融会贯通。”

“那传说中的‘无招胜有招’呢？”引号问。

冒号哂道：“武侠小说看多了，容易想入非非，那种境界岂是一般人所能达到的？对绝大多数人来说，无招就意味着自己没招而将中他人之招。”

众人窃笑。

“还有一样是至关重要的。”冒号提醒道，“那就是实战。”

句号深有体会：“以前在学校里编程似乎还得心应手，到了公司就时感力有不逮。”

“花拳绣腿对付小喽啰绰绰有余，真碰到高手自然漏洞百出了。”冒号直言道，“编程水平的提升之道是：在实战中演练招法，在招法中领会心法，心法反过来提升招法，进而提高实战水平，如此循环往复呈螺旋式上升过程。正所谓熟能生巧，巧能生通。”

问号询道：“下面我们的主题是什么？”

冒号亮出他的一套学习理论：“软件工程中有个迭代开发法，本班则采用迭代学习法：即在具体知识与抽象理论之间进行折返式学习。当然这种迭代不是机械式的重复，而是增量式的循环。假定你们以前更关注具体的编程语言，那么遵循这种方式，先介绍抽象的编程范式是合适的。在初步了解范式之后，不妨重新回到编程语言上来。”

叹号唯唯连声：“是啊，在空中飘久了，会染上恐高症的。”

冒号笑着警告：“不要高兴太早，着陆后我们还会再次起飞的——别忘了我们的迭代式学习是周而复始的。至于眼下谈什么，还是先征求各位的意见，这样开放式教学才名副其实嘛。”

众人开始交头接耳、七嘴八舌地议论起来。

一阵商讨之后，大家似乎未能达成共识。冒号见状，便让他们一一道来。

问号再次充当急先锋：“能不能比较一些当今主流语言各自的优缺点？”

冒号笑言：“我怎么恍惚间又回到了第一堂课？你的潜台词还是那句话：到底学哪种语言好？”

问号被窥破心事，微露窘色。

“不过我非常理解你们的想法。”冒号体谅道，“虽然这是编程中最易提出却又最难回答的问题，但考虑到大家对它如此兴致盎然，我决定不顾引火烧身之危，铤而走险一回。”

众人鼓掌。

冒号故作疑惑：“你们这是对问题的答案表示期待呢，还是对我的勇气表示赞赏？”

众皆笑曰：“兼而有之，兼而有之！”

叹号提出：“近来动态语言非常流行，能说说它与静态语言到底有何不同，是否会取而代之？”

“嗯，这个问题总算简单了些。”冒号如释重负。

逗号坚持道：“我还是那个建议，希望学些具体的编程知识和技巧，比如将最流行的Java语言中的一些重点和难点分几个专题来讨论。”

冒号颔许：“这是个很好的建议，可以采纳。”

引号有不同意见：“Java没有C++来劲：要说难点，C++多得多；要说流行度，按照TIOBE的数据，C与C++之和还超过Java六个百分点呢。”

逗号不服：“你没看到C和C++正在逐渐没落吗？”

引号冷哼一声：“开玩笑，什么时候操作系统、数据库、游戏软件和嵌入式系统都改用Java了再说这话。别忘了，Java的虚拟机都还是C或C++写成的呢。”

冒号忙止住干戈：“我还没来得及成为众矢之的呢，你们二位倒先掐上了。”

句号提议：“最好找一个项目实例，从头至尾演练一次，既能贯穿各个知识点，又能让我们对软件开发有个整体认识。”

“这个想法听起来非常不错。”冒号沉吟了一会又道，“只是一个真正企业级的项目，涉及面太广。比如一个完整的web应用，不论是采用重量级的Java EE或.NET技术，还是采用轻量级的Perl、PHP、Ruby、Python等动态语言技术，除了要掌握各自的主体语言外，还涉及到相应的框架、集成环境和各种工具，以及JavaScript、CSS、HTML和XML等技术，同时数据库的知识也是不可或缺的。”

问号奇道：“JavaScript、CSS和HTML这些不主要是网页设计人员的语言吗？”

冒号解释：“网页设计人员大多用Dreamweaver之类的工具来设计HTML页面，开发一般网站尚可勉力而为，若开发企业级软件则有些力不从心了。更何况web应用的趋势是具有更丰富用户体验的Rich Internet application （RIA），采用大量的AJAX、FLEX等技术，需要熟悉Javascript或Actionscript之类的语言，这些就更非一般网页设计人员所能胜任。”

引号插言：“据我所知，许多公司都是请网页设计师来编写HTML和Javascript等代码的。”

冒号指出：“网页的迷人之处就在于，能够用精美的画皮来包裹冗长低效的代码。出于软件开发的时间和成本的考虑，公司的选择无可非议，但如果要提高软件竞争力，这些代码至少要经过程序员的加工处理。”

逗号复言：“那数据库总该是数据库管理员的事吧？程序员至多用到hibernate、iBATIS之类的ORM^[1]框架。”

冒号断然否定：“数据库绝不只是DBA的事，ORM也不能取代数据库的设计和SQL的使用。另外，复杂的应用需要编写大量的存储过程（stored procedure），故还应掌握PL/SQL或Transact-SQL等扩展数据库语言。换句话说，从web开发最前端的网页到最后端的数据库，都应该有程序员的身影。”

句号联想到：“借用前面餐馆的例子，不妨把接待员看作客户层（client tier），把服务员看作表现层（presentation tier），把厨师看作业务层（business tier），把收银员看作数据层（data tier），把厨工看作常用的辅助类（helper class）^[2]。”

冒号微微点头：“比较靠谱。要说不当之处，就是服务器端的表现层不会如服务员那样直接与客户打交道，此外业务层常与数据层打交道，但厨师好像不会与收银员有什么瓜葛。”

叹号夸张地捂住脸：“天哪，程序员竟然身兼五职，太惨了吧？”

“当然程序员会各有分工，不过如果你总局限某一层的应用开发，今后凭什么谋取更高的职位？”冒号苦口婆心，“无论干哪一行，要想胜任愉快，离不开四样东西：才能、兴趣、方法和努力。没有才能则难以胜任；没有兴趣则难以愉快；没有方法则事倍功半；没有努力则一事无成。我相信好的方法最终能激发人的才能、兴趣和努力，这也是本班的一个理念。希望大家能通过各种问题的讨论，获得一些方法上的启示。”

问号急切地询问：“那么我们的下一步是什么？”

“综合各位的意见，我们从简到繁。”冒号公布计划，“先简单谈谈动态语言；再对主流语言作简评；然后范式上以OOP为主，语言上以C++、Java和C#为主，作一些专题讨论；最后如果时间允许，找一个项目来实践一番。”

“呕耶！”众人皆大欢喜。

叹号摘下眼镜，揉了揉眼：“范式再好，多了也难免有些审美疲劳。”

逗号也搓着太阳穴：“这段时间脑子被灌得沉甸甸的。”

“彼此彼此！你们的脑袋老闹涝灾，我的喉咙老闹旱灾。”冒号说着，拿起矿泉水瓶一饮而尽。

大伙听着怪别扭的，这不是拐着弯说我们脑子进水了吗？

冒号清了清嗓子：“为尊重民意，也为避免消化不良，大家先轻松一下。下面我们来个情景编程。”

“情景编程？没听说过，只听说过情景英语。”问号感到挺新鲜。

“都是学语言嘛，有何两样？”冒号轻描淡写，“让我们试着用生活中的实例将一些编程范式串联起来。前面提到，OOP可以看作管理一个服务型公司，现在以餐馆为例，你们每人设计一类对象及其提供的服务。”

问号来了兴致：“我先来吧。构造一个前台接待员，负责迎客、引座、送客。”

句号很是不满：“还真不客气，上来就把最漂亮的对象抢走了。”

台下一阵笑声。

“我来构建最常见的服务员。”逗号一捋袖子，一副准备开干的样子，“负责斟茶、写菜、上菜、换盘。”

“嗯，很熟练。”冒号一本正经。

句号实在得很：“我设计收银员，专管收帐、出具发票。”

引号颇为自豪：“我造一个技术含量最高的大厨，专门负责烹调。”

逗号不服：“你倒简单，那么高的技术含量，敢情炒肉和炖肉一个做法啊？”

引号自觉理亏：“那就负责蒸、煮、炒、炖吧。”

冒号为其辩护：“引号同学并没有错，可惜没能坚持。厨师只需提供一种服务：把纸上菜变成盘中菜，至于蒸、煮、炒、炖等具体做法纯属实现细节。”

叹号有点委屈：“唉，看来我只好做技术含量最低的厨工了，负责食品预加工、洗碗、打扫清洁。”

冒号将大家设计的类翻译成Java代码——

// 前台接待员
Class Receptionist
{
    public void receive(Customer customer)  {…} // 迎客
    public void usher(Customer customer)    {…} // 引座
    public void send(Customer customer)	    {…} // 送客
}

// 服务员
Class Waiter
{
    public void pourTea(Customer customer)             {…} // 斟茶
    public List<Order> write(Customer customer)        {…} // 写菜
    public void serve(Customer customer, Course course){…} // 上菜
    public void exchangePlate(Customer customer)       {…} // 换盘
}

// 收银员
Class Cashier
{
    public void charge(Customer customer)	{…} // 收帐
    public void issueInvoice(Customer customer) {…} // 出具发票
}

// 厨师
Class Cook
{
    public Course cook(Order order)		{…} // 烹调
}

// 厨工
Class KitchenHand
{
    public void prepareFood()			{…} // 准备食品
    public void washDishes()			{…} // 洗碗
    public void clean()				{…} // 打扫清洁
}

“你们造人，我来造物。”冒号构造了一个餐馆的类——

// 餐馆
Class Restaurant
{
    // 每当有顾客来访，返回该顾客
    private Customer accept() {…}
 
    // 为指定顾客提供所有的餐馆服务
    private void serve(Customer customer) {…}

    // 餐馆服务
    public void service()
    {
        while (true) // 无限循环，假设餐馆7×24小时营业
        {
            final Customer customer;
            if ((customer = accept() ) != null) // 某顾客来访
            {
                serve(customer);  // 为该顾客提供服务
            }
        }
    }
}

冒号解说道：“这里accept类似Socket的accept，属于堵塞呼叫，意味着此方法将堵塞进程直至收到新数据。为简单计，把一行顾客当作一个Customer。大家对此段代码有何看法？”

“没什么，很简单啊。”逗号说完补充一句，“关键是serve方法的实现。”

“这里我们明显用到了两个范式，对象式和过程式。”冒号提示道。

引号会意：“应该还需要并发式。serve如果与service在同一线程中运行，那么餐馆只有等服务完一个Customer后才能服务后面的，这显然是荒唐的。”

“对极了！”冒号将“serve(customer);”改写为——

// serve(customer);  // 错误地使用单线程！
new Thread           // 构造一个线程
    (new Runnable()
    {
        public void run(){ Restaurant.this.serve(customer); }
    }).start();         // 启动该线程 

冒号道：“这回serve在新线程中运行，不会耽误Restaurant服务下一位Customer了。”

问号眼尖：“我注意到声明customer时前面加上了关键字final，有必要吗？”

“如果不用线程，是不必要的。”冒号回应道，“我们在建造线程时用到了实现Runnable接口的匿名类（anonymous class），它是涉及到局部变量customer的内部类（inner class），Java语法要求该局部变量必须是final类型。值得一提的是，这里不仅用到了并发式，而且与函数式也密切相关。”

“函数式？”逗号奇道。

“不错。”冒号坚定地点着头，“我们不是提过函数式中的函数是头等公民吗？也就是说，函数与其他基本数据类型一样，可以作为传递参数、返回值或与变量名绑定。闭包（closure）便是这样一种函数，并且还能保留当初创建时周围的环境变量。以上匿名类本质上是函数serve的包装，经实例化后作为参数传入Thread的构造函数，并且记住了外部类的局部变量customer——这也是为什么它必须是final以保证不被重新赋值的原因。应该说这是一种OO化的闭包形式，预计在Java 7中它的用法会更简洁，这也意味着Java代码中将飘进更多的函数式风味。”

引号喃喃道：“以前只听说过数学里有个闭包的概念。”

冒号略加指点：“可以这么理解：所谓包，指函数与其周围的环境变量捆绑打包；所谓闭，指这些变量是封闭的，只能为该函数所专用。如果你真懂数学，就会发现它们本质上是相通的。”

叹号隐隐约约地觉得：“把函数与变量捆绑起来，怎么听起来像是OOP的做法啊？”

“嗯，的确相似。”冒号微颔，“不妨认为闭包就是封装了环境变量的隐形对象的方法——通常是匿名方法。我们用一段JavaScript代码来加深印象——”

/* 返回函数f的近似导函数 */
function derivative(f) 
{  // dx最好作为参数传入，放在此处主要是为了说明闭包的用法
    var dx = 0.00001;  // dx越小，近似度越高
    return function(x) { return (f(x + dx) - f(x)) / dx; };
} 

/* 返回一个数的平方数 */
function square(x) { return x * x; }

/* 返回一个数的双倍数  */
function double(x) { return 2 * x; }

/* 对任何一个不大的数值变量x（比如小于100），下列函数的返回值应该非常接近于零 */
function testSquareDerivative(x) { return derivative(square) (x) - double(x); } 

叹号感到有点头痛：“怎么跑出了微积分？大学学的那点高数早就还给老师了。”

冒号笑着安慰他：“还给老师没关系，我再借给你一点：平方函数的导数是双倍函数。因此，函数derivative(square)应该很接近函数double的作用效果。作为检验，testSquareDerivative能将任何一个不大的数映射到近似于零的数^[1]。”

引号这下彻底明白了：“在求导函数derivative中，传入的参数f和返回值都是函数，这是函数作为头等公民的特征。其中返回的匿名函数就是闭包，它附着了两个环境变量：外层函数的传入参数f和局部变量dx。”

“完全正确！”冒号作出积极的肯定，“如果不是闭包，这两个环境变量在derivative返回后就会失去效用。由此可见，合理地使用闭包能使代码更加简洁清晰，散发出函数式特有的优雅气质。”

句号有些按捺不住编程的冲动，自告奋勇：“我来具体实现餐馆的serve方法吧。”

得到冒号的默许，句号在黑板上写下——

private void serve(Customer customer)
{
    // 找一个空闲的接待员
    Receptionist receptionist = findReceptionist();
    receptionist.receive(customer);
    receptionist.usher(customer);
    // 找一个空闲的服务员
    Waiter waiter = findWaiter();
    waiter.pourTea(customer);
    List<Order> orders = waiter.write(customer);
    // 将菜单交给一位厨师
    Cook cook = waiter.pass(orders);
    for (Order order : orders) // 厨师照单做菜
    {
        Course course = cook.cook(order);
        // 找一个空闲的服务员
        waiter = findWaiter();
        // 服务员上菜
        waiter.serve(customer, course); 
        // 顾客开始享用
        customer.eat(course); 
    }

    // 顾客用餐完毕。。。
    // 找一个空闲的收银员
    Cashier cashier = findCashier();
    cashier.charge(customer);
    cashier.issueInvoice(customer);
    // 找一个空闲的接待员
    receptionist = findReceptionist();
    receptionist.send(customer);
} 

句号写毕又复查一遍，拍拍手上的粉笔灰，心满意足地走下台来。

叹号提意见：“我的厨工没派上用场，应该在厨师烹调前调用KitchenHand的prepareFood方法。”

问号挑出另外的毛病：“在for循环中，厨师、服务员和顾客的行为应该在不同的线程中，厨师不可能等服务员上完一道菜或顾客吃完一道菜后才做下一道。”

“可能更复杂呢！”逗号也来凑热闹，“一位顾客点的几样菜可能分别由几位厨师同时做，每位厨师都在不同的线程中工作。”

引号更严谨：“还应有一个后台线程，让服务员（Waiter）随时换盘（exchangePlate），让厨工（KitchenHand）随时洗盘（washDishes）和清洁（clean），这样所有服务人员提供的服务都用上了。”

句号倒抽凉气：“估不到漏洞这么多，并发式真是无处不在啊。”

冒号继续点拨：“换盘子有两种方式：一种是服务员主动换，一种是客人要求换。前者是轮询，后者是通知。”

“哦，事件驱动式！”句号迅即反应过来，“客人是事件源，服务员是事件处理器，客人不定期地招手呼唤是在发表事件以通知服务员。客人与服务员是多对多的松耦合关系。”

冒号点点头，又指着引号：“刚才有人不满你的大厨职责过于简单，现在你来实现一下，也好显显技术含量。”

引号在台上摸了半天头，编出一段代码——

Class Cook
{
    public Course cook(Order order) 
    {
        // 根据菜单查食谱
        Recipe recipe = lookupRecipe(order);
        // 找到食谱的烹调步骤
        List<Instruction> instructions = recipe.getInstructions();
        for (Instruction instruction : instructions)
        {
            follow(instruction); // 按食谱的指令操作
        }
    }
} 

“堂堂大厨原来是靠查食谱做菜的。”逗号揶揄道。

引号为难地说：“这不是在编程嘛，好端端的人脑，不得不去模拟电脑，完全搞倒了。”

“要设计会烹调的机器人，兴许还真得这样呢。”冒号笑道，“不过由于各种菜式组合繁多，如果每种菜都配菜谱未免太庞杂，如何精简呢？”

句号建议：“菜式成千上万，烹调技法相对少许多，不妨以技法为主线。”

“好主意！”冒号挑起大拇指，“如果把待加工的菜看作数据，技法看作算法，将数据与算法分离，以算法为中心，那是什么范式？”

“泛型式！”大家异口同声。

“至此我们已涉及了过程式、对象式、并发式、函数式、事件驱动式和泛型式。”引号扳着手指算着，“还差逻辑式、元编程和切面式了。”

冒号把目光转向逗号：“写菜单并不容易，如果客人不直接点菜，你的服务员如何向他推荐？”

逗号答：“最简单的方法是报菜名，并一一询问客人。”

冒号皱眉：“这样你是简单了：一个迭代就完事，可客人也该发火了。”

逗号赶紧修正：“先询问客人的口味、忌讳等等，再向他建议一些菜式。”

“这还差不多。”冒号眉头舒展开来，“考虑到客人的口味、忌讳等各有不同，餐馆的菜单也随时可能变化，如果把这些都硬编码（hardcode），再加上层层叠叠的if-else语句，代码将成为懒婆娘的裹脚——又臭又长又难维护。”

引号提议：“可以把这些信息预先存入数据库，届时用SQL查询。”

“想法很好，只是有一点难度。”冒号提醒道， “这些信息并非简单的对应关系，包含一些逻辑推理，甚至需要一些模糊判断。”

句号一拍大腿：“前面不是提到领域特定语言DSL吗？将所有规则用自定义的DSL编写，再利用元编程转换成C、Java之类的通用语言，不是很好吗？”

“棒极了！”冒号不吝赞词，“不过还有一种思路。我们可以搜集餐馆的菜式、顾客口味、忌讳以及各种菜与口味、忌讳之间的关系等等一系列事实和规则，用规则语言（Rule Language）来描述，通过规则引擎（Rule Engine）来导出符合顾客需求的菜肴。这种方式将业务规则与应用程序分离、将知识表示与逻辑实现分离，是SoC原理的一种应用，同时也是一种逻辑式编程。”

问号关心地问：“这些规则引擎与Java程序兼容吗？”

冒号回答：“不少规则引擎用Java实现或专为Java平台设计，如Jess、Drools、JLisa、JRules等，Sun还发布了javax.rules API（JSR 94）以统一对各类引擎的访问接口。另外在.NET平台上也有业务规则引擎，Microsoft Business Rule Engine（MS BRE）和Windows Workflow Foundation （WF）中的WF Rules均提供了业务规则引擎。”

引号颇感意外：“既然是逻辑式编程，为什么不采用代表语言Prolog呢？”

冒号准备了一大段理由等着他：“刚才提到的规则引擎多是基于Rete算法^[2]的，主要采用数据驱动（data-driven）的正向推理（forward chaining）法，而Prolog引擎采用目标驱动（goal-driven）的逆向推理（backward chaining）法。正向推理自底向上，利用推理规则从已有的事实数据推出更多的数据，直到达成目标；逆向推理正相反，自顶向下，从目标出发寻找满足结论的事实^[3]。相比而言，正向推理适合针对不同输入作出不同反应，而逆向推理适合回答查询。现在是服务员根据客人的喜好提建议，当然用正向推理更合适。再说这类引擎与Java的集成更加方便，因此我们没有选择Prolog。”

讲到此处，每个人都意识到，只剩下最后一个范式了。

冒号提出一个新问题：“假如餐馆经理接到顾客投诉，反映服务人员态度不好，卫生状况也不理想，应该怎么办？”

问号抢先说：“首先我的接待员在迎客（receive）时要笑容可掬地对顾客说：‘欢迎光临！’，在送客（send）时要对顾客鞠躬：‘请慢走，欢迎下次再来’”

逗号接着说：“我的服务员在上完菜后应对客人说：‘请慢用’，句号的收银员也应加些礼貌用语，让人家高高兴兴地掏钱。”

句号补充道：“服务员在上菜（serve）前、厨师在烹饪（cook）前应洗手，厨工在洗碗（washDishes）后应对餐具消毒。”

冒号紧接着问：“如果餐馆对礼貌规范或卫生标准做修改，必然要牵扯不同类中的不同的方法，维护起来很不方便，怎样才能有效地解决这个问题呢？”

答案已经昭然若揭了。

冒号干脆自问自答：“不错，正是用切面式编程。只要创立两个Aspect：Etiquette和Sanitation，分别负责礼貌规范和卫生标准方面的事务。一旦某一方面的要求发生变化，比如餐馆来了外宾，或者碰上非典或禽流感，只需在相应的Aspect模块中作调整：将礼貌用语换成英语或者提高卫生标准等等。如果采用runtime AOP，甚至还可在运行期选择激活或禁用这些Aspect。”

下面开始有些骚动，大伙早已脑中满满而腹中空空，有点头重脚轻了。

冒号见状，遂发出激动人心的号召：“今天的课到此结束，让我们从虚拟的餐馆中走出，到真实的餐馆中去吧！”

众人齐声欢呼。

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

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

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

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

冒号解疑：“这倒并不矛盾。同样的思想用在整体系统的结构设计上，则称为架构模式；用在局部模块的细节实现上，则称为设计模式^[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]；元编程过于强大，运用不当会超出程序员的控制，宜谨慎使用；切面式编程减少了程序的可预测性和可控性，同时给代码的跟踪调试带来一定困难，还可能造成性能上的损失；事件驱动式编程虽然也能用于同步的流程应用，但毕竟机制更复杂，没有普通的流程式编程那么自然易懂。”

叹号看上去有点泄气：“您可真够绝的，先把这些编程范式一个个捧到天上，又几杆子它们一个个打下云端。”

“因其长而容己，因其短而容他，此万物之理也。”冒号忽然惜言如金，一番之乎者也地予以回应。

句号借用了一句俗话：“不怕有缺点，就怕没特点。”

冒号本欲多言，却恐众人食多伤胃，遂作结案陈词：“尽管只是管中窥豹，相信大家多少见识了编程范式的魅力之处。它们各擅胜场，有风格之别而无高下之分。作文绘画讲究形神兼备，编程也不例外。语言为形，范式为神。若能以神导形、以形传神，则看似平白无趣的程序也能写出诗画般的意境。”

一席话说得众人皆觉虽不能至，然心向往之。

问号提出：“逻辑式编程不是也很特别吗？前面似乎介绍得也不多。”

“那我们就用逻辑式语言Prolog再实现一次quicksort吧。”冒号说着将幻灯片翻页——

/*快速排序法的Prolog实现 */
/* 定义划分法 */
partition(_,[],[],[]).                             /* 划分递归终点 */
partition(Pivot,[X|Rest],[X|Small],Big) :- 
X < Pivot, partition(Pivot,Rest,Small,Big).        /* 比基准小的归入Small */
partition(Pivot,[X|Rest],Small,[X|Big]) :- 
X >= Pivot, partition(Pivot,Rest,Small,Big).       /* 比基准大的归入Big */

/* 定义排序法 */
qsort([],[]).                                      /* 排序递归终点 */
qsort([Pivot|Rest],Sorted) :- 
partition(Pivot,Rest,Small,Big),                   /* 按基准划分子列 */
      qsort(Small,SortedSmall),                    /* 对前面的子列递归 */
      qsort(Big,SortedBig),                        /* 对后面的子列递归 */
      append(SortedSmall,[Pivot|SortedBig],Sorted)./* 子列合并 */ 

逗号挠挠头：“看不太懂哦，好在我记住了您的一句话：容忍无知。我忍了！”

大伙都乐了。

“本节课的焦点不是语言而是范式，因此对Prolog代码不详加解说。我只简单地说三点：首先，Prolog代码是由一系列事实（fact）、规则（rule）和查询（query）语句组成的^[1]。其次，与大多数语言不同的是，大写字母或下划线开头的标识符是变量，其他的是常量或函数。请注意，这不是约定俗成，而是语法规定。最后，符号‘:-’等价于if；逗号‘,’等价于and。比如，我们可以用Prolog来表达一个断言：如果一个人未婚且为男士，那么他就是一光棍。”冒号转身在黑板上写下——

/* X is bachelor if X is unmarried and male*/
bachelor (X) :- unmarried(X) , male(X). 

听见下面一阵嘀咕声，冒号忽地闪过一个念头：这个例子该不会触动了满足条件的某位同学的心事吧？顿了一会，继续说道：“逻辑式实现的排序虽不比函数式更简洁，但比起过程式来还是绰绰有余的。毕竟同属声明式，省去了不少有关变量赋值、迭代和流程控制方面的代码。我们再看一个更加典型的范例。”

黑板上出现了一幅树状图形——

图4-1. 家谱

冒号简作说明：“这是一个三代家谱图。已知每人的性别和父辈，要求判断任意两人之间的关系。我们先用Java来试一试——”

class Person
{
    private Person parent;
    private boolean isMale;

    public Person(Person parent, boolean isMale)
    {
        this.isMale = isMale;
        this.parent = parent;
    }

    private boolean isSibling(Person other)
    {
        return parent == other.parent && parent != null && this != other;
    }

    public String getRelation(Person other)
    {
        if (other == null || this == other) return null;

        if (parent == other) return isMale ? "son" : "daughter";

        if (other.parent == this) return isMale ? "father" : "mother";

        if (parent == null) // this是老祖宗
        {
            if (other.parent == null) return null;

            if (other.parent.parent == this) return isMale ? "grandfather" : "grandmother";

            return null;
        }

        if (other.parent == null) // other是老祖宗
        {
            if (parent.parent == other) return isMale ? "grandson" : "granddaughter";

            return null;
        }

        // 非直系
        if (isSibling(other)) return isMale ? "brother" : "sister";

        if (parent.isSibling(other.parent)) return "cousin";

        if (parent.isSibling(other)) return isMale ? "nephew" : "niece";

        if (isSibling(other.parent)) return isMale ? "uncle" : "aunt";

        return null;
    }

    public static void main(String[] args)
    {
        Person a = new Person(null, true);
        Person b = new Person(a, true);
        Person c = new Person(a, true);
        Person d = new Person(a, false);
        Person e = new Person(b, false);
        Person f = new Person(b, true);
        Person g = new Person(c, false);
        Person h = new Person(d, true);
        Person i = new Person(d, false);
        Person j = new Person(d, true);
        // 以下省略。。。
     }
}

“这段代码很平凡，毋需多言。再来看看逻辑式语言的做法。”冒号不愿过多地纠缠于细节，随即又换成了Prolog代码——

/* 规则 */
/* 上下两代直系关系 */
father(X,Y)        :- parent(X,Y), male(X).
mother(X,Y)        :- parent(X,Y), female(X).
child(X,Y)         :- parent(Y,X).
son(X,Y)           :- parent(Y,X), male(X).
daughter(X,Y)      :- parent(Y,X), female(X).

/* 祖孙关系 */
grandparent(X,Y)   :- parent(X,Z), parent(Z,Y).
grandfather(X,Y)   :- grandparent(X,Y), male(X).
grandmother(X,Y)   :- grandparent(X,Y), female(X).
grandchild(X,Y)    :- grandparent(Y,X).
grandson(X,Y)      :- grandparent(Y,X), male(X).
granddaughter(X,Y) :- grandparent(Y,X), female(X).

/* 平辈关系 */
/* 若X与Y有相同的父辈Z，且X不是Y，则X与Y是同胞*/
sibling(X,Y)       :- parent(Z,X), parent(Z,Y), X\==Y. 
brother(X,Y)       :- sibling(X,Y), male(X).
sister(X,Y)        :- sibling(X,Y), female(X).
cousin(X,Y)        :- parent(Z,X), parent(W,Y), sibling(Z,W).

/* 上下两代旁系关系 */
uncle(X,Y)         :- parent(Z,Y), brother(X,Z).
aunt(X,Y)          :- parent(Z,Y), sister(X,Z).
nephew(X,Y)        :- parent(Z,X), sibling(Z,Y), male(X).
niece(X,Y)         :- parent(Z,X), sibling(Z,Y), female(X).

/* 定义一个普适关系relation，方便查询 */
relation(R, X, Y)       :-  relations(Rs), member(R,Rs), Q =..[R,X,Y], call(Q).

/* 事实 */
/* 关系列表 */
relations([parent,father,mother,son,daughter,grandparent,grandfather,
grandmother,grandchild,grandson,granddaughter,
                sibling,brother,sister,cousin,uncle,aunt,nephew,niece]).

parent(a,b). parent(a,c). parent(a,d).
parent(b,e). parent(b,f).
parent(c,g).
parent(d,h). parent(d,i). parent(d,j).

male(a).
male(b).
male(c).
female (d).
female (e).
male(f).
female (g).
male(h).
female (i).
male(j). 

叹号没有看出名堂：“Prolog代码并不比Java代码简短多少啊。”

“评价代码的复杂度，长短只是一个因素。程序员不是打字员，花在思考上的时间和精力远远超过花在键盘上。”冒号指出，“就拿此例来说，Java代码虽然并不复杂，但有不少的选择分支语句，次序很重要。稍有不慎，就会出现逻辑错误。另外如果我们把关系分得更细致些，比如区分叔伯舅、姑姨婶、堂兄表妹等；再加入姻亲关系，比如姑嫂婆媳、妯娌连襟等。这时你再来改写这段代码试试？”

引号听得头皮有些发麻：“那一定需要不少重重嵌套的if-else语句了。”

问号提出的问题更让人头痛：“如果我们不限于三代，再加上曾孙女、曾叔父之类的关系呢？”

逗号联想到一则笑话：“话说一对父子与一对母女联姻，作父亲的娶了那位女儿，作儿子的娶了那位母亲。本来关系已经够颠倒错乱了，雪上加霜的是这两对夫妇又各自有了子女，那位父亲终于精神崩溃了。”

大家哄笑着：这下彻底乱套啰。

“前面的Java代码之所以没有嵌套，得益于及时退出的一些return语句。如果考虑到超过三代的关系以及多重交叉的关系，许多语句都得改写。可见上述代码是多么地脆弱！” 冒号就棍打腿，“再看Prolog代码，如果要求更细的血亲关系、增加姻亲关系或三代以上的关系，只需引入新的规则和事实即可，不会影响原有代码。下面列出几个示范语句——”

/* 规则 */
/* 配偶原则 */
father(X,Y)          :- spouse(Z,X), mother(Z,Y).
mother(X,Y)        :- spouse(Z,X), father(Z,Y).
husband(X,Y)      :- spouse(X,Y), male(X).
wife(X,Y)            :- spouse(X,Y), female(X).

/* 父系的堂、姑兄弟姐妹 */
paternal_cousin(X,Y) :- father(Z,X), father(W,Y), sibling(Z,W).
/* 母系的舅、姨兄弟姐妹 */
maternal_cousin(X,Y) :- mother(Z,X), mother(W,Y), sibling(Z,W).

/* 姻亲关系 */
father_in_law(X,Y) :- spouse(Y,Z), father(X,Z).
mother_in_law(X,Y) :- spouse(Y,Z), mother(X,Z).
son_in_law(X,Y)    :- spouse(X,Z), daughter(Z,Y).
daughter_in_law(X,Y) :- spouse(X,Z), son(Z,Y).

/* 曾祖孙关系 */
great_grandparent(X,Y) :- grandparent(Z,Y), parent(X,Z).
great_grandchild(X,Y)  :- grandchild(Z,Y), child(X,Z).

/* 事实 */
/* 新引入的关系 */
relations([husband,wife, paternal_cousin,maternal_cousin,
father_in_law,mother_in_law,son_in_law,daughter_in_law,
great_grandparent,great_grandchild]).

parent(pa,a).
spouse(a,as).
spouse(ds,d).
spouse(cs,c). 

句号方悟其妙：“这样的代码既无层层嵌套，也无次序分别。比起过程式，编写轻松得多，程序的可维护性和可扩展性也更高。”

“此外另有妙处。逻辑式与过程式和函数式的一个不同之处是，它没有明显的输入、输出之分。上面的程序不仅可以用来判断任意二人之间的关系，还能倒过来通过关系来找人。”冒号板书了几行字——

引号义务作翻译：“这告诉我们两件事：a与ds是翁婿关系，pa有曾孙e、f、g、h、i和j。”

“逻辑式语言着眼于关系而非函数，对付这类问题正是它的拿手好戏。”冒号声音逐渐高亢，“大家应该都听说过等式‘算法+数据结构=程序’吧？这是Pascal设计者Niklaus Wirth的一本著作的书名，它刻画了过程式尤其是结构化编程的思想。后来Robert Kowalski进一步提出：算法=逻辑+控制。其中逻辑是算法的核心，控制主要用于改进算法的效率。在逻辑式编程中，程序员只需表达逻辑，而控制交给编程语言的解释器或编译器去管理。”

“所以程序员的负担大大减轻了。”问号接口道，“逻辑式编程听起来真是不错，但不知Prolog程序能否与Java程序对接呢？”

冒号回答：“任何程序之间的对接都是可能的，只是不同的对接方式在复杂度和效率上有所差异而已。除了通过程序之间的通讯（如socket）或可执行文件的直接调用外，Prolog与C、C++、Java、C#、VB、Perl、JavaScript等多种语言之间，还能借助工具进行源代码转换^[2]或通过双向编程接口互嵌代码。具体到Java，一方面可以通过JNI （Java Native Interface）与Prolog引擎相连^[3]，另一方面可以利用Prolog引擎的Java实现来完成JVM上的集成^[4]。”

句号请求：“能否总结一下逻辑式编程的优缺点？”

冒号欣然应允：“由于逻辑式编程模拟人类的逻辑思维，故而在机器证明、专家系统、自然语言处理、博弈等人工智能领域如鱼得水，同时在非学术领域的知识管理、智能决策分析等方面也能大显身手。同为声明式，它与函数式一样比命令式更简洁、更抽象、更少副作用，运用得当能大大提高生产效率，还能用于快速原型（rapid prototyping）开发。但缺点是运行效率偏低，可掌控性较差，与常规的过程式思维差异较大，更适合基于规则（rule-based）而不是基于状态（state-based）的应用^[5] 。此外，相对而言逻辑式语言还不够成熟和完善。”

逗号“抗议”道：“我怎么感觉经过这么一反刍，胃里的负担更重了？”

冒号略带歉意地笑了笑：“在所有编程范式中，函数式与逻辑式与传统思维方式的差别最大，此前的介绍又过于简单，因此今天特意多谈了些。既然有人提意见，那就我就适可而止了。最后请允许我画蛇添足：在代表计算机最高水平的人工智能领域中，这两种范式发挥着举足轻重的作用。单凭这一点，它们也是值得学习和借鉴的。好了，大家先休息十分钟，出去活动活动筋骨吧。”

众人落座之后，冒号鸣锣开场：“上两节课为大家介绍了多种编程范式，虽未将所有类型尽囊其中，但最具代表性的均在其列。我们也不必贪多求全，俗话说得好：贪多嚼不烂啊。现在给大家一个知识反刍的机会。”

问号正感求之不得：“总算可以喘口气了。我们就像观光客，被导游带着从一个景点赶往另一景点。一天下来，虽然大开眼界，但都是走马观花，无法充分领略各地的风光。”

“你说得没错，我就是那个不近情理的导游。”冒号哈哈一笑，“类似时下流行的欧洲N国M日游，大部分人的收获就是一堆照片和日渐模糊的记忆。不出多日，如果不看标注，八成连照片上的背景是在法国还是在意大利都分不清了。”

逗号颇有同感：“差不多，目前我的收获就是一堆幻灯片和似懂非懂的概念。”

冒号料有此果：“这一点也不奇怪。别说几天游一个国家，单一个罗马，没有一个月是不可能深入了解的。至于编程范式，单一个OOP，没有两年以上的实践和思考，是难以真正领会其精髓的。”

叹号深表怀疑：“OOP需要两年以上才能领会？！”

“那还得看你是否有足够的勤奋和悟性。”冒号加强了语气，“前面说过，单靠记忆只能触及知识之表，单靠练习只能深入知识之里，唯有培养方能渗透知识之根。编程范式正处知识的根部，你们又怎能奢望只听几堂课即豁然贯通呢？”

引号表达自己的感受：“虽然学了不少东西，但也存了不少疑惑，搁在心里有点不舒服。”

“我明白你的意思。凡事追根究底是一种良好的学习习惯，也是一种可贵的学习精神。” 冒号表示理解和肯定，“但学习如打仗，除了要有直线式的纵深攻击，还要有曲线式的迂回包抄。回顾我们中学的课堂，往往是每引入一个概念或理论，便围绕其作深入的学习和反复的练习。在此过程中的种种疑惑，随着学习的深入都会烟消云散。这样稳扎稳打、层层推进，学得扎实，心里也踏实。但这种方法并不总是最好的，尤其在面临动态的、开放的知识体系时，难免左支右绌。为此，我们必须学会适度地容忍无知。请注意，容忍无知不是放任无知，而是一种学习的技巧，让无知成为求知的动力而不是障碍。容忍无知能使我们既不沮丧气馁，也不急于求成。在学习时不妨略过一些细节或难点，先概览全貌以获取感性认识，然后在逐步积累中升华为理性认识。要而言之，我们不仅需要强调钻劲和深度的‘钉子精神’，还需要强调磨功和广度的‘刨子精神’。我一口气兜售这么多编程范式，就是为了刺激大家求知欲，同时为大家进行第一道刨磨。”

引号得到一些安慰：“看来今后我们还会故地重游的。”

“不仅会重游，而且会‘深度游’。” 冒号肯定地说，“此番我们一路行色匆匆，若能感受到途中景色带来的感官冲击，便算是不枉此行了。其实，把编程范式类比旅游景点并不十分准确，或许比作当地的风俗文化更确切些。”

句号立刻会意：“景点是具体的，背后的风俗文化是抽象的；编程语言是具体的，背后的编程范式是抽象的。”

“此乃其一。”冒号右手伸出食指，“其二，如果不了解景点的历史文化和风俗人情，仅仅满足于表面的奇观异景，一切很快便会淡忘。比如说，你若不了解圣经文化、不了解文艺复兴史，则欧洲之行至多只是视觉的盛宴，而非文化的洗礼，收获将是有限的，印象将是肤浅的。同样，如果你不了解编程范式，那么眼中的编程语言只是语法、语义、核心库、规范等组成的集合，写出的代码虽能编译、能工作，却会显得生硬、别扭。就像中式英语，语法正确、表达也正确，可就是不正宗、不地道。其症结我们在第一节课中已经提过了，即所谓的语感缺失。”

问号实话实说：“可我还是不明白编程范式如何提高我们的编程语感。”

“那就让我们再说说范式吧。”冒号并不着急，“范式可以粗略理解为模范、模型、模式、风格、流派等等。软件中的范式除了编程范式外，还有架构范式^[1]、数据库范式^[2]等。比如，对象导向式（Object-Oriented）可以应用于编程、架构和数据库中，分别成为OOP（Object-Oriented Programming）、OOA（Object-Oriented Architecture）和OODB（object-oriented database）；类似地，事件驱动式（Event-Driven）可以是一种编程范式，可以是一种架构模型，也可以是一种设计模式。总之，每种范式都代表着一套独特而有效的解决问题的思想和方法。掌握范式对编程语感的提高至少有两层作用：首先，编程语言的语法、语义等都是从编程范式的树根衍生而出的枝叶，把握了这种脉络和节奏，代码才会如音乐舞蹈般韵律有致；其次，每种范式擅长的问题领域不尽相同，只有博闻广识，方可扬长避短，程序才会如行云流水般流畅自然。”

逗号添油加醋：“武功练至化境，一定是博采众长，就像杨过融合了东邪、西毒、南帝、北丐、中神通等各派武功，才能随心所欲地打出黯然销魂掌来。”

提起武侠人物，众人俱是逸兴遄飞，哪能体会到半点黯然消魂之伤？

冒号道：“天下之理，殊途同归。我们停止玄玄之论，用实例来说明吧。谁来介绍一下快速排序法（quicksort）？”

众人飞舞的思绪渐渐收敛，终于由引号作答：“快速排序法的思想是：在列表中找一个基准元素，将所有小于它的元素划归一个子列，置于其前；将所有大于等于它的元素划归另一子列，置于其后。然后递归地对前后两个子列作同样处理，直至最终。”

“很好，让我们用Java来实现一下该算法。”冒号显示出一段代码——

/** 快速排序法的Java实现 */
public class Sorter
{
    public static <T extends Comparable<? super T>> void qsort(T[] list)
    {
        qsort(list, 0, list.length - 1);
    }

    private static <T extends Comparable<? super T>> void qsort(T[] list, int low, int high)
    {
        if (low >= high) return;

        int i = low - 1, j = high + 1;
        T pivot = list[low]; // 基准元素

        for ( ; ; )
        {
            do { ++i; } while (list[i].compareTo(pivot) < 0);
            do { --j; } while (list[j].compareTo(pivot) > 0);

            if (i >= j) break;

            // 交换
            T tmp = list[i]; list[i] = list[j]; list[j] = tmp;
        }

        // 找到分割点j，递归
        qsort(list, low, j);
        qsort(list, j + 1, high);
    }
}

“请问这里用到了哪些编程范式？”冒号提问。

叹号心想，有何难哉？遂答：“既然是用Java实现的，自然少不了OOP。同时为了使算法更具普适性，还用到了泛型编程。”

“你好像忘记了最重要的过程式，反倒是OOP的色彩极淡。”冒号显然不满意他的答案。

叹号不解：“不是说Java是100%的OOP语言吗？”

冒号颇为不屑：“不要轻信这种浮浅之论。且不说Java的基本类型（primitive type）不属于类（class），本就不是100%的OOP，即使是100%的OOP，那与过程式也不矛盾啊。此例中的Sorter类连一个实例成员（instance member）也没有，唯一与OOP沾边的是作为interface的Comparable，在C中也可用函数指针代替。如果不考虑泛型式的特征，本例无论用Java还是用C，并没有本质差别。事实上，对于这类纯算法的问题，OOP范式本无太多用武之地。换句话说，quicksort虽然是通过以OOP著称的Java来实现的，但用的主要还是过程式的思想和方法。”

问号赶紧问道：“还能用其他范式来实现吗？”

此问正合冒号之意：“我们改用纯函数式语言Haskell来试试——”

-- 快速排序法的Haskell实现 
qsort :: (Ord a) => [a] -> [a]  --函数声明
qsort[] = []                    --递归终点 
qsort(pivot : rest) = qsort[x| x <- rest, x < pivot]         --对前面的子列递归
                          ++ [pivot]
                          ++ qsort[x| x <- rest, x >= pivot] --对后面的子列递归

叹号几不能信：“竟然可以如此精炼？”

“上面的Java代码很难再精简了，但与Haskell代码相比还是太冗长了。后者省去了所有的赋值、迭代和流程控制，只有单纯的递归，反映了典型的函数式特征。”冒号解说着，“鉴于你们对Haskell不太熟悉，我稍微解释一下。第一步，声明函数类型^[3]：同类型列表之间的变换，其中Ord可类比Java中的Comparable，以保证列表元素之间能进行比较；第二步，声明递归终点：空列排序后仍是空列；第三步，描述递归原则：基准元素pivot与剩余子列rest进行排序后的列表，正是将小于基准的子列和超过基准的子列分别排序，中间插入基准元素后的结果。”

句号思有所得，不禁喜形于色：“我明白了，这两段代码生动地反映了命令式编程与声明式编程之间的差别：前者需要指定计算的过程，后者只需指定计算的原则。一个着重微观的细节，一个着重宏观的方向，自有繁简之别。”

冒号亦有所慰：“非常好！类似的话我以前也说过，但你们自己说的才是真正的收获啊。我们还提过，过程式与函数式的差别同时也是机器思维与数学思维的差别。不妨对比Haskell表达式与数学中的集合表达式，它们是多么地相近！”

黑板上出现两行式子——

数学表达式：   {x| x ∈ rest, x < pivot} 
Haskell表达式：[x| x <- rest, x < pivot] 

逗号仔细打量着：“嗯，的确像，跟哥俩似的，连符号<-都是仿照集合属于符（∈）的。”

“还有另一种表达方法。”冒号又添加了一行——

Haskell表达式2 ：(filter (< pivot) rest) 

“虽然与前一表达式的简洁度相差无几，但可读性更强。filter即是过滤，将列表rest中的元素进行筛选，条件是小于基准元素。”冒号讲解道。

问号略感迷惑：“（< pivot）的用法看起来有点怪异。”

“它是一个函数，也是filter的第一个参数，用来判断第二个参数rest的元素是否合格，即 < pivot。这体现了函数式的一个重要特征：函数是头等公民（first-class citizen）——可作为传递参数、可作为表达式的值、可嵌入数据结构、也可与某变量绑定，与普通的基本数据类型毫无二致。这类函数更数学化的叫法是高阶函数（higher-order function），它是函数式编程简洁而强大的重要根源。”冒号细加解释，“大家还记得上节课谈到的回调函数吧？callback无非是将函数作为参数来传递，本质上是将代码当数据来使用，回调机制的巨大威力均拜此高级用法所赐。”

众人又一段经脉被打通了。

引号提出一个很实际的问题：“函数式编程的确很酷，可Java并不支持。如果采用Haskell之类的函数式语言，会不会带来系统集成上的困难？”

冒号打消了他的疑虑：“Java平台下已经集成了不少的支持函数式编程的语言，如JRuby、Jython、Groovy、Scala等，甚至Haskell在JVM下也有相应的Jaskell。其中，Groovy与Java的结合最为自然。此外，C#3.0引入了lambda表达式，也能方便地支持函数式。我们看一下它们是如何实现quicksort的——”

/** 快速排序法的Groovy实现 */
def qsort(list) {
    if (list.size() <= 1) return list

    def pivot = list[0]
    return (qsort(list.findAll{x -> x < pivot})
          +             list.findAll{x -> x == pivot}
          +    qsort(list.findAll{x -> x > pivot}))
} 

/** 快速排序法的C#3.0实现 */
IEnumerable<T> qsort<T>(IEnumerable<T> list) where T : IComparable<T>
{
    if (list.Count() <= 1) return list;

    var pivot = list.First();
    return qsort(list.Where(x => x.CompareTo(pivot) < 0))
                .Concat(list.Where(x => x.CompareTo(pivot) == 0))
                .Concat(qsort(list.Where(x => x.CompareTo(pivot) > 0)));
} 

“以上两种方法如出一辙，虽然比Haskell的代码略长了些，并且还带着过程式的烙印，但总体思想还是函数式的。”冒号紧扣本质，“函数式还有一个重要特征：无副作用或尽量减少副作用^[4]。所谓无副作用，是指一个函数在被调用前后保持程序的状态不变。无副作用的函数不会改变非局部变量的值，不会改变传入的参数，也没有I/O操作。”

逗号脱口而出：“什么状态都不变，那这样的函数有什么用？”

冒号不以为奇：“你的这种想法源自根深蒂固的命令式思维。我们曾把命令式程序比作状态自动机，其运行过程就是在不断地修改机器的状态。而函数式程序则是进行表达式变换，一般不会改变变量的值。其实函数式并非完全不改变内存，只不过改变的是栈内存（stack）罢了。换言之，无副作用函数的作用关键在于其估值结果，按过程式的说法是返回值。刚才的quicksort不正是如此吗？”

逗号如梦初醒。

冒号旋即补充：“当然，在涉及流程控制、顺序操作、状态维护、I/O运算等问题时，没有副作用是很不方便的。函数式语言一般也会提供变通的方式，比如Haskell、Ruby、Python、Scala等语言支持的monad便是这样一种机制。”

问号仍有疑问：“药物最好没有副作用，函数没有副作用的好处是什么？”

冒号嘴一咧：“好处太多了。首先，没有副作用的函数易于重构、调试和单元测试。其次，代码有效性与函数顺序无关，方便并发处理和优化处理。举个简单的例子，计算两个函数的乘积：f(x) * g(y)。由于无副作用，f(x) 和g(y)的估值过程是独立的，估值顺序也不重要，因此理论上可以对二者并行计算。另外，还可利用惰性求值（lazy evaluation）^[5]：如果算出f(x)为零，那么不用计算g(y)便可知乘积为零了。”

叹号忍不住赞叹：“听起来真不错！”

冒号突然扭头写下一行字，然后提问：“请问这个unix命令表示什么意思？”

grep the BigFile.txt | head 

引号回答：“这是要打印出文件BigFile.txt中包含字符串‘the’的十行文字。”

冒号点头：“没错，这是unix管道（pipe）的用法。它由两个命令组成：grep和head，前者的输出是后者的输入。一个有趣的事实是，后者不用等到前者执行完毕才启动。更有趣的是，只要后者获取了足够的数据，前者便会停止执行。故而当grep在给定文件中找到含有给定字符串的十行文字后，即可功成身退，因为那已是head的全部所需。假如没有管道机制，那就只能这样——”

grep the BigFile.txt > tmpfile; head tmpfile 

“这样不仅产生了多余的临时文件，而且效率大大降低。这与惰性求值有关吗？”句号隐隐明白了冒号的用意。

“类似地，通常要计算f(g(x))的值，需要计算完g(x)后才能将所得值代入函数f。有了惰性求值机制，g(x)的计算完全由函数f的需求来驱动，避免做无用功。此乃其惰性之所在。”

逗号挑起大拇指：“这个懒偷得真聪明！”

“惰性求值不仅能节省有限的时间，还能超越无限的时间——g(x)甚至可以永不退出，从而可能产生无穷的输出结果集供函数f使用。这可是在过程式编程中想都不敢想的事啊。”冒号言犹未尽，“最后，没有副作用的函数是引用透明的（referential transparency），即一个表达式随时可以用它的值来替换^[6]，正如数学中的函数一样，保证了数学思维的贯彻和运用。”

引号自感获益颇丰：“前面介绍范式时，觉得函数式最为神秘。现在总算有了些感性认识了。”

冒号道出缘由：“函数式编程不仅有许多独特的概念和方法，还有很深的数学背景——λ-演算（lambda calculus）。如果一开始便倾囊相授，你们必会望而却步，我岂不是打草惊蛇了？”

众人始觉：老冒狡猾狡猾的，原来在诱敌深入啊。

“尽管函数式有这么多优点，运算能力从理论上比诸过程式也毫不逊色^[7]，但一直没有成为主流范式。”冒号话锋一转，“细究之，至少有两方面的原因：主观上，程序员更习惯机器风格的过程式思维和现实风格的OOP思维，不容易接纳数学风格的函数式思维；客观上，函数式语言在表现力和运行效率^[8]等方面与过程式和OOP语言也有一定的差距。饶是如此，支持它的语言还是越来越多，其简洁精巧的特性也为越来越多的人所青睐。它的整体应用虽然主要集中于数学计算、人工智能等领域，但局部应用早已遍地开花了。”

逗号渐觉睡虫上脑，开始闭目点头。正神游之际，忽觉腰间一阵酥麻。惺眼微睁，原是被引号的胳膊肘给捅的，顿时警醒。抬头见讲台上的老冒正目光灼灼地盯着自己，不禁脸颊微烫，嗫嚅道：“不好意思，昨晚睡得太晚了。”

冒号却不以为意：“正愁找不到新话题呢，你倒启发我了。话说课堂上睡觉大抵有三种方式——”

话音未落，有人已笑不自禁。

“第一种是警觉式：想睡可又担心被老师发现，不时睁眼查看周围的变化。同时双耳保持警戒，一有异动立刻挺直身板。”冒号有板有眼地形容，“第二种是宽心式：俯桌酣睡，如处无人之境。境界至高者或可雷打不动，或可鼾声如雷。”

“总之是很雷人。”叹号的网络新语再度引发笑声。

冒号继续分析：“第三种是托付式：请人放哨，非急勿扰。遂再无顾忌，大可封目垂耳，安心入眠。请问你们乐意采用哪种方式？”

“第一种方式睡不踏实，不得已而为之。敢用第二种方式的人多半没心没肺，估计IT人都达不到那种境界。只要有同伴在身旁，我想大家都会选第三种方式的。”句号的回答获得一致认同。

冒号续问：“好，抛开第二种方式不谈，为什么第三种要比第一种优越呢？”

句号回答：“犯困者既要打盹又要警戒，必然苦不堪言。如果把警戒的任务委托同伴，两人分工合作，自然愉快得多。”

冒号再问：“他们是如何合作的呢？”

“放哨者一旦发现有情况，立即通知犯困者采取行动——睁眼坐直，作认真听讲状。”句号说得是绘声绘色。

除了两位当事人略显尴尬外，其他人均乐不可支。

眼见时机成熟，冒号不再兜圈：“采用警觉式者主动去轮询（polling），行为取决于自身的观察判断，是流程驱动的，符合常规的流程驱动式编程（Flow-Driven Programming）的模式。采用托付式者被动等通知（notification），行为取决于外来的突发事件，是事件驱动的，符合事件驱动式编程（Event-Driven　Programming，简称EDP）的模式。下面我们就来说说这种编程范式。”

逗号瓮声瓮气道：“没想到打瞌睡打出了个范式。”

冒号瞥了他一眼，继续说下去：“为完成一样事，既可以采用流程驱动式，也可以采用事件驱动式。这样的例子在生活中可谓俯拾即是，刚才逗号同学为大家现场示范了一个，谁还能举出其他范例？”

叹号抢先举例：“与客户打交道，推销员主动打电话或登门拜访，他的工作是流程驱动的；接线员坐等电话，他的工作是事件驱动的。”

问号也说：“同样是交通工具，公共汽车主要是流程驱动的，它的路线已预先设定；出租车主要是事件驱动的，它的路线基本上由随机搭载的乘客所决定。”

引号以个人经验作例：“购买喜爱的杂志可以选择频繁光顾报刊亭，也可以选择一次性订阅。浏览关注的新闻网站或博客，可以直接访问站点，也可以订阅相应的RSS。主动检查所关心的内容是否更新是流程驱动的，用订阅的方式是事件驱动的。”

句号回到本行：“Windows下的许多工作既可以在DOS下用批处理程序实现，也可以在图形界面下完成。前者不需人工干预，显然是流程驱动的；后者毫无疑问是事件驱动的。”

“看来你们对这种范式很熟悉嘛。不过，它原理虽简单，威力却无穷。看似一招，实则暗藏百式，甚可幻化千招。个中精妙之处，断非一时可以尽述。”冒号不知不觉中又走进了武侠的世界。

众人听了，暗疑老冒有些言过其实。

冒号正式入题：“首当其冲的问题是：何谓事件？通俗地说，它是已经发生的某种令人关注的事情。在软件中，它一般表现为一个程序的某些信息状态上的变化。基于事件驱动的系统一般提供两类的内建事件（built-in event）：一类是底层事件（low-level event）或称原生事件（native event），在用户图形界面（GUI）系统中这类事件直接由鼠标、键盘等硬件设备触发；一类是语义事件（semantic event），一般代表用户的行为逻辑，是若干底层事件的组合。比如鼠标拖放（drag-and-drop）多表示移动被拖放的对象，由鼠标按下、鼠标移动和鼠标释放三个底层事件组成。”

问号推想：“编程人员应该还能创造新的事件类型吧？”

“那是当然。”冒号点点头，“还有一类用户自定义事件（user-defined event）。它们可以是在原有的内建事件的基础上进行的包装，也可以是纯粹的虚拟事件（virtual event）。除此之外，编程者不但能定义事件，还能产生事件。虽然大部分事件是由外界激发的自然事件（natural event），但有时程序员需要主动激发一些事件，比如模拟用户鼠标点击或键盘输入等，这类事件被称为合成事件（synthetic event）^[1]。这些都进一步丰富完善了事件体系和事件机制，使得事件驱动式编程更具渗透性。”

叹号嘟哝了一句：“看来这里边还有点名堂。”

“名堂多着呢！”冒号回应，“事件固然是事件驱动式编程的核心概念，但一个编程范式的独特之处绝不仅仅是一些概念，更重要的是建立于这些概念之上的思维模式。为了了解这种范式与众不同的特点，我们先看看如何利用win32的API在windows下创建一个简单的窗口——”

/** 一个win32窗口程序 */
…WinMain(...) // windows应用程序的主函数
{
    // 第一步——注册窗口类别
    ...;
    windowClass.lpfnWndProc = WndProc; // 指定该类窗口的回调函数
    windowClass.lpszClassName = windowClassName; // 指定该类窗口的名字
    RegisterClassEx(&windowClass);

    //第二步——创建一个上述类别的窗口
    CreateWindowEx(…, windowClassName, ...);
    …;

    //  第三步——消息循环
    while (GetMessage(&msg, NULL, 0, 0)  > 0) // 获取消息
    {
        TranslateMessage(&msg); // 翻译键盘消息
        DispatchMessage(&msg);  // 分派消息
    }
}

// 第四步——窗口过程（处理消息）
…WndProc(…, msg,...)
{
    switch (msg)
    {
        case WM_SIZE:   …;   // 用户改变窗口尺寸
        case WM_MOVE: …; // 用户移动窗口
        case WM_CLOSE: …; // 用户关闭窗口
        …;
    }
}

“没有选用Java、Visual C++、C#、VB或者Delphi来实现窗口，是因为它们高度的封装和强大的IDE掩盖了部分事件机制。如果你们对win32 API不太熟悉，没有关系。为了减少语言和API上的障碍，同时突出重点，这里最大限度地省略了次要的过程和参数等，仅保留脉络主干。”冒号解释，“从中看出到，创建一个能响应用户操作的win32窗口共分四步：注册窗口类别、创建窗口、消息循环和窗口过程。”

问号对概念很敏感：“消息与事件是一回事吗？”

“严格说来它们不是一回事，但如果你不想深究，不加区分也无大碍。概略地说，消息是Windows内部最基本的通讯方式，事件需要通过消息来传递，是消息的主要来源。每当用户触发一个事件，如移动鼠标或敲击键盘，系统都会将其转化为消息并放入相应程序的消息队列（message queue）中^[2]。”冒号解答着，“明白了这一点，上面的代码就不难理解了——在消息循环中，程序通过GetMessage不断地从消息队列中获取消息，经过TranslateMessage预处理后再通过DispatchMessage将消息送交窗口过程WndProc处理。”

逗号琢磨了一会，不解地问：“窗口过程应该是在分派消息时被调用的，但我怎么想不出DispatchMessage是如何联系到WndProc的？”

冒号为其解惑：“DispatchMessage的消息参数含有事发窗口的句柄（handle），从而可以得到窗口过程WndProc^[3]。至于窗口与窗口过程之间是如何建立联系的，回看前面两步就一目了然了：当初在创建窗口时指明了窗口类别名windowClassName，而窗口类别windowClass又绑定了窗口过程。”

叹号有点纳闷：“干嘛要绕这么大的弯子，直接调用WndProc不就得了？”

“对于这个简单的程序来说，的确区别不大。但假如再增添其他菜单、按钮、文本框之类的控件，每个控件都可绑定自己的窗口过程，那么到底该调用哪个才对呢？”冒号反问。

叹号虽有所悟，但仍有心结：“总觉得窗口过程的用法有些怪怪的。”

冒号一敲桌案：“没错！怪就怪在编程者自己写了一个应用层的函数，却不直接调用它，而是通过库函数间接调用。这类函数有个专用名称：回调函数（callback）。”

引号忍不住插话：“回调函数我知道，在C和C++中就是函数指针嘛。”

“确切地说，函数指针是C和C++用来实现callback的一种方式。此外，抽象类（abstract class）、接口（interface）、C++中的泛型函子（generic functor）和C#中的委托（delegate）都可实现callback。我们先图解一下回调机制。”冒号调出一张图示——

图3-4. 普通函数与回调函数的对比

“如果我们把系统划分为两层^[4]：低层的函数库和高层的应用程序。同样作为主函数的辅助函数，左图中的普通函数直接被主函数调用，然而右图中的回调函数却是通过库函数间接被主函数调用的。”冒号的手影在幻灯下上下翻飞。

句号点出要害：“一般都是高层代码调用低层代码，callback反其道而行之，因此显得与众不同。”

“所言极是。一方面，在软件模块分层中，低层模块为高层模块提供服务，并且不能依赖高层模块，以保证其可重用性；另一方面，通常被调者（callee）为调用者（caller）提供服务，调用者依赖被调者。两相结合，决定了低层模块多为被调者，高层模块多为调用者。但这种惯例并不总是合适的——低层模块为了追求更强的普适性和可扩展性，有时也有调用高层模块的需求，于是便邀callback前来相助。我们看一个简单的例子。”冒号写下一段Java代码——

String[] strings = {"Please", "sort", "the", "strings", "in", "REVERSE", "order"};
Arrays.sort(strings, new Comparator<String>() {
    public int compare(String a, String b){ return -a.compareToIgnoreCase(b); }
    });

引号很快读懂了代码：“这是将字符串组不区分大小写地逆序排列。其中Comparator的匿名类实现了callback，因为它的方法compare是在类库中被调用的。”

“此处callback的好处是显而易见的——它使得Arrays.sort不再局限于自然排序，允许用户自行定制排序规则，大大提高了算法的重用性。”冒号说着将幻灯片又翻到前页，“回头再看win32窗口程序的例子，其中第三步消息循环那段代码不依赖应用程序代码，完全可以提炼出来作为library的一部分。事实上，在Visual C++里这段代码就‘下放’到MFC类库中去了。假设窗口过程由应用程序直接调用，那么消息循环中的代码将不再具有独立性，无法作为公因子分解出来。”

叹号块垒顿消，畅然无比：“终于搞清那个怪异的窗口过程了！每个窗口在创建时就携带了一个callback，以后每当系统侦查到事件，都能轻易地从事发窗口身上找到它的callback，然后调用它以响应事件。”

“这等于将侦查事件与响应事件两项任务进行了正交分解，降低了软件的耦合度和复杂度。”句号言犹未尽，又加了一句，“就像刚才，引号负责侦查事件——警戒，逗号负责响应事件——警醒。想法很好，可惜配合不够默契，还是给人逮住了。”

逗、引二人大窘，余者大笑。

“仔细比较，以上两个callback的用法还是稍有不同的。在字符串组排序中，callback在作为参数传入低层的函数后，很快就在该函数体中被调用；在窗口程序中，callback则先被储存起来，至于何时被调用完全是未定之数。用一句话概括：前者属同步（synchronous）回调，后者属异步（asynchronous）回调。它们都使调用者不再依赖被调者，将二者从代码上解耦，异步调用更将二者从时间上解耦。”冒号显示出一副新图——

图3-5. 异步回调

“图中处于低层的软件平台是在win32 API的基础上的改进。不仅把主循环从应用程序中沉淀下来，而且将储存callback的过程封装在一个注册函数中，使得应用程序代码变得更简洁、健壮。同时我们看到，整个流程的控制权已经从应用程序的主程序转移到底层平台的主循环中，符合好莱坞原则。”冒号。

逗号好奇地问：“什么是好莱坞原则？”

“don’t call us, we’ll call you.”冒号难得甩出一句洋文，“我很想画蛇添足地在末尾加上单词‘back’，这样更容易理解callback的含义：‘call you back’。此话的背景大约是这样的：一个艺人要想演出，需与好莱坞的经纪公司联系。由于幻想一朝成名的人太多，经纪人总是牛气十足，他们的口头禅是：‘别打电话给我们，留下你的电话，有活干我们会打给你的’。”

引号认真地解析：“好莱坞经纪公司相当于一个背后运作的软件平台，艺人相当于一个callback，‘留下你的电话’就是注册callback，‘我们会打给你的’就是异步调用callback。”

冒号接着补充：“‘别打电话给我们’意味着经纪公司处于主导地位，艺人们处于受控状态，这便是控制反转（Inversion of Control，简称IoC）。”

问号听着耳熟：“控制反转？第一课谈到框架时似乎提到过。”

“没错，正是它！”冒号谈兴愈浓，“一般library中用到callback只是局部的控制反转，而framework将IoC机制用到全局。程序员牺牲了对应用程序流程的主导权，换来的是更简洁的代码和更高的生产效率。如果将编程譬比命题作文，不用framework的程序是一张可以自由写作的白纸，library是作文素材库；采用framework的程序是一篇成型的作文，作者只需填写空白的词语和段落即可。”

叹号为之一叹：“唉，编程序变成了做填空题，真没劲！ ”

“那你就多努力，争取以后出填空题吧。”冒号笑着鼓励他，“控制反转不仅增强了framework在代码和设计上的重用性，还极大地提高了framework的可扩展性。这是因为framework的内部运转机制虽是封闭的，但也开放了不少与外部相连的扩展接口点，类似插件（plugin）体系。如下图所示——”

图3-6. 框架的IoC机制

引号联想到另一个名词：“我知道有个依赖反转，与控制反转是一回事吗？”

冒号简答：“虽然不少人把它们看成同义词，但依赖反转原则（Dependency-Inversion Principle，简称DIP）更加具体——高层模块不应依赖低层模块，它们都应依赖抽象；抽象不应依赖细节，细节应依赖抽象。经常相提并论的还有依赖注射（Dependency Injection，简称DI）——动态地为一个软件组件提供外部依赖。由于时间关系，它们之间的区别容后再叙。有一点可以看出，它们的主题是控制与依赖，目的是解耦，方法是反转，而实现这一切的关键是抽象接口。”

“为什么说是抽象接口而不是前面所说的回调函数？”打过瞌睡的逗号现在似乎变得特别清醒。

冒号予以说明：“回调函数的提法较为古老，多出现于过程式编程，抽象接口是更现代、更OO的说法。另外从字面上看，‘回调’强调的是行为方式——低层反调高层，而‘抽象接口’强调的是实现方式——正是由于接口具有抽象性，低层才能在调用它时无需虑及高层的具体细节，从而实现控制反转。”

众人细细品味着冒号的这番话。

问号忽然惊觉：“我们是不是跑题了？本来是谈事件驱动式编程的，结果从callback谈到控制反转，再到框架，现在又说起了抽象接口。”

“事物是普遍联系的嘛。”冒号扯了句哲学套话，“不谙熟callback和IoC机制，就不可能真正领会事件驱动式编程的精髓。不过，也该回到中心主题了。我们通过win32 API用四步实现了一个简单的窗口程序，与事件直接相关的有三步：实现事件处理器（event handler）或事件监听器（event listener）；注册事件处理器；实现事件循环（event loop）。具体上，事件处理器负责处理事件，经注册方能在事发时收到通知；事件循环负责侦查事件、预处理事件、管理事件队列和分派事件等，无事时默默等待，有事时立即响应，生命不息工作不止。在整个事件机制中，主循环好比心脏，事件处理器好比大脑，是最重要的两类模块。”

句号指出：“在支持事件驱动的开发环境中，主循环是现成的。许多IDE的图形编辑器在程序员点击控件后，还能自动生成事件处理器的骨架代码，连注册的步骤也免除了。”

冒号提醒他：“并不是总有这样的好事，要知道事件驱动式并不局限于GUI应用，支持事件驱动的开发环境也未必唾手可得。程序员有时必须自行设计整个事件系统，他需要决定：采用事件驱动式是否合适？如果合适，如何设计事件机制？其中包括事件定义、事件触发、事件侦查、事件转化、事件合并、事件调度、事件传播、事件处理、事件连带（event cascade）^[5]等等一系列问题。”

逗号扮着苦相说：“我的脑袋就是一个事件监听器，在听到要面临这么多的事件后，迅速作出反应——大了一圈。”

众皆弯腰捧腹。

“脑袋能变大是件好事啊，说明它伸缩性强，相信用它来编的程序也是一样。”冒号打着哈哈，“事件驱动式的程序可伸缩性就很强，知道为什么吗？”

叹号随口说道：“不是因为利用回调函数实现了控制反转吗？”

“非也非也。”冒号文绉绉地说，“软件的可伸缩性（scalability）一般指从容应对工作量增长的能力，常与性能（performance）等指标一并被考量。而控制反转的主要作用是降低模块之间的依赖性，从而降低模块的耦合度和复杂度，提高软件的可重用性、柔韧性和可扩展性，但对可伸缩性并无太大帮助。我们已经看到，控制反转导致了事件驱动式编程的被动性（passivity）。此外，事件驱动式还具有异步性（asynchrony）的特征，这是由事件的不可预测性与随机性决定的。如果一个应用中存在一些该类特质的因素，比如频繁出现堵塞呼叫（blocking call），不妨考虑将其包装为事件。”

问号打岔道：“什么是堵塞呼叫？”

冒号作了个比方：“在高速公路上一辆车突然出故障停在路途，急调维修人员。如果现场修理，在修好之前所在车道是堵塞的，后面车辆无法通行。类似地，在程序中一些函数需要等待某些数据而不能立即返回^[6]，从而堵塞整个进程。”

引号道出常识：“显然更可取的修车做法是：先把车拖到路边，修完后向其他车辆发出信号，以便重回车道。”

冒号趁热打铁：“同理，我们可以让堵塞呼叫暂时脱离主进程，事成之后再利用事件机制申请重返原进程。相比第一种同步流程式的方案，这种异步事件式将连续的进程中独立且耗时的部分抽取出来，从而减少随机因素造成的资源浪费，提高系统的性能和可伸缩性。”

问号听得仔细：“为什么抽取的部分是‘独立且耗时’，而不是‘随机且耗时’？”

“问得好！”冒号很欣赏他严谨的学风，“再拿修车来说，第二种方案之所以可行有两方面原因：一是修车耗时，二是修车独立。所谓独立又有两层含义：与车道独立——修车时不必占用车道；与后车独立——后面车辆不必恭候该车。如果一分钟内能修好，或者路边没有足够空位，再或者后面车辆是故障车的随行车，那么拖车方案均不成立。大家可以自己类比堵塞呼叫的情形，我就不再饶舌了。总之，独立是异步的前提，耗时是异步的理由。至于随机嘛，只是副产品，一个独立且耗时的子过程，通常结束时间也是不可预期的。”

眼见天色已晚，冒号赶忙换上最后一页幻灯片——

图3-7. 事件驱动式模型

“上图为一个典型的事件驱动式模型。事件处理器事先在关注的事件源上注册，后者不定期地发表事件对象，经过事件管理器的转化（translate）、合并（coalesce）、排队（enqueue）、分派（dispatch）等集中处理后，事件处理器接收到事件并对其进行相应处理。请注意事件处理器随时可以注册或注销事件源，意味着二者之间的关系是动态建立和解除的。”冒号在幻灯屏上指指点点，“通过事件机制，事件源与事件处理器之间建立了松耦合的多对多关系：一个事件源可以有多个处理器，一个处理器可以监听多个事件源。再换个角度，把事件处理器视为服务方，事件源视为客户方，便是一个client-server模式。每个服务方与其客户方之间的会话（session）是异步的，即在处理完一个客户的请求后不必等待下一请求，随时可切换（switch）到对其他客户的服务。更有甚者，事件处理器也能产生事件，实现处理器接口的事件源也能处理事件，它们可以角色换位，于是又演化为peer-to-peer模式。”

叹号抱怨：“有点眼花缭乱了。”

为湿润枯燥的理论，冒号再次举例：“你们不是很喜欢在QQ上聊天吗？QQ服务器是事件管理器，每个聊天者既是事件源又是事件处理器，这正是事件驱动式的P2P模式啊^[7]。此外，聊天时不等对方回答，就可与另一网友交谈，这就是会话切换带来的异步效果。不过同样是聊天，改用电话就稍有不同了。”

冒号扫了 众人一眼，果见有人皱起了眉头。

“当你正用座机通话时，手机响了。你会怎么做？”冒号提示。

逗号本能地回答：“要么挂掉电话再接手机，要么让打手机的人迟些打来。”

句号听出了门道：“这说明电话的通话过程是同步而非异步的，原因是打电话双方的交流是连贯的、非堵塞式的（non-blocking），与QQ聊天正好相反。”

冒号点头称许。

虽然早已过了下课时间，引号仍是好学不倦：“我觉得观察者模式与事件驱动式很像啊。”

“你开始不是还举了订阅杂志和RSS的例子吗？发行/订阅模式（publish-subscribe pattern）^[8]正是观察者模式（observer pattern）的别名，一方面可看作简化或退化的事件驱动式，另一方面可看作事件驱动式的核心思想。该模式省略了事件管理器部分，由事件源直接调用事件处理器的接口。这样更加简明易用，但威力有所削弱，缺少事件管理、事件连带等机制。著名的MVC（Model-View-Controller）架构正是它在架构设计上的一个应用^[9]。”冒号长舒了一口气，准备收工，“事件驱动式的应用极广，变化极多，还涉及到框架、设计模式、架构、以及其他的编程范式，本身也可作为一种架构模型。今天我们仅仅是蜻蜓点水，更深入更具体的内容只能留后探讨了。时候不早，你们也该饿了，赶快回家吧！范式可不能当饭吃哦。”

众人笑作鸟兽散。