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

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

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

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

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

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

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

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

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

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

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

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

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

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

众人窃笑。

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

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

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

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

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

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

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

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

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

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

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

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

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

众人鼓掌。

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

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

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

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

逗号坚持道：“我还是那个建议，希望学些具体的编程知识和技巧，比如将最流行的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]。”冒号长舒了一口气，准备收工，“事件驱动式的应用极广，变化极多，还涉及到框架、设计模式、架构、以及其他的编程范式，本身也可作为一种架构模型。今天我们仅仅是蜻蜓点水，更深入更具体的内容只能留后探讨了。时候不早，你们也该饿了，赶快回家吧！范式可不能当饭吃哦。”

众人笑作鸟兽散。

课间休息刚一结束，引号便重开话题：“OOP方兴未艾，AOP又开始崭露头角。AOP算是OOP的一种补充、一种分支还是一种超越？”

叹号故作捶胸顿足状：“OOP还没有完全吃透，又来了个什么AOP。”

“不同的人对新生事物采取不同的态度。”冒号王顾左右而言他，“追星族倾向于盲目追捧，唯恐落伍，他们信奉新潮的、流行的就是好的；守旧派倾向于本能抗拒，回避求新，他们认为经典的、传统的才是好的。”

引号和叹号互视一眼，不情愿地戴上了老冒派发的帽子。

冒号续道：“从宏观角度看，太阳底下没有新鲜事——AOP无非是SoC原理和DRY原则的一种应用；从微观角度看，太阳每天都是新的——AOP虽自OOP的土壤中长出，却脱离藩篱自成一体，并且嫁接到非OOP的领地，不仅在纯过程式语言、函数式语言、甚至逻辑式语言中得到发展，而且本身也具备了一定的声明式语言特征，成为一种新的软件模块化方式。”

问号举手：“什么是SoC和DRY？”

引号代答：“SoC就是Separation of Concerns，即关注点分离；DRY是Don’t Repeat Yourself，即尽量减少重复代码。”

“答案正确，加十分！”冒号戏赞道，“不良代码通常有两种病征：一是结构混乱，或聚至纠缠打结、或散至七零八落；二是代码重复，叠床架屋、臃肿不堪。治疗此类病症一个有效的方法是抽象与分解：从问题中抽象出一些关注点，再以此为基础进行分解。分解后的子问题主题鲜明且独立完备，既不会牵一发而动全身，也不会四分五裂、支离破碎。同时具有相同特征的部分可以象代数中的公因子一样提取出来，提高了重用性，减少了重复性。”

句号醒悟道：“这不就是模块化吗？”

“准确地说，抽象是前提，分解是方式，模块化是结果。”冒号很讲究精确，“大家记得庖丁解牛的故事吧？在常人眼中复杂的牛体，庖丁经过抽象，已目无全牛，及至提刀分解，自是游刃有余。待牛如土委地，模块化即成。”

句号举一反三：“前面提到的编程范式的基本思想大多不也如此？将程序分别抽象分解为过程、函数、断言、对象和进程，就依次成为过程式、函数式、逻辑式、对象式和并发式。至于泛型式——”

句号讲不下去了。

“泛型式虽未引入新类型的模块，其核心也是抽象出算法后与数据分解。”冒号为其解围，“以此类推，切面式的AOP将程序抽象分解为切面。”

问号提问：“抽象与分解的原则是什么？”

冒号作了个V字：“两条：单一化，正交化。每个模块职责明确专一，模块之间相互独立，即高内聚低耦合（high cohesion & low coupling）^[1]。此原则相当普适，是分析复杂事物的一种基本方法，在数学和物理中应用得尤为广泛，如质因式分解、正交分解、谱分解等等。”

逗号调皮地抬杠：“为什么称为正交化呢？斜交化不行吗？”

冒号呵呵一笑：“在数学中互为正交的两个向量在彼此方向上投影为零，意味着彼此独立、互不影响，斜交可不行。”

逗号吐了吐舌头。

“诚如前述，AOP以切面为模块。”冒号返回主题，“切面Aspect常直译为‘方面’，但它描述的是横切关注点（cross-cutting concerns），故‘切面’更准确生动，而‘方面’则失之空泛呆板。何谓横切关注点？顾名思义，乃是与程序的纵向主流执行方向横向正交的关注焦点。不妨回顾一下，无论是过程式的函数，还是对象式的方法，都包含了完整的执行代码。但有些代码横跨多个模块，以片断的形式散落在各处，虽具有相似的逻辑，却无法用传统的方式提炼成模块，难以实现SoC与DRY。典型的例子如：在调用某些对象的方法、读写某些对象的域、抛出某些异常等等前后，需要用到统一的业务逻辑，诸如日志输出、代码跟踪、性能监控、异常处理、安全检查、事务管理等等。为解决此类问题，AOP应运而生。它将每类横切关注点封装到单独的Aspect模块中，将程序中的一些执行点与相应的代码绑定起来。单个的执行点称为接入点（join point），例如：调用某个对象的方法前后；符合预先指定条件的接入点集合称为切入点（pointcut），例如：所有以set为命名开头的方法；每段绑定的代码称为一个建议（advice）。”

问号有点疑问：“接入点与切入点有何区别？”

冒号释疑：“望文生义，接入处是点，切入处是面，面由点组成。advice定义于切入点上，执行于接入点处。换言之，共享一段附加代码的接入点组成了一个切入点。切入点一般用条件表达式来描述，不仅有广泛性，还有预见性——以后新增的代码如果含有满足切入点条件的接入点，advice中的代码便自动附着其上。这是AOP的威力所在，但有时也是麻烦所在。”

引号很较真：“好像一些书上把join point译作连接点，把advice译作通知。”

“误导，完全是误导！”冒号有些痛心疾首，“何谓join point？是advice中额外代码接入之处，join显为‘参加’、‘加入’之意。如果说翻作‘连接’ 只是因缺乏动感和方向性而不够贴切的话，将advice译作‘通知’则近乎荒谬了。advice是在原有程序流程中加入的额外流程，可理解为建议采取的措施，而‘通知’强调的是一种信息，难道是程序运行到join point的信息？抑或采取某种行动的信息？简直不知所云。”

顿了一会，冒号仍意犹未尽：“英文好的技术不好，技术好的英文不好，两者都好的不屑去翻译，导致市面上的译书虽汗牛充栋，然佳作寥寥。这里奉劝各位，如果真想成为优秀的程序员，一定要尽可能地读原文的书籍、文章和文档。事实上，凡是科学和艺术方面的专业人员，要想专业水平上一层台阶，都应读该专业权威经典的原文。要知道，语言之间的天堑原本难以弥合，译者的专业水准、语言功底和严谨程度更是参差不齐。纵使万事俱备，一年半载后的译书便如隔夜的饭菜，虽刚出炉，已然不新鲜了。”

逗号抱怨：“英文虽读得懂，但太慢、太费劲了。”

“多读，读多了就习惯了。”冒号鼓励着，“对程序员来说，英语也是一门计算机语言，而且是必修的语言。”

课堂上有这么一个规律，越是题外的话大家讨论得越欢。下面果然开始嘈杂起来，冒号也乐得乘机歇歇嘴。

等大伙渐渐把视线重新聚焦到讲台上，冒号才继续讲课：“从软件重用的角度看，可以这么理解AOP与OOP的关系：OOP只能沿着继承树的纵向方向重用，而AOP则弥补了OOP的不足，可以在横向方向重用。这算是回答了引号开始提出的问题：AOP不是OOP的分支，也不能说是超越了OOP，而是OOP的一种补充——尽管AOP并不局限用于OOP语言。”

问号的求知欲很强：“AOP实现的机理是什么？”

冒号回答：“如果一个程序是一个管道系统，AOP就是在管道上钻一些孔，在每个孔中注入新的代码流。因此AOP实现的关键是将advice的代码嵌入到主体程序之中，术语称编织（weaving）。这是很自然的——将问题分解之后再合成，问题才得以还原。编织可分两种：一种是静态编织，通过修改源码或字节码（bytecode）在编译期（compile-time）、后编译期（post-compile）或加载期（load-time）嵌入代码——请注意，这里涉及到刚才提到的元编程和产生式编程；另一种是动态编织，通过代理（proxy）等技术在运行期（run-time）实现嵌入。具体的工具包括一些扩展性语言如AspectJ、AspectC++、Aspect#等和一些框架如AspectWerkz、Spring、Jboss AOP等。”

叹号搔着头：“听起来怪复杂的。”

引号倒不在乎：“这些机理是AOP的实现者需要操心的，使用者只需关心AOP是否好用，性能如何等等。”

“为了让你们有更直观的印象，我们借用光学原理来类比。”冒号用幻灯片展示了一幅图——

图3-3. 切面式编程

“众所周知，白光经过三棱镜的折射而分解为七色光，是谓光的色散。再经过一个倒置的三棱镜，七色光又重新会聚为白光。”冒号简述中学的物理知识，“如果把一个复杂的系统看作复合色的白光，经过第一个三棱镜——关注分离器，系统被分解为不同的切面，如同不同的单色的彩光。这些切面经过第二个三棱镜——编织器，再度合成为原系统。”

叹号脸上的迷惘之色渐去：“这下清楚多了。”

句号积极发言：“从中看出，AOP的实施分三步：切面分解、切面实现和切面合成。其中第一步是在设计者的头脑中进行的，第三步是通过AOP的工具实现的，真正需要程序员编码的部分在第二步，即分别实现各切面的advice。”

冒号赶紧补漏：“你好像忽略了切面的另一要素pointcut，如果程序员不指明advice挂靠的切入点，系统如何知道该何时何处调用他编写的执行代码呢？”

句号的嘴张成O状：“是哦，我怎么把这茬给忘了？”

在AOP的议题结束前，冒号不忘指出：“与OOP一样，AOP在带来便利的同时，也增加了一定的复杂度和性能损耗。它们更适用于大中型程序，用在小型程序中则不啻牛刀杀鸡。”

问号忽然想起一事，问道：“有一本名为《C++模版元编程》的书，既然提到了模板，想来也属于泛型编程吧？”

冒号答道：“模板元编程即Template Metaprogramming，与泛型编程密切相关但自成一派，隶属于另一种编程范式——元编程（Metaprogramming），简称MP。此处的前缀‘meta-’常译作‘元’，其实就是‘超级’、‘行而上’的意思。比如，元数据（Metadata）是关于数据的数据，元对象（Metaobject）是关于对象的对象，依此类推，元编程自然是关于程序的程序，或者说是编写、操纵程序的程序。”

叹号皱着眉：“听着有点绕。”

冒号投影出另一段代码——

    template <int N>
    struct factorial 
    {
         enum { value = N * factorial<N - 1>::value };
    };

    template <>            // 特化（specialization）
    struct factorial<0>    // 递归中止
    {
         enum { value = 1 };
    };

    int main()
    {
        cout << factorial<5>::value << endl; // 等价于 cout << 120 << endl;
        return 0;
    }

“以上用模板元编程实现了阶乘运算。”冒号讲解道，“与前面三种核心范式的阶乘实现有着根本的不同：这里阶乘的值是在编译时而非运行时计算出来的。换句话说，这段代码以模板形式通过编译器生成了新的代码，并在编译期间获得执行。”

叹号大惑不解：“这又说明什么呢？”

冒号并不直接回答：“假设你需要批量处理用户文档，其格式结构预先给定，但既不像CSV（逗号分隔）那么简单，也不像XML那么标准，并且用户随时可能改变格式标准，请问如何设计这段程序？”

叹号略一思索，便回答：“三大模块：阅读器读出输入文档，解析器按照格式标准去解析，处理器对解析结果进行处理。”

“显然关键在解析器，如果你是从头做起，那么问题至少有四。”冒号扳着指头数，“第一、费时写解析器代码；第二、费时调试解析器代码；第三、如果用户更改格式标准，你得重复做上两件事；第四、如果这段程序是大型程序的一部分，任何改动都可能意味着软件的重新编译、连接、测试、打包、部署等等。如果因为你的缘故公司不得不频频发布补丁包的话，你的饭碗恐怕是朝不保夕了。”

还是句号机灵：“既然谈到了元编程，一定是利用元编程，根据不同的格式标准自动生成相应的解析器代码。不过——此法虽一劳永逸，但难度似乎不小啊。”

“思路对头！”冒号赞许道，“大家听说过Lex和Yacc吗？它们能根据格式标准生成相应的解析器代码。更妙的是，格式标准不限于静态数据，甚至可以含有动态指令！这意味着用户不仅能定义业务数据格式，还能定义业务流程。”

“这敢情好！”叹号兴奋地说。

“如果知道Lex和Yacc本来就是编写编译器和解释器的工具，你就不会惊讶于它们的强大了。顺带说一句，编译器本身就是元编程的典型范例——把高级语言转化为汇编语言或机器语言的程序，不就是能写程序的程序吗？”冒号引申开来，“更进一步地，我们可以定义自己的领域特定语言DSL，更加灵活方便地处理客户逻辑。”

逗号有点糊涂了：“领域特定语言？就是前两堂课提到的非通用编程语言吧？怎么和元编程也扯上关系了？”

“不是扯上关系，而是它们之间本来就有着千丝万缕的联系。”冒号纠正着，“相比第三代的通用编程语言，领域特定语言由于其在应用范围上和语法上的限制而显得简单、针对性强，有时被成为‘小语言’（little language），也是一种特高级语言（very high-level programming language ，简称VHLL），属于第四代编程语言。”

冒号说到此处，逗号猛地一拍脑门：“哦，我明白了。第四代语言最终需要编译为机器语言，而编译器就是元编程的应用。”

“你只说对了一半。”冒号不疾不缓地说，“DSL一般不会一步到位地编译为第一代的机器语言或第二代的汇编语言，而是通过现成的编译器生成器（compiler-compiler或compiler generator）首先转化为第三代的高级语言。这样不仅大大降低了难度，也方便了程序的调试。刚才提到的Yacc（Yet Another Compiler Compiler）便是这样的工具，能为解析器（parser）产生C程序，多用于Unix下的编程。更现代的工具如ANTLR (ANother Tool for Language Recognition)，能生成C、C++、Java、C#、Python等多种语言的源程序。”

引号立刻联想到：“我记得框架Hiberate的必备库中就含有antlr.jar文件，与这个ANTLR有关吗？”

“说得正是！”冒号很满意学员完美的配合，“Hiberate中的HQL（Hibernate Query Language）是典型的DSL，需要通过ANTLR来解析。你们可以验证一下，在Hibernate的API中有org.hibernate.hql.antlr的package，但在其发布的源代码中相应的目录下却看不到一个Java源文件。却是为何？盖因此package中所有的源代码都是在ant build中自动生成的，这些非人工编辑的文件是不会放在版本控制中的。”

众人茅塞顿开。

句号想通了一个逻辑：“元编程作为超级范式的一个体现是，它能提升语言的级别。比如，有了编译器的存在，汇编语言升级为第三代高级语言；同样借助Yacc、ANTLR之类的元编程工具，第三代语言可以升级为第四代的DSL语言。”

冒号并未就此止步：“将这一模式发挥到极致，便是更加激进的语言导向式编程^[1]（Language-Oriented Programming，简称LOP）。这种编程范式的思路是：在建立一套DSL体系之后，直接用它们来编写软件，尽量不用通用语言。””

叹号莫明其妙：“想法近乎疯狂啊！放着好端端的通用语言不用，先造一套专用语言，这么做划算吗？”

“如果一个大型系统涉及的领域十分专业，包含的业务逻辑十分复杂，为其定制DSL或许会磨刀不误砍柴工。我们通过下面的两个图比较一下这种范式与主流编程范式的不同之处。”冒号映出新的投影——

图3-1. 通用语言编程

图3-2. 专用语言编程

“由于DSL比通用语言更简单、更抽象、更专业、更接近自然语言和声明式语言，开发效率显著提高，因此图中手工部分的时间相应减少。此外尤为关键的是，这种方式填补了专业程序员与业务分析员之间的鸿沟。要求一个非专业编程的业务分析员用DSL来开发固是勉为其难，但要做到读懂代码并审查其中的业务逻辑则已非难事。” 冒号细解个中要点，“如果说OOP的关键在于构造对象的概念，那么LOP的关键在于构造语言的语法。有人认为LOP是继OOP之后的下一个重要的编程范式，我们不妨拭目以待。”

句号整理了一下头绪：“能不能这么说：如果处理一些复杂、非标准格式的文档，可以考虑用元编程；如果整个业务逻辑复杂多变，可以考虑利用现有的DSL或创造新的DSL来处理业务，即所谓的语言导向式编程。”

“总结得不错，不过当特定格式的文档有了专门的解析器后，这种文档格式标准就可视为一种语言了，不是吗？这本质上就是DSL啊。”冒号出语点化。

句号顿时醒悟：“是啊，就像XML、HTML一样，能被程序认识的格式可不就是一种计算机语言嘛。”

冒号将话题延伸：“我们的想象力可以再狂野些，在文本DSL的基础上裹以图形界面，从而引进图形语言。如果再将部分业务逻辑开放给用户定制，那么你的客户会欣喜地发现，他们的经理只要点点鼠标就可以改变整个业务流程了，而这一切不仅不需要软件开发方或第三方的参与，连本公司的技术人员也免了。这时候倒是你的老板发愁了：你的设计太过完美，客户的后续开发费怕是赚不到啰。”

众人一乐。

问号继续发问：“还有其他元编程的应用吗？”

冒号随口举了几例：“元编程的例子比比皆是：许多IDE如Visual Studio、Delphi、Eclipse等均能通过向导、拖放控件等方式自动生成源码；UML建模工具将类图转换为代码；Servlet引擎将JSP转换为Java代码；包括Spring、Hibernate、XDoclet在内的许多框架和工具都能从配置文件、annotation/attribute等中产生代码。”

引号仍不知足：“这些应用虽然典型，但都是些开发工具、框架引擎之类的基础软件，有没有平时编程就能用到的例子？”

“当然有！”冒号坚定地答复，“有时程序中会出现大量的重复代码，却囿于语法上的限制无法进一步抽象化和模块化。如果采用手工编写或者单纯拷贝的方法，既费时又易错，显为下策。有时可借助IDE内置的代码生成功能，但一方面局限性很大，另一方面无法自动化和版本化。”

问号插问：“什么叫版本化？”

冒号解释：“理想情况下，一个程序员对程序的贡献都应该保存在版本控制系统（version control system）中，以便跟踪、比较、改进、借鉴和再生成。在IDE下自动生成的代码本身可以被记录，但产生代码时的行为却不能被记录，几次简单的鼠标动作就能产生较大的代码差别，使得版本比较的意义大打折扣。顺便说一句，离开IDE就无法编写、编译或调试的程序员，如同卸盔下马后便失去战斗力的武士，是残缺和孱弱的。”

问号有些明白了：“这是因为鼠标行为本身在代码中是没有痕迹的。”

“不仅是鼠标行为，有些需要键盘交互的行为也是没有痕迹的。比如在命令行下用debugger来调试的行为无法被记录，也难以重复和自动化，只能作为权宜之策。相比之下，日志（logging）和单元测试（unit test）具有明显的优势）^[2]。”冒号答完，立马重返主题，“回到上面的问题，既然有重复的代码，不能从语法上提炼，不妨退一步从文字上提炼。我们可以利用AWK、Perl之类的擅长文字处理的脚本语言，当然也可以用Java、C等非脚本语言，再辅以XSLT之类的模板语言，自动生成重复代码。这样不仅灵活性强，而且生成代码的代码——也就是元程序代码可以被重用，元程序的数据来源也能版本化。”

句号深得要领：“就像Hibernate中的antlr包一样，真正的源码反而不在版本控制中了。一方面没有保存的必要——可以自动生成；另一方面没有比较的必要——元程序的数据来源的变化比实际源码的变化更简明、更直观。”

冒号继续推进：“另外，有时程序的结构需要动态改变，而C++、Java、C#等静态语言是不允许动态变更类的成员或实现代码的，利用元编程便可突破这种限制。”

逗号恍然大悟：“原来元编程就是编写能自动生成源代码的程序。”

“也不尽然。”冒号马上修正道，“自动生成源代码的编程也属于另一种编程范式——产生式编程（Generative Programming）^[3]的范畴。区别在于后者更看重代码的生成，而元编程看重的是生成代码的可执行性。另外，除了在编译期间生成源代码的静态元编程，还有能在运行期间修改程序的动态元编程。从低级的汇编语言到一些高级的动态语言如Perl、Python、Ruby、JavaScript、Lisp、Prolog等均支持此类功能。比如许多脚本语言都提供eval函数，可以在运行时将字符串作为表达式来运算^[4]。”

问号突然问道：“编写病毒算不算元编程？”

“编写一个只是删除或感染文件的病毒，不必用到元编程。但如果要开发一个能自我变异的智能病毒，那就需要元编程了。不过你要是把元编程用在这方面，可别说是我教的。”冒号开了个玩笑。

引号自言自语：“程序的程序，就是程序的平方。”

“也可以是程序的立方，四次方……理论上是无限次方。在传统的编程中，运算是动态的，但程序本身是静态的；在元编程中，二者都是动态的。元程序将程序作为数据来对待，能自我发现、自我赋权和自我升级，有着其他程序所不具备的自觉性、自适应性和智能性，可以说是一种最高级的程序。它要求编程者超越常规的编程思维，在一种崭新的高度上理解编程。想象一下吧！”冒号激情勃发，“如果有一天机器人能自我学习、自我完善，甚至能生产新的机器人，实现‘智能繁衍’，是不是很美妙？”

“我怎么觉得特恐怖呢？岂止是程序员，所有地球人的饭碗都会被它们砸光了。”叹号此言一出，众皆忍俊不禁。

冒号重新开讲：“你们会不会经常遇到这样的情景：一遍又一遍地写着相似的代码，有心将其归并，却因种种原因无法践行。”

逗号心有戚戚焉道：“是啊，有时明明两个函数的实现几乎是一模一样的，就因为某些参数不匹配，无法合而为一。”

“有一种编程范式可以解决这个问题，它打破了不同数据类型之间的壁垒，让你的代码不再臃肿，这——就是泛型编程。”冒号的语调和说辞不免令人联想到电视上的减肥广告，“Generic Programming，简称GP，其基本思想是：将算法与其作用的数据结构分离，并将后者尽可能泛化，最大限度地实现算法重用。这种泛化是基于模板（template）的参数多态（parametric polymorphism），相比OOP基于继承（inheritance）的子类型多态（subtyping polymorphism），不仅普适性更强，而且效率也更高。这不能不说是一种异数——我们知道，普适性往往是以效率为代价的。如果一定要找出代价的话，那就是其用法稍微复杂一些，可读性稍微差一些。GP最著名的代表是C++中的STL（Standard Template Library），其后亦为Java、C#、D等语言所吸纳^[1]。此外，一些函数式语言如Ocaml、Standard ML、Haskell等也支持GP。”

冒号写下两段代码——

    template <typename T>
    T max(T a, T b)       // 求出两个数中的较大者
    {
            return  (a > b) ? a : b;
    }

    #define max(a,b) ((a) > (b) ? (a) : (b))
    

“求两个数中的较大值是经常遇到的问题。”冒号解说着，“对于静态类型语言^[2]来说，若参数类型不同，即使函数体相同也不能合为一体。如果语言不支持重载（overload），还可能出现maxInt、maxLong、maxFloat、 maxDouble之类的函数名，冗赘而丑陋。尽管在C中可用宏定义（macro definition）来实现，但无法保证类型安全，而C++模板则兼顾类型安全和代码重用，并且由于是在编译期间展开的，效率上也不损失。不止于此，C++支持运算符重载，除数值类型外，一切定义了‘>’ 运算的数据类型均可调用max函数，真是一举N得，N趋向无穷大啊！”

冒号边说边比划，夸张的语气和手势逗得大家都笑了。

引号提出疑问：“Java的一切对象都是Object类型，只要将所有参数都换成Object类型，岂不也是一种泛化？”

冒号答道：“首先，基本类型如int、float等不是Object的子类，虽然Java 新增了自动装拆箱（autoboxing/unboxing）的功能，但要付出性能的代价。更重要的是，这将不可避免地需要类型的显式转换（explicit conversion或cast），无法在编译期间施行严格的类型检查，由此丧失了静态类型语言的优势，为bug大开方便之门。这也是Java最终引入泛型的原因，虽然有些姗姗来迟。类似地，C/C++中的通用指针void *也有类型安全问题。”

句号发表他的看法：“泛型虽好，似乎只是某些局部才用到的技术，不具有前面几种范式的渗透性。”

冒号听罢不语，返身在黑板上写下几道题——

句号暗忖，这有何难？不过是些常规题罢了。不料冒号的问题却出人意表：“请问它们之间有何共同之处？能否共享同一段代码？”

见众人缄默已久，冒号接着投影出一段代码——

template <class Iterator, class Act, class Test>
void process(Iterator begin, Iterator end, Act act, Test test)
// 对容器中在给定范围内（即起于begin止于end）所有满足给定条件的元
//素（即test（元素）==true）进行处理（即act（元素））
{
    for ( ; begin != end; ++begin)    // 从头至尾遍历容器内元素
        if (test(*begin)) act(*begin); // 若当前元素满足条件，则对其采取行动
}

“STL有三要素：算法（algorithm）、容器（container）和迭代器（iterator）。算法是一系列切实有效的步骤；容器是数据的集合，可理解为抽象的数组；迭代器是算法与容器之间的接口，可理解为抽象的指针或者游标。”冒号讲述道，“算法串联数据，如脊贯肉；数据实化算法，如肉附脊。只有抽象出表面的数据，算法的脊梁才能显现。以上几题看似风马牛不相及，若运用泛型思维，便可发现它们的共性：对指定集合中满足指定条件的元素进行指定处理。用模板语言，寥寥数行即勾勒完毕。”

问号诧异道：“相比前面的max模板，这儿连元素的数据类型T都不见了？”

冒号回答：“元素被容器封装了。”

问号追问：“可连容器也看不到啊？”

冒号料有此问：“容器通过它的迭代器参与算法。”

句号豁然开朗：“通过模板，泛化了容器——可以是数组、列表、集合、映射、队列、栈、字符串等等；泛化了元素——可以是任何数据类型；泛化了处理方法和限定条件——可以是任何函数。”

冒号提醒道：“补上两点：这里的处理方法和限定条件不限于函数，还可以是函子（functor）^[3]——自带状态的函数对象；另外迭代器也被泛化了——可以从前往后移动，可以从后往前移动，可以来回移动，可以随机移动，可以按任意预先定义的规律移动。”

叹号由衷感叹：“果然强悍无比啊！”

逗号倒也心细：“最后一题中标准输入也算容器吗？”

“为什么不呢？只要一个对象配备了迭代器，它就可以作为容器来对待。I/O流上就有现成的迭代器，当然你也可以自行定制。索性我们来看看这道题的解法吧。”冒号给出了第六题的实现代码——

#include <iostream>
#include “process.h” // 前述process所在的头文件

using namespace std;

// 判断字符是否为非数字字符
bool notDigit(char c)
{
    return (c < '0') || (c > '9');
}

// 打印非数字字符
void printNondigit(char c)
{
    cout << c << "不是数字字符" << endl;
}

int main()
{
    process(istream_iterator<char>(cin), istream_iterator<char>(),
            printNondigit, notDigit);

    return 0;
}

逗号打量了半天：“这里完全看不到I/O读取的过程，也看不到通常的迭代循环，简洁得难以置信。”

冒号补充道：“不光是代码简洁，它还让人摆脱了底层编码的细节，在更高更抽象的层次上进行编程设计。”

引号发觉：“开始谈起泛型编程时，您特别强调它对数据类型的抽象。现在看起来，它也能对函数进行抽象呢。”

“说得没错，条件是被抽象的函数或者方法具有相同的签名（signature）或接口（interface）。不过别忘了，在C和C++中的函数——准确地说是函数指针——也能作为数据类型。但不管怎样，这都表明泛型编程不仅能泛化概念，还能泛化行为。”冒号目光转向句号，“现在还有人认为泛型编程的渗透性不够强吗？”

句号腆然一笑。

“这些只是泛型编程的冰山一角。重要的是，我们不是在玩弄花哨的技巧，而是在用一种新的视角去审视问题。”冒号总结道，“泛型编程是算法导向的（Algorithm-Oriented），即以算法为起点和中心点，逐渐将其所涉及的概念（如数据结构、类）内涵模糊化、外延扩大化，将其所涉及的运算（函数、方法、接口）抽象化、一般化，从而扩展算法的适用范围。这非常类似数学思维——当数学家证明完一个定理后，总会试图在保持核心思想的前提下，尽可能地放宽题设，增强结论，从而推广定理。外行人常以为数学定理最重要，其实数学思想才是数学的精髓。比如举世皆知的哥德巴赫猜想和费尔马大定理，人们在攻克它们的过程中产生的新思想、新理论、新方法，已远远超过了定理本身的意义。数学家们甚至不愿这些猜想被过早地解决，怕扼杀了会下金蛋的鸡。在他们眼里，思想是鸡，结论是蛋。这也无怪乎STL会出自一位学数学的人之手了^[4]。”

“我怎么觉得更像是出自一位菜场大妈之口呢？” 逗号打趣道，“不信你们听嘛，算法好比脊骨、数据好比猪肉、思想好比母鸡、结论好比鸡蛋。我没说错吧？”。

众人哑然失笑。

逗号好奇地问：“还有其他类型的编程范式吗？”

“不但有，而且有很多。”冒号喝了一口水，悠悠地说，“并发式编程（concurrent programming）就是其中之一。”

叹号有些惊讶：“并发式编程也算一种范式？它似乎更像是提高运行效率的一种手段。”

“大谬不然。”冒号摇摇头，“真正的并发式编程，绝不只是调用线程^[1]API或使用synchronized、lock之类的关键字那么简单。从宏观的架构设计，到微观的数据结构、流程控制乃至算法，相比通常的串行式编程都可能发生变化。随着硬件性能和用户需求的双重提升，并发式编程已成为不可回避的主题。毫不夸张地说，并发式编程是继OOP之后又一场思想和技术上的革命。只是相比OOP，尽管年龄相仿，但语言上不够支持，标准上不够统一，理论上不够完善，因而这场革命更具破坏性和建设性。现在我们来看一个例子，比较两种烧水泡茶的方案。”

说着冒号在黑板上写下——

引号见多识广：“我记得这好像是运筹学中的例子，显然方案二更佳。从编程的角度来看，方案一是串行式编程，方案二是并发式编程——烧水的线程与洗茶杯放茶叶的线程是同时进行的。”

“如果方案一也用并发式编程呢？”冒号追问。

引号一愣，随即道：“必须先洗茶杯后放茶叶，洗茶杯放茶叶的同时也没法烧水，至于泡茶，更得等水开之后了。”

句号明白了冒号的用意：“这就是说，单凭并发式编程并不能保证提高程序性能，还必须在程序设计上下功夫。”

问号继续深究：“即便如此，如果硬件不支持，并发式编程也未必能提高效率啊。比如在一台单处理器的主机上，多个线程只能是模拟的、逻辑上的并行，而非真正物理上的并行。”

“这话有一定道理。”冒号有限度地表示赞同，“但设计者应该未雨绸缪，总不能等到有了多处理器才想到并发式编程吧？再者，没有多处理器，是不是可以利用多台单处理器的主机同时运算呢？退一步讲，即使在一台单处理器的情况下，并发式编程有时也是必不可少的。它能保证不同用户、不同程序之间的公平竞争，这对多用户、多任务的系统而言尤为重要。此外，采用并发式编程同样可能提高性能。最典型的一个例子：当一个线程因为等待某种资源而被堵塞时，可以切换到其他线程而不至让CPU闲置。更重要的一点是，难道除了缩短程序运行时间外，并发式编程就没有别的好处吗？譬如打开一个网页，你是希望浏览器边下载边显示网页呢，还是下载完成后再显示？”

“当然是边下载边显示啦。” 叹号毫不犹豫地说，“如果每个网页都是下载完成后再显示，那还不把人给憋坏了！”

逗号加了一句：“浏览器加载文字和加载图像也应分开在不同的线程，如果用户对文字部分不感兴趣，不等图像显示就可直接关闭网页了。”

“如果网页被提前关闭，那也是假用户之手变相缩短了程序运行时间。”冒号接过话来，“还有一个常见的例子，包括浏览器在内的许多应用软件在运行中都会显示一个进程条。该进程条的更新需要一个单独的线程，从效率上看它起的作用是负面的，但大大提高了用户体验，是软件人性化的表现。再举一例，媒体播放器一般都会提供暂停、快进、倒退、快放、慢放等按钮，如果不采用多线程，它们将形同虚设。此处并发式编程的作用在于提高了软件的响应能力，也改善了用户体验——有谁愿意驾驶一辆启动后不能刹车、不能倒车、不能变速、油尽方停的汽车呢？”

“岂止是不愿意，简直是恐怖！”叹号加重了语气。

“对于操作系统、各种实时系统和诸如数据库、网络服务器等基于服务的系统来说，在响应用户请求的时间上和资源的合理分配上有着极高的要求，并发式编程更是不可或缺。”句号接着补充。

问号紧接着又问：“并发式编程还有其他用处吗？”

冒号应道：“不同编程范式采用不同的视角和方法来设计和开发软件。并发式编程以进程为导向（Process-Oriented）、以任务为中心将系统模块化。我们都知道，模块化在编程中是个好东西。”

引号心存疑惑：“过程式中引入了函数模块，对象式中引入了对象模块，但并发式似乎没有在语法上引入新型模块，比如C和Java中的线程其实不过是函数或方法的包装而已。”

“我猜你的意思是：在定义一个线程之前，其主函数已经模块化了，不能把功劳记在并发式编程上，对吧？”冒号笑问，“你不能孤立静止地看待每个模块，还要考虑到模块之间的相互关联和作用。相比串行式，并发式在模块之间引入了新的通讯和控制方式。也就是说，原先的一些模块的定义和划分一定是建立在线程机制的基础上的。如果失去线程的支持，它们的合理性自然会打上问号，说不定整体设计都会受到牵连。这也体现了编程范式的渗透性和全局影响力。”

教室上空弥漫的疑云一消而散。

冒号进一步指出：“除了用户主观上的需求和硬件客观上的可能外，并发式显得格外重要的另一深层原因是：许多程序是现实世界的模拟，而我们生活的世界不折不扣是并发式的。从某种意义上看，并发式的模拟比对象式的模拟更贴近世界。”

引号再次提问：“并发式编程在设计上有什么要求？”

“并发式编程以资源共享与竞争为主线——又是对当今世界形势的一个逼真模拟。这意味着程序设计将围绕进程的划分与调度、进程之间的通讯与同步^[2]等等来展开。合理的并发式设计需要诸多方面的权衡考量。”冒号说着，放出一段幻灯片——

叹号蹙眉：“并发式编程好是好，就是太复杂。”

“天下没有免费的午餐。有所得，必有所失。” 冒号淡淡地说，“并发式编程当然不容易，但也并非难以掌握。最重要的是，作为一个程序员，你不得不面对它。即使你不直接用并发式编程，你依赖的代码和依赖你的代码也可能用到；即使现在没有用并发式，将来也可能用到。如果采取避而不理的鸵鸟政策，早晚会被人点中你的死穴。虽然目前不会对并发式编程作更深入的探讨，但希望能引起你们足够的重视。”

句号谈及他的感受：“相比OOP在语言上得到的支持，并发式的支持力度好像很不够。”

冒号点头称是：“这是由并发式的复杂性和成熟度决定的。另外，在究竟是在语言级别上支持并发、还是交由操作系统处理的问题上，仁者见仁，智者见智。Ada、Java和C#等选择前者，在语法上对并发式编程有一定的支持；C和C++等选择后者，除了关键字volatile外，主要靠库函数支持。专门为并发式而设计的语言大多仅限于学术研究而非商业应用，Erlang语言^[3]是少数的例外。顺带提一下，前面提到的声明式语言具有无副作用的特性，尤其适合于并发式编程。”

问号提了一个听似奇怪的问题：“并发式与前面提到的对象式有无共通之处？”

“并发式与对象式虽是互相正交的两种范式，倒真有些相通呢。”冒号回答，“它们均与三大核心范式正交，并且越来越广泛地向它们渗透着；均为传统编程的一种推广——并发式进程的个数为一时即为传统的串行式编程，对象的方法个数为为零即为传统的数据类型；均将整个程序系统分解为若干独立的子系统，不同的是一个以任务为单位，一个以对象为单位；子系统之间均能交流与合作，不同的是一个以竞争为主题，一个以服务为主题。如果将程序系统视作公司，那么并发式系统是产品型公司，每个进程是一名工人，其职责是执行单一任务；对象式系统是服务型公司，每个对象是一名服务员，其职责是提供系列服务。由此可见，一名优秀的程序设计师也应该是一名优秀的管理者。”

句号提出：“迄今为止我们谈到了五种范式，能否对它们简单概括一下？”

“你提问的时机把握得不错嘛。”冒号开始如数家珍，“为便于记忆，我们不妨用‘一二三四五’来概括编程范式之最：最传统的一个是命令式；最基本的两个是命令式和声明式；最核心的三个是命令式、函数式和逻辑式；最主要的四个是命令式、函数式、逻辑式和对象式；最重要的五个是命令式、函数式、逻辑式、对象式和并发式。最后，我们来对比一下五大范式。”

少顷，黑板上出现几行排比句——

“说回并发式编程，它要求我们摆脱以往习惯的按部就班的思维方式，对编程提出了更高的挑战。程序世界与现实世界一样，呈百舸争流、千帆竞发之势，不进则退啊！”言讫，冒号宣布，“第二堂课到此为止，欢迎下次光临。”

短憩之后，引号迫不及待地问：“面向对象的范式应该是一种特殊的命令式吧？”

“面向对象？”冒号咕哝着，“姑且称之为OO或对象式吧，既不标新立异，也不以讹传讹。在回答你的问题之前，请先回答我的：什么是OOP？”

引号应答如流：“OOP（Object-Oriented programming）是一种计算机编程模式，它以对象作为问题空间的基本元素，利用对象和对象间的相互作用来设计程序。所谓对象，是实际问题中实体的抽象，具有一定的属性和功能。OOP的三个基本特征是：封装性、继承性和多态性。所谓封装性就是——”

冒号作了个暂停的手势：“OOP的的基本特征相信大家早就耳熟能详了，那么根据你刚才的定义，能否得出OOP一定是命令式的结论？”

引号歪头想了一阵，答道：“从定义上好像并不能得出，难道C++、Java、C#不是命令式的吗？”

冒号回答：“当然是，但这不妨碍Clos成为OO版的Lisp，而Prolog也有不少融入OO特征的扩充，如Visual Prolog、Logtalk等。OOP虽然是在命令式的基础上发展起来的，但其核心思想可泛化为：以数据为中心组织逻辑，将系统视为相互作用的对象集合，并利用继承与多态来增强可维护性、可扩展性和可重用性。这种思想也能应用到函数式和逻辑式中，只不过对象的方法从命令式中的过程分别换成函数式中的函数和逻辑式中的断言罢了。大致说来，命令式、函数式和逻辑式互相平行，而OOP与它们正交。”

问号提问：“OOP已经成为一种潮流，上堂课列举的十二种流行语言中只有C不是OO的，这是否意味着OOP将要一统天下？”

“严格说来，VB（VB.NET除外）和JavaScript也不是OO的，只是基于对象的（Object Based）^[1]。” 冒号纠正道，“至于OOP是否会一统天下，答案是否定的。首先，与能独当一面的三类最基本的范式不同，纯粹的OOP是不存在的^[2]，必须结合其他范式；其次，世上没有包治百病的万灵丹方，OOP也不例外。用软件业的行话来说：没有银弹（No silver bullet）^[3]。OOP最适用于大型复杂的、交互式的、尤其是与现实世界密切相关的系统，但在小型应用、数学计算、符号处理等方面并无优势。需要指出的是，语言和范式的流行，与大公司支持和商业推动是密切相关的。有人说OOP其实是MOP（Money-Oriented Programming），即以金钱为导向的。虽有过激之嫌，但有经验的股民都知道，有主力运作的股票总是涨得快一些的。当然OOP能流行，自有独到之处，谁能说说它到底好在哪里？”

逗号抢答：“OOP能提高软件的可维护性、可扩展性和可重用性。”

冒号反问：“为什么过程式编程的可维护性、可扩展性和可重用性就差呢？”

感到来者不善，逗号有点发虚：“因为OOP具有信息隐藏、继承和多态的特征。”

冒号并不买帐：“首先，将可维护性、可扩展性和可重用性与OOP划等号，是只见树木，不见森林——那是所有范式和语言的共同目标。其次，以C语言为例，信息隐藏可用关键字static来实现；继承可用合成（composition）来代替；多态可以利用函数指针来实现。更何况这些只是手段而非目的，只要设计合理，C程序同样具有可维护性、可扩展性和可重用性，性能效率还更优越。即使在OOP日益风行的今天，C的占有率始终稳踞前列，许多大型复杂软件如操作系统、数据库等仍以C为主，这足以证明其仍堪大用。”

见逗号有些理屈词穷，冒号语气放缓：“请不要误解，我并非OOP的反对者，相反今后还要重点讨论它。但我希望大家少一点照本宣科和人云亦云，多一点独立思考，甚至不妨标新立异。”

稍作停顿，冒号继续发问：“过程式编程与OOP在设计理念上有什么区别？”

“过程式编程的理念是以过程为中心，自顶向下、逐步求精^[4]。”引号一出口就自感有些“照本宣科”，见冒号正用鼓励的目光看着他，这才继续说下去，“OOP则正相反，以数据为中心，自底向上、逐步合并。”

冒号首肯道：“如果把整个流程看作一颗倒长的大树，过程式编程自树根向下，逐渐分支，直到每片树叶，类似数学证明中的分析法，即执果索因的逆推法；OOP则从每片树叶开始，逐渐合并，直到树根，类似数学证明中的综合法，即执因索果的正推法。”

句号心领神会：“倘若把树根看成主函数，离树根越近，离用户需求也越近。如果用过程式编程，由于是逆推法，树干改变容易导致树枝相应改变，因此一旦用户需求发生变化，可能会从树根波及到树枝甚至树叶，维护起来殊为不易。相反OOP从树叶开始设计，离用户需求较远，抽象程度较高，受波及的程度较小，因此更易维护和重用。”

冒号拊掌赞道：“好极了！”

问号不解：“您刚才不还说C程序同样具有可重用性吗？”

冒号微微一笑：“数学中分析法与综合法往往是结合起来使用的，过程式编程与OOP也是如此，只不过各有偏重罢了。句号的一番话虽不无道理，但也授OOP的反对者以口实：OOP鼓吹的可重用性来自‘自底向上’的设计模式，而这种模式并非OOP的专利。其实软件设计的最重要的并不是编程语言，甚至也不是编程范式，而是抽象思维。关于这一点，我们今后还会详细阐述。”

叹号不甘寂寞，插言道：“OOP以对象为基本模块单位，而对象是现实中具体事物和抽象概念的模拟，这使得编程设计更自然更人性化。”

“深合吾意！”冒号挥动着右手，“尽管OOP最大的卖点是其高度的可重用性，相比其他范式却并不具明显优势。但它更接近人类的认知模式，编程者更容易也更乐于用这种方式编程，这是它深入人心的一个重要原因。比较一下两种用法：牛.吃（草）与吃（牛，草），哪种更接近人类思维？”

有人在底下嘀咕：“如果把牛换成狗，那么一个是狗吃屎，一个是吃狗屎。”

全班捧腹。

冒号也忍不住笑了：“OOP人性化的另一表现是其接口简洁易记。看看Win32 API、Unix API等之类操作系统接口或OCI之类的数据库接口，函数的参数动辄七八个乃至上十个，函数名和数据结构成员也多冗长晦涩，既难记又易错。相比之下，相应的Java的API显然平易近人得多。”

问号刨根问底：“为什么C的API不能象Java的那么简洁呢？”

冒号释疑：“单纯这么比较其实对C并不公平，因为Java的API虽然简洁易用，但功能上与相应C的API并不等同，换句话说，Java把接口粗粒度化了。”

“接口粗粒度化？”引号质疑道，“就是把一些函数包装起来吧？我们也可以用C将操作系统、数据库之类的API再包装一下。”

“事实上许多软件公司都曾这样做过。”冒号颔首作答，“但C函数不像Java对象，本身没有状态，只有依靠参数传递或外部变量来维持相关函数之间的联系，包装后的接口肯定不如Java简洁，但应该比Java高效。说白了，OOP就是将相关的函数用数据粘合，重新包装后再贴上对象的标签。从这种角度上看，与其说OOP更具重用性，不如说更具易用性。”

叹号狐疑道：“OOP并不更具重用性？这可是它的金字招牌啊！”

冒号冷哼一声：“不要被金字招牌晃晕了眼，我来问你：是收音机、电视机之类的电器产品更具重用性呢，还是电阻、电容之类的电器元件更具重用性？”

“当然是电器元件啦。”叹号冲口而出。

冒号因势利导：“每个电器元件具备单一的功能，正如过程式中的函数；每个电器产品是对多个相互关联的电器元件的封装，正如OOP中的对象。同样的电器元件可用于不同的电器产品，具有高度的可重用性，而电器产品重用性低，但易用性高。^[5]”

众人犹自将信将疑。

“对一个没有独立思考习惯的人来讲，与其说他认同一个理论，倒不如说他认同该理论倡导者的权威。而在他仰视权威的同时，也把自己的思想交托给了权威。”冒号颇具犬儒之风，“你们可以怀疑我的观点，但绝不可放弃自己的思考。请注意，这就是我在第一堂课提到的精神——批判精神。”

冒号这时停了下来，与在座的每位逐一对视。他仿佛想通过目光把这种精神注入到每个人的身上，就像武侠小说中通过手掌将内功传输给他人一样。并不是每个人都能理解冒号的用心，但都或多或少地感受到一种异样的气氛。

“关于OOP今天就谈到这里。”冒号恢复了常态，“请不要奇怪为何如此流行的编程范式我却一带而过，那是因为你们对它相对比较熟悉，而我们这一轮只是在作热身运动，以后再作专项训练。在结束之前，我们引进一个新视点：过程式编程的模块以函数为单位，OOP的模块以对象为单位，二者的区别是：函数是被动的实体，对象是主动的实体。过程式程序的世界是君主制的，主函数是国王，其他函数是臣民，等级分明，所有臣民在听命于上级的同时也对下级发号施令，最终为国王服务；OO程序的世界是民主制的，所有对象都是独立而平等的公民，有权利保护自己的财产和隐私并向他人寻求服务，同时有义务为他人提供承诺的服务，公民之间通过信息交流来协作完成各种任务。更进一步地，封装使得公民拥有个体身份，需要对自己负责；继承使得公民拥有家庭身份，需要对家庭负责；多态使得公民拥有社会身份，需要对社会负责。欲知个中玄机，且听我日后慢慢道来。”

众人顿觉耳目为之一新。

冒号迅速转移了话题：“下面我们来谈谈与命令式编程相对的声明式编程（declarative programming）。顾名思义，声明式编程由若干规范（specification）的声明组成的，即一系列陈述句：‘已知这，求解那’，强调‘做什么’而非‘怎么做’。声明式编程是人脑思维方式的抽象，即利用数理逻辑或既定规范对已知条件进行推理或运算。”

问号询问：“声明式产生的背景是什么呢？”

“声明式编程发轫于人工智能的研究，主要包括函数式编程（functional programming，简称FP）和逻辑式编程（logic programming，简称LP）。其中，函数式编程将计算描述为数学函数的求值，而逻辑式编程通过提供一系列事实和规则来推导或论证结论。其实支持它们的语言出现得并不比命令式的晚多少——最早的函数式语言Lisp（LISt Processor）已有半个世纪的历史，最早之一的逻辑式语言Prolog（PROgramming in LOGic）也与C同龄。只是由于大多数更多地用于学术研究而非商业应用，颇有些‘养在深闺人未识’啊。”冒号有些惋惜，“起源的不同决定了这两大类范式代表着迥然不同的编程理念和风格：命令式编程是行动导向（Action-Oriented）的，因而算法是显性而目标是隐性的；声明式编程是目标驱动（Goal-Driven）的，因而目标是显性而算法是隐性的。为便于说明，我们分别用三种代表性的语言来实现阶乘（factorial）运算。”

冒号在黑板上打出投影——

    int factorial(int n) 
    {
        int f = 1;
        for (; n > 0; --n) f *= n;
        return f;
    }

    (defun factorial(n)
      (if (= n 0)
        1                               //  若n等于0，则n!等于1
        (* n (factorial(- n 1)))))      //  否则n!等于n* (n-1)

    // 0! 等于1
    factorial(0,1).
    // 若M等于N-1且 M!等于Fm且F等于N*Fm，则N! 等于F
    factorial(N,F) :-   M is N-1, factorial(M,Fm), F is N * Fm. 

冒号提问：“撇开语法细节，大家说说以上三段代码区别在哪里？”

句号沉思片刻，答道：“C明确给出了阶乘的迭代算法，而Lisp仅描述了阶乘的递归定义，Prolog则陈述了两个关于阶乘的断言。”

冒号很满意：“一针见血！第二个问题：你们更习惯哪一种思维方式？”

逗号不加思索：“当然是第一种！”

冒号微笑着说：“这证明你至少是受过一定训练的程序员。大家回想一下，当你们初学编程时，是否习惯这种思维方式？”

叹号沉吟道：“好像不太习惯i = i + 1之类的语句。”

“对！”冒号的一嗓子吓了众人一跳，“我们最早接触的变量是代数方程中的x、y、z等，本质上是抽象化的符号，变量值是该符号在给定约束条件下的允许值。而命令式编程中的变量本质上是抽象化的内存，变量值是该内存的储存内容。通俗地说，前者好比姓名，所指之人是固定的；后者好比住址，所住之人是变化的。此外，等号在代数中是一种约束，而在许多命令式语言中则表示赋值。因此i = i + 1可以在命令式编程中出现，但绝不可能在数学推理中出现^[1]——除非在反证法中。”

叹号又道：“现在回头再看代数，反倒有些不习惯了。”

“这就是思维的定势效应。”冒号感慨道，“声明式编程让我们重回数学思维：函数式编程类似代数中的表达式变换和计算，逻辑式编程则类似数理逻辑推理。其中的变量也如数学中的一样，是抽象符号而非内存地址，因此没有赋值运算，不会产生变量被改写的副作用（side-effect），也不存在内存分配和释放的问题。这既简化了代码，也减少了调试——不妨想一想，有多少bug是由于某个变量被意外改写或内存管理不慎而造成的？”

问号问道：“声明式语言与命令式语言看来是两个世界的产物，它们是否有相通之处？”

冒号答道：“首先，所有高级语言都建立于低级语言之上，最终转化为机器语言，声明式语言也不例外。其次，声明式语言与命令式语言并非泾渭分明，而是互相交叉渗透的。一些‘非纯粹’ 的声明式语言也提供变量赋值和流程控制，而一些命令式语言也在逐渐发展，通过利用其他程序或增加新的语言特征来实现声明式编程。总的说来，在命令式语言中融入声明式的元素应当是一种趋势。尤其是函数式，它的一些特征已经在许多命令式语言中得到了支持。比较而言，声明式编程重目标、轻过程，专注问题的分析和表达而不致陷入算法的迷宫，其代码也更加简洁清晰、易于修改和维护。从这种意义上说，声明式语言天然地就比命令式语言更高级。上节课提到的前三代计算机语言基本上都是命令式的，而后两代基本上都是声明式的，由此可见一斑。”

句号一拍脑袋：“命令式是模拟电脑的，声明式是模拟人脑的，人脑当然比电脑高级啦。”

冒号另有佐证：“早在命令式语言引入函数从而进化为过程式语言时，就已经开始向声明式过渡了。何以见得？比方说调用一个函数的语句：doWhat()，这不正是在声明‘what to do’吗？至于‘how to do’，即函数的具体实现细节，则不劳调用者费心。这种声明式的风格，提高了语言的抽象能力和开发效率，促成了语言的升级。”

逗号仍然有些疑惑：“既然声明式编程有这么多好处，为什么命令式语言不仅占大多数，而且流行程度也不减呢？”

冒号回答：“编程语言的流行程度与其擅长的领域关系密切。声明式语言——尤其是函数式语言和逻辑式语言——擅长基于数理逻辑的应用，如人工智能、符号处理、数据库、编译器等，对基于业务逻辑的、尤其是交互式或事件驱动型的应用就不那么得心应手了。而大多数软件是面向用户的，交互性强、多为事件驱动、业务逻辑千差万别，显然命令式语言在此更有用武之地。”

大家频频颔首。

“值得指出的是，声明式编程并不仅仅局限于函数式和逻辑式。”冒号旋即补充道，“比方说，C#中的attribute、Java中的annotation和XDoclet库等采用的也是具有声明式特征的属性导向式编程（Attribute-Oriented Programming，简称@OP）。再比如，Prograph^[2] 、SISAL^[3]等数据流语言（dataflow language）采用的数据流式编程（Dataflow Programming）与函数式编程有不少共同点，同样属于声明式的范畴。还有一些语言如Oz、CHIP等支持与逻辑式编程相交的约束式编程（Constraint Programming）^[4]。此外，大家熟悉的数据库语言SQL，样式语言XSLT、CSS，标记语言HTML、XML、SVG，规范语言IDL（Interface Description Language）等等都是声明式的。算上它们，声明式语言所占的比例也是非常可观的。此前之所以没有提及，一方面，不少声明式语言采用的范式并没有专门的名称；另一方面，这些语言大多是领域特定语言，并且不少并非图灵完备的，有的连运算都没有。毕竟，目前我们的重点还是放在通用编程语言上。”

问号突然想到了什么，指着投影问：“这里用Lisp实现阶乘的方法不也可以用在C上吗？”

冒号点点头，写下一段代码——

int factorial(int n) 
{
    return n == 0 ? 1 : n * factorial(n - 1);
}

“这是C的递归实现。”冒号娓娓道来，“除了细微的语法差别外，二者的确很相似，这说明用命令式语言也可以讲出声明式的味道。实际上，命令式语言提倡迭代而不鼓励递归，早期的Fortran 甚至都不支持递归。一则迭代比递归更符合命令式的思维模式，因为前者贴近机器语言而后者贴近数学语言；二则除尾递归（tail recursion）^[5]外，一般递归比迭代的开销（overhead）大。相反，声明式语言提倡递归而不支持迭代^[6]。就语法而言，它不允许迭代中的循环变量；就视角而言，迭代着眼微观过程而递归着眼宏观规律。”

叹号轻叹：“原来貌似普通的迭代和递归有那么多道道！”

“任何语言都难脱命令式或声明式的窠臼。事实上，凡是非命令式的编程都可归为声明式编程。因此，命令式、函数式和逻辑式是最核心的三种范式。为清楚起见，我们用一幅图来表示它们之间的关系。”说罢，冒号换了一个幻灯片——

图2-4. 编程范式的简单分类

末了，冒号归纳道：“归根结底，编程是寻求一种机制，将指定的输入转化为指定的输出。三种范式对此提供了截然不同的解决方案：命令式把程序看作一个自动机，输入是初始状态，输出是最终状态，编程就是设计一系列指令，通过自动机执行以完成状态转变；函数式把程序看作一个数学函数，输入是自变量，输出是因变量，编程就是设计一系列函数，通过表达式变换以完成计算；逻辑式把程序看作一个逻辑证明，输入是题设，输出是结论，编程就是设计一系列命题，通过逻辑推理以完成证明。绘成表格如下（如表2-1所示）——”

冒号见众人微显难色，宽慰道：“这部分理论性稍微强了些，对函数式和逻辑式也仅作了描述性说明，并未深入展开。不解之处，大可不必介怀，撒下的种子总有一天会萌动。先休息片刻，不要走开，广告之后更精彩。”

第二课伊始，冒号开门见山：“首先介绍一下最原始也是我们最熟悉的编程范式：命令式编程（imperative programming）。用命令式编写的程序由命令序列组成，即一系列祈使句：‘先做这，再做那’，强调‘怎么做’。更学术点说，命令式编程是电脑——准确地讲，是冯•诺伊曼机（von Neumann machine）——运行机制的抽象，即依序从内存中获取指令和数据然后去执行。从范式的角度看，其世界观是：程序是由若干行动指令组成的有序列表；其方法论是：用变量来储存数据，用语句来执行指令。”

逗号小声嘟囔着：“我们用的编程语言不都是命令式的吗？”

“应该说绝大多数语言是命令式的，但非命令式的语言也是存在的。关于后者，我们稍后再议。” 冒号纠正道，“这也在情理之中。语言的演化是渐进的，大多数语言追根溯源是汇编语言的升级，而作为与机器语言一一对应的汇编语言自然是命令式的，因而这种范式最为传统和普及。”

不料问号竟穷追不舍：“为什么机器语言就一定得是命令式呢？”

“我很欣赏你这种打破砂锅问到底的精神，不过你可以问到底，我却不敢保证能答到底哦。”冒号有些逗趣地说。

问号略带腼腆地笑了。

“从理论上而言，完全可以有非命令式的机器语言存在，前提是计算机采用了特殊的硬件实现，比如非冯•诺伊曼结构的数据流机（dataflow machine）和归约机（reduction machine）。但这类计算机并未流行于市，相应的机器语言自然罕见了^[1]。”冒号还是给出了理由。

引号问：“命令式编程与人们常说的过程式编程是一回事吗？”

“严格说来，过程式编程（procedural programming）是指引入了过程（procedure）、函数（function）或子程序（subroutine/subprogram）的命令式编程。但由于现代的命令式语言均具备此特征，故二者往往不加区分。”冒号回应道。

句号认为：“由于常用的语言基本上都是命令式的，其思想也与计算机的运行机制相符，一切对我们来说，似乎都是自然而然的事。”

“单纯的命令式思想的确很朴素，毋庸赘述。” 冒号承认，“但有必要提一下结构化编程（structured programming或简称SP），它是在过程式编程的基础上发展起来的。其本质是一种编程原则，提倡代码应具有清晰的逻辑结构，以保证程序易于读写、测试、维护和优化。可别小瞧它，在上世纪六十年代首次爆发的软件危机中，它曾起着中流砥柱的作用，就像后来的OOP一样。Pascal正是遵循结构化编程原则而设计的一种教学语言，当年也是风光无限。为直观起见，我们用图来表现程序的结构化特征——”

图2-1. 非严格的结构化程序框图

“这是一个流程图（flowchart），或称程序框图，它描述了一个简单程序：用户从标准输入中键入算术表达式，程序打印出结果，如此循环往复，直到用户输入字符‘q’为止。”冒号解释道，“若以纯粹的结构化编程的标准来衡量，该流程图并未达标。”

叹号有些惊讶：“这个图不是再清晰不过了吗？”

“根据结构化定理（structured program theorem）^[2]，任何程序都可用顺序（concatenation）、选择（selection）和循环（repetition）等三种基本控制结构来表示。”冒号画了几幅图——

图2-2. 三种基本控制结构：顺序、选择和循环

冒号指点着黑板：“结构化编程就是在三种基本结构的基础上进行嵌套组合。如果将每个基本结构看作基本电器元件，编程就是将这些元件组装成复杂的电路。请注意，所有基本元件都满足‘单入口、单出口’（single entry, single exit，简称SESE）的原则，这使得电路井井有条，不会串线缠绕。”

引号已经看出：“上面的流程图无法用基本结构来组合，所以不是标准的结构化程序。”

冒号提出要求：“你能改造一下吗？”

引号走上讲台，在前图的基础上作了些许调整——

图2-3. 严格的结构化程序框图

“嗯，不错。这下流程图可以拆解为基本结构了。”冒号表示认可，“二者的区别在于前者利用了break语句，在循环途中退出，后者通过引入quit标志（flag）保证了循环的完整性。”

逗号的脸上写下一个大大的问号：“难道连break语句都不能用吗？”

“break语句只是在循环体内部的跳转，合理地使用它能简化代码，不致影响整体结构，大可不必拘泥于教条。但goto语句可以跳到程序过程中的任一点，造成静态程序（static program）与动态进程（dynamic process）之间的差异，影响程序可读性，是要竭力避免的^[3]。”冒号如是说道，“结构化编程的思想包括两方面。在微观上，主张循规守矩，采用顺序、选择和循环三种逻辑结构，摒弃或限制goto语句^[4]，以避免杂乱无章的代码。在宏观上，主张分而治之（divide and conquer），采用‘自顶向下（top-down）’ ^[5] 的设计，通过模块化将一个较为复杂的系统分解为若干相对简单的子系统，每个子系统可以独立地进一步分解，直到容易编码实现为止。这两方面是互为因果、互为保障的——由基本结构拼装而成的系统一定是模块清晰、层次分明的；反之，系统逐步分解到最后，一定会演化成基本结构。”

叹号产生一个想法：“能从程序的流程图上看出结构化编程与非结构化编程之间的区别吗？”

“一个按结构化编程思想设计的流程图，每个模块大小适中、模块之间关系简明、模块内部线路清晰，单从视觉上就会给人一种美感。相反，如果采用非结构化的设计，流程图往往结构如杂草般松散紊乱、脉络如迷宫般错综复杂、箭头如线头般剪不断理还乱，情节严重的会导致读者头晕目眩乃至抓狂吐血。”冒号极尽夸张之能事。

众人掩口失声。

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

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

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

众现不信之色。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

问号第一个从小说里走出来，问道：“刚才谈到了低级语言和中级语言，现在该谈高级语言了吧？”

冒号微叹：“高级语言大概有近千种，流行的也不下几十种，有时候选择过多反而无所适从啊。”

逗号不以为然：“最流行的不就那么几个：Java、C++、C#还有VB吗？”

不意此言遭到冒号连珠炮似的反问：“可你知道它们为什么会流行吗？是不是学会这几样就是一个合格的程序员了？它们会不会变得不那么流行，甚至被其他语言取代？如果不会，为什么？如果会，又怎么办？”

逗号赧然语塞。

冒号口气放缓：“掌握一门语言的语法、工具和技巧固然重要，但那只相当于学会一门兵器的招法，更重要的当然是心法。招法重形，心法重意。得形而忘意，无异舍本逐末；得意而忘形，方能游刃有余。下面要谈的就是一种心法：编程范式。”

问号不解：“编程范式？听上去很学究，那是什么东东？”

冒号续道：“范式译自英文的paradigm，也有译作典范、范型、范例的。所谓编程范式（programming paradigm），指的是计算机编程的基本风格或典范模式。借用哲学的术语，如果说每个编程者都在创造虚拟世界，那么编程范式就是他们置身其中自觉不自觉采用的世界观和方法论。”

叹号吸口气：“好抽象哦！”

句号心中一动：“您是说我们都是虚拟世界的创造者，都在创造自己的黑客帝国？”

大家不禁莞尔。

冒号动情地说：“难道不是吗？只不过帝国有大小之分、优劣之别罢了。当你编程之时，便进入到自己创造的世界之中。这是你的世界，只有注入你的想象力、创造力和激情，它才有勃勃生机。你编写的岂止是代码，分明还有乐曲；你敲击的岂止是键盘，分明还有琴键；你运行的岂止是程序，分明还有世界。当优美的旋律奏起，整个世界都随之翩然起舞，一种莫可名状的满足是否会充溢你的全身？”

大家都被冒号诗化的语言感染了，没想到编程也可以如此感性。

良久，引号试探地问：“面向对象编程就是一种编程范式吧？”

冒号点头：“不错，它是时下最流行的一种编程范式。顺便说一句，‘面向对象’ 译自Object-Oriented，但‘面向’二字令人费解。据说有本书叫‘面向对象方法’，比别的计算机书都畅销，知道为什么吗？不少同学把它当成恋爱指南买走了。”

全班笑倒。

冒号认真地说：“将Object-Oriented译成‘对象导向’^[1]，虽然稍嫌拗口，但更贴切。并非刻意要咬文嚼字，这关系到对编程范式的理解。我们知道，编程是为了解决问题，而解决问题可以有多种视角和思路，其中普适且行之有效的模式被归结为范式。由于着眼点和思维方式的不同，相应的范式自然各有侧重和倾向，因此一些范式常用‘oriented’来描述。换言之，每种范式都引导人们带着某种的倾向去分析问题、解决问题，这不就是‘导向’吗？而‘面向’ 的宾语往往是预先确定的目标，如面向世界、面向未来、面向用户、面向问题等等。此外，‘面向’强调静态结果，而‘导向’强调动态趋势，显然后者更生动，也更符合编程的特质^[2]。”

句号一语惊人：“找对象是‘对象导向’的，去约会是‘面向对象’的。”

全班再倒。

句号得意地解释：“按梦中情人的标准去找对象，具体目标未定但选择倾向已定，这就是一种导向，而且是对象导向。找到之后再约会，不就面向对象了吗？”

众人称绝。

“我们是来谈编程范式的，不是来谈对象的。” 冒号一脸的道貌岸然，“编程范式是抽象的，必须通过具体的编程语言来体现。它代表的世界观往往体现在语言的核心概念中，代表的方法论往往体现在语言的表达机制中。一种范式可以在不同的语言中实现，一种语言也可以同时支持多种范式。任何语言在设计时都会倾向某些范式、同时回避某些范式，由此形成了不同的语法特征和语言风格。”