自從完成「Jollen 的 Android Framework Complete (框架大全) 課程」後，對於軟體設計領域有了更深一層的認識，並且發現許多軟體設計的美麗之處。接下來的工作，除了過去近十年的系統程式領域，也打算在軟體設計領域繼續提升。系統程式(systems software)的技術工作，除了需要大量的經驗累積外，還需要「手感」；這點相信有經驗的系統程式高手，都有同感，所以必須保持不斷的接觸程式碼。系統程式領域廣大，包含：kernel、device drvier等，這些都是筆者過去相當有興趣的主題；所謂的「手感」就像是寫文章，需要偶而一點靈感才行。

系統程式領域，主題與範圍一般都較為明確，例如：kernel。軟體設計領域，範圍更大，所涉及的知識也更多，例如：網路、使用者。無論是系統程式，或是軟體設計，都會有共同的背景知識，例如：物件導向(Object-oriented, OO)。

初學 kernel 或 device driver 的開發者，或許不會知道 kernel 本身就是物件導向的設計；實務上，如果專注在工程面(Engineering)，其實也不太需要深入了解 kernel 與物件導向的關係。所以在 kernel 與 device driver 領域，物件導向是 implicit，隱性的。

在軟體設計方面，例如：Android framework，如果不了解 subsystem 的物件導向設計，以及設計模式(Design pattern)，並不太容易看懂其程式碼(Source code)，並且幾乎影響了後續工程工作的進行。所以在 Android framework 領域，物件導向是 explicit，顯性的。

這就是過去幾年為企業進行相關教育訓練時，有些主題我會特別強調 Object-oriented 與 design pattern，有些主題僅介紹機制與作法(practice)的原因。這是老師的責任，評斷並決定主題的切入點以及重心。例如，最近在介紹 Android 的 graphics system 時，我就會特別說明 Surface 與 SurfaceHolder.Callback 的 MVC 模式。

Implicit of Object-oriented

所以，並不是作業系統不需要用到物件導向觀念，也不是物件導向觀念是用在大型軟體開發上(有些教科書的說法)。而是，在某些時候，它是相當 implicit 的。原創者(Creator)將物件導向的觀念封裝到非常好，好到使用者(Users/coders)只需要照圖施工，就可以保證成功。最好的例子，就是 Linux kernel。

將View與Control切割是軟體設計的根本。這個觀念非常的好懂，也是學習軟體設計的基本功。View被解釋成UI等可見物，Control則是控制功能，例如：關機。一般來說，控制功能由控制者提供，所以經常被稱為View/Controller模式。

這個觀念真的簡單不過，把畫面與控制功能分開。這個觀念的發展始於 1980 年代，當時為了開發圖形介面的電腦，電腦科學家於是想到「 Separated Presentation」，也就是從事視覺(Presenetation)的程式碼就只做視覺(例如：Drawing)，把其餘的切割(separated)出來。後來形成今天家喻戶曉的軟體設計模式 - MVC(Model-View-Controller)。

把View與Controller切割的觀念被一直沿用到今天，所以先想清楚View/Controller為什麼切割，原因何在？才是重點。「Model」是擴充出來的觀念(Concept extending)，所以，可以先將「Model」是什麼放著不談。

將View與Controller切割是為了不讓控制的動作影嚮到畫面(View)，根本原因是希望有更好的使用者體驗。做法很簡單，從現今的分時多工作業系統(Time-sharing & multi-task operating system)角度來看，只要切割成獨立的process即可。如圖1.1。

二個process就使用訊息(message)傳遞的方式溝通，也就是我們所熟悉的IPC(Inter-process communication)。

切割 View & Control

Android 系統將 View & Control 切割，因為這樣可以設計出 UI 使用性更好的軟體。同時還有二個好處。第一、讓程式碼更容易維護，第二、軟體架構更清楚。為什麼將 View 與 Control 切割成獨立的 process，可以讓 Android 系統有更好的 UI 使用性呢？

Linux 核心是 implicit of object-oriented 的典型實例。例如，在開發驅動程式的過程中，雖然不需要特別了解驅動程式的物件導向架構，但其架構則是依循嚴謹的物件導向觀念。Linux 核心與驅動程式，都是以 C 語言實作。

另外一個例子，就是筆者在 Android Framework & HAL 課程中所提到的 HAL Stub 觀念。HAL Stub 可採用 C 語言實作，編譯後以 *.so 形式佈署，但它不是程式庫(Library)，而是一個物件(Object)。

圖1.2 HAL Stub 架構

HAL 的模組稱為 Stub，Stub 是一種物件。Stub 在軟體工程領域代表「樁」的角色，也就是整體架構中的一小段基礎程式碼，這段程式碼有著以下二個特色：

1. 符合架構的程式碼（打地基）
2. 一段程式碼範本，最終的實作 (final implementation) 是代理人 (proxy) 的角色

但是，Android 將上述的物件導向封裝得非常好，不需要懂這些架構面的觀念，也能依循「步驟」實作出基本的 HAL Stub。

在軟體裡加上自已的實作，最重要的第一門課就是練習寫「樁」，也是打地基的程式碼。所以，我們要知道 Android 的整體架構，並依循其架構，設計並實作自已的 HAL Stub。由此可知，從事 Android 軟體整合開發，重要的背景知識是物件導向、軟體工程與 HAL 架構，而不是硬體的知識。另外，還有很重要的背景知識，就是如何以 C 語言實作物件導向設計。

步驟性的知識可以解決部份的工程(實作)問題，但因為缺乏系統性的觀念，將會影響解決整體性問題的能力。這就是「隱性物件導向」的概念，大部份我們接觸過的軟體，都是嚴謹的物件導向設計，只是因為它被封裝得很好，所以常常會忽略它，或是認為它不存在。

有一種誤解，可以說明這個現象。有些工程師，會誤以為使用 C 語法實作的軟體，並不是物件導向的架構，實則不然。Linux 核心便是一個很好的例子。Axel-Tobias Schreiner 在 1993 年發表了著作「Object-oriented programming with ANSI-C」，解釋了如何使用標準 C 語言 (ANSI C) 撰寫物件導向程式碼；國外有些大學，甚致將這個科目列為必修課。

因此，C 語言是隱性的物件導向程式碼，因為它不像 C++ 或 Java，有著明顯的物件導向語法特徵。這點對於研究工作其實是個麻煩，因為 C 語言沒有鮮明的物件導向語法，所以經常需要花費時間，來探索隱藏其中的物件導向設計。

JavaScript 是「王者再臨」的最佳代言人，由於 jQuery 被大量應用在網頁設計上的原因，讓 JavaScript 再度被重視了起來；再加上 HTML5 的推波助瀾，JavaScript 儼然成為今年最受矚目的程式語言。

現在，JavaScript 的主要用途，已經由過去的動態網頁（Dynamic Webpages），轉為開發 HTML5 App 角色；也就是 HTML5 的應用。我們不僅僅使用 JavaScript 製作有動態效果的網頁，還藉助它來開發大量的 UI interactive、使用者體驗的設計，以及，最重要的雲端服務的整合。

還有一個很重要的應用，就是「JavaScript in Browser」，也就是利用 JavaScript 來增強瀏覽器的功能，最為大家所熟悉的例子，就是 Google Chrome。Google Chrome 為了增強對 JavaScript 的支援與效能，開發了新的 JavaScript 引擎；在日記「HTML5在手持裝置將開始爆發式成長」就提到了，「JavaScript引擎的成熟度是關鍵」。

所以，測試 JavaScript 的使用案例（Use Cases）在各大瀏覽器的效能，更為一項重要的工程工作。目前被軟體工程師廣為使用的 jsPerf 就是為此而生。更進一步地，由於 JavaScript 現在搭配 HTML5 來開發「軟體」，而不只是用來製作動態網頁，所以研究 JavaScript 的軟體設計模式，當然也就變成一門顯學；目前被廣為推薦的就是「Essential JavaScript Design Patterns」一書。

JavaScript 過去曾經在動態網頁製作上紅極一時，後來又迅速沈寂，2003到2007年這段時間，應該是 JavaScript 最谷底的時候。而後在 2007 到 2009 年，因為 Web 2.0 風格網頁，以及 jQuery 的盛行，再度得到開發者的重視。2010 到 2011 年因為 Mobile Native App 的大量流行，使得眾多開發者不再以 JavaScript 做為首選，再度走入低潮。

時間到了 2012 年，在 HTML5 時代正式啟動的今天，JavaScript 成為軟體工程師的必修語言，也是程式設計初學者的最佳選擇。從去年大約 1.5% 的使用率，飆升到這個月的 3.3% 左右的使用率。雖然它不是最受歡迎的程式語言，但是在「Browser & Webpages」的領域，頗有王者再臨的感覺。

先前在「Jollen 的 Android Framework Complete (框架大全) 課程發表、外加感想」提到了想把 Jollen's AFC 寫成一本書的構想，現在開始付諸行動了。學生時代寫書，其實也不是為了寫書而寫，大多是平常做技術的零碎紀錄，再匯集而成。在看到自已的成果出版成實體書時，內心可是無比的感動與激動，要特別感謝旗標出版社當時給了我這麼好的機會。

這次，也打算開始整理手邊的資料，慢慢匯整成一本書，並且一邊整理，一邊上線。這就是數位內容的好處，不用一次全寫完再出版。新書的書名也未定，所以暫且叫做「Jollen's AFC」吧。不過，這次不打算出版實體書，原因有三：

1. 這是冷門書。內容不在迎合業界需求，而是希望寫出真正自已想像中的作品。

2. Light-weight content，頁數鎖定在 200 頁上下。簡單說，出版社考量實體書售價（根據頁數），以及管銷成本等，應該也不願意出版。

3. 不能 Print on demand，也就是不能「隨選列印」。有時讀者可能只想看，並且列印部份內容而已。

近二年，原文書掀起一股輕量級風，越是有深度、越是複雜的技術，內容就更輕量級。這種書的優點是，讀起來全不費工夫，而且一氣呵成，暢快無比。缺點是，底子不深，就很難啃，自已也踼過幾次鐵板。寫出這種書的作者，必定底子深厚，而且把知識融會貫通得很好。我決定多磨練一下功力，挑戰這種輕量級的寫作。

輕量級寫作的重點，在於頁數少，或是字數少。不過，最不重要的就是它的頁數或字數，而是內容的價值。輕量級的書，就是「底子不深不好啃」的概念，看起來小小一本，質量卻很大，讀起有重量。中文電腦書流行的磚頭書概念，也是經常有不錯的作品，但是請避免看起來很大，讀起來卻很輕的現象。例如，連續20頁都是程式碼（Source code listing）。

其實網路上有許多優質的短篇內容，但並不利於做實體出版，就算要出版，出版商也會請作者想辦法補到一定頁數。於是，為了補頁數、趕截稿，作者只好草草做工，所以最後的章節，也就草草了事。非常可惜。

為了不讓短篇內容，被出版商裝上義肢，所以 Amazon 就提出了一個解決方案。線上自助出版平臺。

Amazon 把這類有價值，字數介於一萬至三萬字間的短篇（小品），稱為 Single，並且搭配 Kindle Fire 推出了一個獨立的 Single 線上自助出版產品線。

所以，「Jollen's AFC」將考慮數位內容與數位出版。曾幾何時，實體出版居然變成作者的 Last choice。

最經常使用的物件導向觀念就是繼承(Inherit)，使用C語言如何實作繼承？最實用的例子就是 Android HAL。以下圖為例，這是一個標準的 HAL Stub 設計。這個例子試圖在原有的 Android 作業系統裡加入一個「LED Stub」，透過 LED Stub 來控制底層的 LED 硬體。

圖1.3是一個標準的繼承設計，也就是說，在設計 HAL Stub 時，需要重用 hw_module_t 設計。從架構設計的角度來看，我們進行設計重用的工作，以擴充出 LED Stub；錯誤做法是，直接修改原有的 hw_module_t 設計，以達到原本的要求。上述觀念，就為設計重用(Design reuse)，這是軟體工程領域相當重要的知識。


圖1.3 HAL Stub設計重用

在開發 Android 系統時，會不斷地 reuse 原有的設計，以擴充出想要的功能。

以標準 C 語言實作圖1.3的方式如下：

1. 以資料結構(Data structure)來描述類別(Class)
2. 以資料結構的第一個欄位(First field)，來表示繼承

所以圖1.3的意思是 led_module_t 繼承 hw_module_t，用 C 語言來實作，結果如下：

struct led_module_t {
   struct hw_module_t parent;
};

C語言沒有明顯的物件導向語法，因此以C語言實作物件導向的繼承，又是另一個Implicit of object-oriented的例子。