第四课 重温范式（3）
4.3汇总范式——一张五味俱全的大烙饼
形者神之质，神者形之用 ——《范缜·神灭论》
关键词： 编程范式,设计模式
摘要： 总结编程范式
？提问
l 编程范式与设计模式有什么区别？
l 编程范式的核心价值是什么？
l 总结前面介绍的编程范式，它们各自有哪些代表语言？核心概念和运行机制是什么？针对的问题和主要的目的是什么？实现原理是什么？常见的应用有哪些？有什么不足之处？
：讲解
稍事休整后，大家重新团结在以冒号为中心的周围。
问号再度发问：“编程范式与设计模式都是一种抽象的软件思想，都有一套具体的实现方法。单从字面上看，‘编程’与‘设计’、‘范式’与‘模式’的区别似乎也不太大。它们究竟有什么不同呢？”
“这个问题有点意思。”冒号颔言，“设计模式一般针对某一特定场景的问题，而编程范式针对的是广泛得多的问题领域，通常有一整套的思想和理论体系，具有全局性、系统性和渗透性，这一点在五大重要范式中显得尤为突出。因此，编程范式更普适更抽象，涉及的深度和广度也是设计模式难以比拟的。”
引号不免有些疑问：“但事件驱动式不是也能作为设计模式吗？”
冒号解疑：“这倒并不矛盾。同样的思想用在整体系统的结构设计上，则称为架构模式；用在局部模块的细节实现上，则称为设计模式[1]；用在引导编程实践上，则称为编程范式。”
句号的武侠瘾又犯了：“设计模式好比组合套路，能在一些特定场合下克敌制胜；编程范式则好比武功门派，博大精深且自成体系。”
“很形象的比喻。”冒号赞赏道，“设计模式是遵循设计原则的一些具体技巧，以保证代码的灵活性、扩展性和可重用性为目的。它重在设计，对语言一般没有要求[2]。编程范式则不同，对语言往往有专门的要求。通常所说的某某范式的语言，即指该语言对该范式在语法上有明确充分的支持，不需要借助其他的范式或工具。事实上，语言本来就是围绕其所倡导的核心范式来设计的[3]。”
逗号询问：“如果一种语言不支持某种范式，那么还能用这种范式编程吗？”
“语言不直接支持范式，只是说明它不属于该范式的语言，但还是可能求助工具来应用该范式。比如元编程可以借助Yacc或ANTLR来完成，AOP可以借助一些库或框架来实现。”冒号道，“正是依靠语言和工具的支持，编程范式得以建立起一套独特而完善的抽象机制和方法体系，从而为所倡导的世界观与方法论奠定基石。”
叹号请求：“能不能帮我们理清一下思路，把学过的范式一并汇总比较？”
不一会儿，众人面前呈现出一张表格，地毯似的覆盖了整个投影屏——
编程范式 核心概念 关键突破 主要目的 代表语言 运行机制 实现原理 常见应用 命令式/过程式（Imperative/Procedural）
命令/过程
（Command
/Procedure）
突破单一主程序和非结构化程序的限制 模拟机器思维，实现自顶向下的模块设计 Fortran/Pascal/C 命令执行 引入逻辑控制和子程序 交互式、事件驱动型系统；数值计算等 函数式/应用式
(Functional/Applicative）
函数
（Function）
突破机器思维的限制 模拟数学思维，简化代码 Scheme/Haskell 表达式计算 引入高阶函数，将函数作为数据处理 微积分计算；数学逻辑；博弈等 逻辑式
（Logic）
断言
（Predicate）
突破逻辑与控制粘合的限制 专注逻辑分析，减少控制代码 Prolog/Mercury 逻辑推理 利用推理引擎在已知的事实和规则的基础上进行逻辑推断 机器证明；专家系统；自然语言处理；语义网（semantic web）；决策分析；业务规则管理等 对象式
（Object-Oriented）
对象
（Object）
突破数据与代码分离的限制 迎合人类认知模式，提高软件的易用性和重用性 Smalltalk/Java 对象间信息交换 引入封装、继承和多态机制 大型复杂交互式系统等 并发式/并行式
（Concurrent/Parallel）
进程/线程
（Process/Thread）
突破串行的限制 充分利用资源、提高运行效率、提高软件的响应能力 Erlang/Oz 进程/线程间通讯与同步 引入并行的线程模块以及模块间的通讯与同步机制 图形用户界面；I/O处理；多任务系统如操作系统、网络服务器等；实时系统；嵌入式系统；计算密集型系统如科学计算、人工智能等 泛型式
（Generic）
算法
（Algorithm）
突破静态类型语言的限制 提高算法的普适性 Ada/Eiffel/C++ 算法实例化
（多发生于编译期）
利用模板推迟类型指定 普适性算法如排序、搜索等；集合类容器等 元编程
（Metaprogramming）
元程序
（Metaprogram）
突破语言的常规语法限制 减少手工编码，提升语言级别 Lisp/Ruby/JavaScript 动态生成代码或自动修改执行指令 利用代码生成或语言内建的反射（reflection）、动态等机制，将程序语言作为数据来处理 自动代码生成；定义结构化配置文件；IDE；编译器；解释器；人工智能；模型驱动架构（MDA）；领域特定语言（DSL）等 切面式
（Aspect-Oriented）
切面
（Aspect）
突破横切关注点无法模块化的限制 实现横切关注点分离 AspectJ/AspectC++ 在接入点处执行建议 通过编织（weaving）将附加行为嵌入主体程序 日志输出；代码跟踪；性能监控；异常处理；安全检查；事务管理等 事件驱动
（Event-Driven）
事件
（Event）
突破顺序、同步的流程限制 调用者与被调用者在代码和时间上双重解耦 C#/VB.NET 监听器收到事件通知后做出响应 引入控制反转和异步机制 图形用户界面；网络应用；服务器；操作系统；IoC框架；异步输入；DOM等
叹号怔了怔，好似被一张巨大的烙饼给噎住了。
冒号并不急于讲解，欲以静制动。
果然，逗号沉不住气了，问道：“在第一栏的编程范式及其代表语言中，为什么并发式的代表语言没有Java和C#，只有Erlang和Oz？”
“Java和C#虽然在语法和核心库中为并发编程提供了不少支持，但真正将并发范式融入基本设计理念的语言还得数Erlang、Oz这些较为冷门的语言。”冒号解释，“类似地，比起Java、JavaScript等语言来，C#和VB.NET在语言设计上对事件驱动式编程给予了更多的关注[4]，因而更具代表性。”
问号发现：“第三栏‘关键突破’的提法很特别啊。”
冒号轻捶桌面以示强调：“一种编程范式之所以能独树一帜，关键在于它突破了原有的编程方式的某些限制，带来革命性的新思维和新方法，进一步解放程序员的劳动力。这便是范式的核心价值所在。”
引号如获至宝：“这张表格浓缩了范式的精华，既是对此前知识的总结，也是对今后编程的指导，实在太有用了！”
句号显得更为冷静：“有其长必有其短。我们了解了每种范式的长处，是不是还应该了解它们各自的短处？”
冒号开始对各个范式逐一数落：“过程式编程的数据与代码脱节，不方便维护；函数式和逻辑式的开发效率一般比过程式高，但运行效率和语言表现力则有所不如；对象式编程用于数学计算、符号处理等对象特征淡薄的领域，在心理上缺乏认知基础，在运行效率上不如纯过程式，在开发效率上不如函数式；并发式编程增加了代码的复杂度，加重了程序员的负担；泛型式编程影响了代码的可读性，过度使用模块还可能造成代码膨胀（code bloat）[5]；元编程过于强大，运用不当会超出程序员的控制，宜谨慎使用；切面式编程减少了程序的可预测性和可控性，同时给代码的跟踪调试带来一定困难，还可能造成性能上的损失；事件驱动式编程虽然也能用于同步的流程应用，但毕竟机制更复杂，没有普通的流程式编程那么自然易懂。”
叹号看上去有点泄气：“您可真够绝的，先把这些编程范式一个个捧到天上，又几杆子它们一个个打下云端。”
“因其长而容己，因其短而容他，此万物之理也。”冒号忽然惜言如金，一番之乎者也地予以回应。
句号借用了一句俗话：“不怕有缺点，就怕没特点。”
冒号本欲多言，却恐众人食多伤胃，遂作结案陈词：“尽管只是管中窥豹，相信大家多少见识了编程范式的魅力之处。它们各擅胜场，有风格之别而无高下之分。作文绘画讲究形神兼备，编程也不例外。语言为形，范式为神。若能以神导形、以形传神，则看似平白无趣的程序也能写出诗画般的意境。”
一席话说得众人皆觉虽不能至，然心向往之。
，插语
[1] 因此设计模式有时被称为微架构（microarchitecture）模式。
[2] 虽然设计模式一般多用于OOP语言，但并不总是必须的，更何况大多流行语言均支持OOP。
[3] 当然随着语言的演进，也可能支持新的范式。如Java的generics是后来加入语言以支持泛型编程的。
[4] C#和VB.NET专门为事件驱动式设计了event、delegate等关键字以及一些配套的便利机制。
[5] 这里的代码不是指程序员写的源代码，而是指编译器生成的代码。
。总结
l 相比设计模式，编程范式针对的问题领域更广泛，提出的思想和方法更普适、更抽象、更系统。此外，设计模式重在设计，对语言和工具的要求不高，而编程范式需要建立一套抽象机制和方法体系，离不开语言或工具的支持。
l 编程范式的核心价值在于：突破原有的编程方式的某些限制，带来新思维和新方法，从而进一步解放程序员的劳动力。
l 正文中编程范式的汇总表格既是对此前知识的总结，也是对今后编程的指导。
l 既要了解编程范式的长处，也要了解它们的短处。
l 编程范式为神，编程语言为形，应以神导形、以形传神。
冬天已经到来，春天还会远吗?
