冒號課堂
第四課 重溫范式（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 編程范式為神，編程語言為形，應以神導形、以形傳神。
“”參考
[1] Elena Bolshakova．PROGRAMMING PARADIGMS IN COMPUTER SCIENCE EDUCATION．International Journal "Information Theories & Applications"，2005，Vol.12：285-290
[2] Amnon H. Eden，Rick Kazman．Architecture, design, implementation．Proceedings of the 25th International Conference on Software engineering ，2003：149–159