Thinking in Current Paradigms, Platforms, Frameworks, and Libraries

一、我們要解決的問題

• 功能的描述、表達，即功能的實現

• 結構的描述、表達，即功能的組織

• 業務的描述、表達，即最終的目標

二、我們對功能的描述、表達

• 開始，人們用指令封裝了電路來表達功能

• 後來，人們用函數封裝了指令來表達功能

• 再後來，人們用庫封裝了函數來表達功能

• 那麼現在，我們用什麼來封裝庫去表達功能呢？【問題一】

三、我們對結構的描述、表達3.1，programming principles

• 開始，人們用文字來描述簡單、正確、靈活、高效的有關軟體結構的principles，如“模組化”、“松耦合和高內聚”，“抽象和實現隱藏”，“封裝變化”等，可是，依然存在不合理的結構

• 於是後來，人們強化了程式設計語言來支援這些principle，並發明了各種paradigms

3.2，programming paradigms

在大英百科全書關於“分類學理論”中提出：人類在認識和理解現實世界的過程中，普遍運用著三個構造法則： 區分對象及其屬性，例如，區分一棵樹和樹的大小或空間位置。 區分整體對象及其組成部分，例如，區分一棵樹和樹枝。 不同對象類的形成及區分，例如，所有樹的類和所有石頭的類的形成和區分

• 人們在表達軟體的結構方面，已經使用了結構化編程，物件導向編程、函數式編程、泛型程式設計、及各種產生式編程等

• 結構化編程固化了人們認識世界的第二個法則：區分整體對象及其組成部分

• 物件導向則補充了第一和第三個法則，強化了第二個法則

• 如果分類是正確的，那麼似乎物件導向的表達能力已經足夠了，為什麼還需要函數式、泛型、AOP之類的呢？

• 我們運用一下系統化的思維方式，那麼可以發現，物件導向其實是一種“meta paradigm”，而我們日常所說的物件導向其實是“業務空間的物件導向”，泛型和函數式則是“演算法空間的物件導向”,而AOP則可理解為“結構空間的物件導向”

• 那麼現在，我們最需要什麼空間的物件導向？【問題二】

3.3，object oriented principles，idioms，and patterns

• 開始，人們用文字來描述oo paradigm中有關軟體結構的principles，如“Liskov替換原則”、“開放封閉原則”、“依賴倒置原則”等，可是，依然存在不合理的結構

• 於是後來，人們發明了各種idioms和patterns，來支援這些principles

• 但再次，idioms和patterns依然只是用文字來描述，如Effective xxx，GOF，POSA，PEAA等，因此依然存在不合理的結構

• 於是後來，人們發明了直接的語言特性來固化各種idioms和patterns，如Java的“synchronized”固化了“scoped lock idiom”，“monitor object”(POSA2)等

• 但被固化的只是少數簡單的idioms和patterns，那麼現在，我們用什麼來固化複雜的idioms和patterns，以消除不合理的結構呢？【問題三】

四、我們對業務的描述、表達

• 做過圖形映像領域、做過通訊領域、做過資訊管理領域，但用的都是同樣的或類似的程式設計語言，而它們都是面向實現的

• 那麼，我們應該用什麼去直接描述業務呢？【問題四】

五、後模式時代

• 先來看【問題三】，目前主流的思想是非形式化的模式語言，或模式系統，並認為模式的每一次具體實現都可以有略微的變化；這或許是對的

• 但同一個project中，重複的程式碼片段被認為是bad smell，並使用idioms和patterns消除，那麼，不同project中，相似或相同的程式碼片段算不算整個軟體開發領域的bad smell呢？

• 再來看【問題三】，各種framework做出了另外一種回答，包括.Net和J2EE，而印象最深的，則是loki和spring，便是本身基於各種模式開發，並提供了一個基於模式的開發平台

• loki用模板元編程自動於編譯時間建立了各種pattern的骨架，基於loki編程，只需要編寫特定pattern的單個組成部分，然後作為參數傳遞給loki，便會得到各種合理的結構

• spring用Java元編程和配置，實現了IoC模式和Interceptor模式（POSA2，AOP便是一種自動化的Interceptor模式的實現），基於IoC和AOP，spring又進一步固化了原廠模式，代理模式，職責鏈模式，觀察者模式等；如果決定使用spring編程，則應該盡量使基礎架構基於spring，而不是僅僅在局部使用

• 然而尚有許多模式沒有流行的framework將其固化、沒有被發現，我們尚需完整模式，並且基於庫的解決方案導致我們再次得到【問題一】，那麼什麼技術能夠使模式退居幕後，讓我們感覺不到它們的存在呢？或者其實是無處不在，進入後模式時代呢？【問題五】

六、解決方案空間

• 再來看【問題二】，我們最終是要解決問題，因此姑且將最需要的空間稱之為解決方案空間，姑且令其包含“描述”和“實現”兩部分，姑且將目前的各種paradigm都劃作“實現空間”

• 那麼如此姑且之後，“描述空間”的物件導向的paradigm該是什麼呢？【問題六】

七、最終的幾個問題，後編程時代

• 【問題一】，我們用什麼來封裝庫去表達功能呢？

• 【問題四】，我們應該用什麼去直接描述業務呢？

• 【問題五】，什麼技術能夠使模式退居幕後，讓我們感覺不到它們的存在呢？或者其實是無處不在，進入後模式時代呢？

• 【問題六】，“描述空間”的物件導向的paradigm該是什麼呢？

• 呵呵，莫非是DSL和LOP？