Example Android

Android是Google推出的智慧手機作業系統，在其官方文件中有Android的系統架構圖：

這幅圖中很好地反映了上文中提到的軟體層次。整個系統從底層到高層分為Linux kernel， Libraries/Runtime，Application Framework，Applications。最底層的Kernel可以說與應 用完全不相關，直到最上層的Applications，才提供手機諸如聯絡人、打電話等應用功能。

每一層中，又可能分為若干相互獨立（Again，沒有絕對）的模組，例如Libraries那一層 中，就包含諸如Surface manager/SGL等模組。它們可能都依賴於Kernel，並且提供介面給 上層，但彼此獨立。

Example Compiler

在編譯器實現中，也有非常明顯的層次之分。這些層次可以完全按照編譯原理理論來劃分。 包括：

• 詞法分析：將文字程式碼拆分為一個一個合法的單詞
• 語法分析：基於 詞法分析 得到的單詞流構建語法樹
• 語義分析：基於 語法分析 得到的語法樹進行語義上的檢查等
• 生成器：基於 語義分析 結果（可能依然是語法樹）生成中間程式碼
• 編譯器：基於 生成器 得到的中間程式碼生成目標機器上的機器程式碼
• 連結器：基於 編譯器 生成的目的碼連結成最終可執行程式

軟體分層的好處之一就是對任務(task)的抽象，封裝某個任務的實現細節，提供給其他 依賴模組更友好的使用介面。隔離帶來的好處之一就是可輕易替換某個實現。 例如很 多UI庫隔離了渲染器的實現，在實際使用過程中，既可以使用Direct X的渲染方式，也可 以使用OpenGL的實現方式。

但正如之前所強調，凡事沒有絕對，凡事也不可過度。很多時候無法保證軟體層之間就是單 向依賴。而另一些時候過度的分層也導致我們的程式過於鬆散，效率在粘合層之間繞來繞去 而消失殆盡。

Example C中的模組組織

很多C程式碼寫得少的C++程式設計師甚至對一個大型C程式中的模組組織毫無概念。這是對其他技 術接觸少帶來的視野狹窄的可怕結果。

在C語言的世界裡，並不像某些C++教材中指出的那樣，佈滿全域性變數。當然全域性變數的使 用也並不是糟糕設計的標誌(goto不是魔鬼)。一個良好設計的C語言程式懂得如何去抽象、 封裝模組/軟體層。我們以Lua的原始碼為例。

lua.h檔案是暴露給Lua應用（Lua使用者）的直接資訊源。接觸過Lua的人都知道有個結構體 叫lua_State。但是lua.h中並沒有暴露這個結構體的實現。因為一旦暴露了實現，使用者就 可能會隨意使用其結構體成員，而這並不是庫設計者所希望的。 封裝資料的實現，也算 是構建模組化程式的一種方法。

大家都知道暴露在標頭檔案中的資訊，則可能被當作該標頭檔案所描述模組的介面描述。所以， 在C語言中任何置於標頭檔案中的資訊都需要慎重考慮。

相對的，我們可以在很多.c檔案中看到很多static函式。例如lstate.c中的stack_init。 static用於限定其修飾物件的作用域，用它去修飾某個函式，旨在告訴：這個函式僅被當前檔案（ 模組）使用，它僅用於本模組實現所依賴，它不是提供給模組外的介面！ 封裝內部實現 ，暴露夠用的介面，也是保持模組清晰的方式之一。

良好的語言更懂得對程式設計師做一種良好設計的導向。但相對而言，C語言較缺乏這方面的語 言機制。在C語言中，良好的設計更依賴於程式設計師自己的功底。

Example Java中的模組組織

相較而言，Java語言則提供了模組化設計的語法機制。在Java中，如同大部分語言一樣，一 般一個程式碼檔案對應於一個程式碼模組。而在Java中，每個檔案內只能有一個public class。 public class作為該模組的對外介面。而在模組內部，則可能有很多其他輔助實現的class ，但它們無法被外部模組訪問。這是語言提供的封裝機制，一種對程式設計師的導向。

Example OO語言中類介面設計

無論在C++中，還是在Java中，一個類中的介面，都大致有各種訪問許可權。例如public、 private、protected。訪問許可權的加入旨在更精確地暴露模組介面，隱藏細節。

在C中較為缺乏類似的機制，但依然可以這樣做。例如將結構體定義於.c檔案中，將非 介面函式以static的方式實現於.c檔案中。

OO語言中的這些訪問許可權關鍵字的應用尤為重要。C++新手們往往不知道哪些成員該public ，哪些該private。C++熟手們在不刨根挖底的情況下，甚至會對每個資料成員寫出get/set 介面（那還不如直接public）。在public/private之間，我們需要做的唯一決策就是，哪些 資料/操作並非外部模組所需。如果外部模組不需要，甚至目前不需要，那麼此刻，都不要 將其public。一個public資訊少的class，往往是一個被使用者更喜歡的class。

（至於protected，則是用於繼承體系之間，類之間的資訊隱藏。）

Example Lisp中的模組設計

又得提提Lisp。

基於上文，我們發現了各種劃分模組、劃分程式碼層的方式，無論是語言提供，還是程式設計師自 己的應用。但是如何逐個地構建這些層次呢？

Lisp中倡導了一種更能體現這種將程式碼分層的方式：自底而上地構建程式碼。這個自底而上， 自然是按照軟體層的高低之分而言。這個過程就像上文舉的編譯原理例子一樣。我們先編寫 詞法分析模組，該模組可能僅暴露一個介面：get-token。然後可以立馬對該模組進行功能 測試。然後再編寫語法分析模組，該模組也可能只暴露一個介面：parse。語法分析模組建 立於詞法分析模組之上。因為我們之前已經對詞法分析模組進行過測試，所以對語法分析的 測試也可以立即進行。如此下去，直至構建出整個程式。

每一個程式碼層都會提供若干介面給上層模組。越上層的模組中，就更貼近於最終目標。每一 層都感覺是建立在新的“語言“之上。按照這種思想，最終我們就可以構建出DSL，即Domain Specific Language。

分層的好處

基於以上，我們可以總結很多程式碼分層的好處，它們包括（但不限於）：

• 隱藏細節，提供抽象，隱藏的細節包括資料的表示（如lua_State）、功能的實現
• 在新的一層建立更高層的“語言”
• 介面清晰，修改維護方便
• 方便開發，將軟體分為若干層次，逐層實現

一個問題的解決

有時候，我們的軟體層很難做到單向依賴。這可能是由於前期設計的失誤導致，也可能確實 是情況所迫。在很多庫程式碼中，也有現成的例子。一種解決方法就是通過回撥。回撥的實現 方式可以是回撥函式、多型。多型的表現又可能是Listener等模式。

所有這些，主要是讓底層模組不用知道高層模組。在程式碼層次上，它僅僅儲存的是一個回撥 資訊，而這個資訊具體是什麼，則發生在執行期（話說以前給同事講過這個）。這樣就簡單 避免了底層模組依賴高層模組的問題。