【來龍去脈】
衆所周知，一臺最常見的PC往往由主板、CPU和各種芯片板卡(如內存、聲卡、網卡、顯卡等
)等組件組成。所有的組件可以分別由不同的生產商遵循確定的電氣指標和接口標準並行開發和生產。生產完成後，只要按照接口要求，接駁集成在一起，基本就可以正常工作了。這是一種多麼成熟且高效的生產流程啊！
反觀目前的軟件開發，成熟度和效率要低很多。雖然，在軟件開發領域也提出並正在運用組件式的開發，但是其成熟度和效率，相比於硬件工業的效果仍舊差距顯著。筆者認爲重要的原因之一是很多軟件組件之間存在着不必要的物理耦合(例如在代碼層面指名道姓地進行調用
)，最典型的是編譯期耦合。打個比方，A組件的功能，邏輯上需要依賴B組件，B以某種庫的形式存在。在A的開發過程中，其編譯、鏈接以及模塊測試的運行，往往嚴重依賴於B的現場存在，例如需要B的頭文件，或者是lib文件、dll文件、jar文件等
，不一而足。這種物理上的耦合，牽制了AB雙方的開發活動，明顯降低了效率，並在耦合環節爲bug的產生埋下了伏筆
。另一方面，在產品的維護上也提高了成本、降低了效率，最糟糕的情況下，甚至會造成牽一髮而動全身的效應
。這是軟件工業普遍存在又亟待解決的根本性問題之一。
【創新暢想】
針對這種困境，讓我們大膽地暢想一下，如果軟件工業可以實施像硬件工業一樣的開發、生產方式，這將是一種多麼令人憧憬的場景啊。我相信，這種深度解耦的模塊化、分工合作、並行開發
的模式，必將是軟件工業的大趨勢。因此，雖然目前還沒有一種成熟的思想和技術可以實現這樣的場景，但我們軟件行業的從業者應該始終朝着這個方向不懈的努力，使這個目標儘早得以實現。這個目標的實現，是軟件工程師勞動力、創造力的解放，也是軟件工業生產力的革命性飛躍。
正是基於以上的這種嘗試和努力的心態，基於匹夫有責的意識，在本文中，筆者試圖給出一種被稱爲“軟芯片”(softchip)
的軟件架構設計的創新思維(請恕筆者才疏學淺，這種idea早有提出也未可知
)。Softship架構設計思想的主旨是組件間深度解耦
。具體而言：
01
.在軟件架構設計上，構造一種類似“主板
”角色的基礎機制，作爲所有組件的支撐平臺。
02
.組件間的絕大部分交互將經由這種類似主板的平臺機制
(軟主板softboard
)來協調實施，組件之間幾乎不再直接“面對面”
。
03
.基本上，每個組件模塊可以獨立開發、編譯
和模塊測試
。
04
.在軟件開發過程中，存在組件開發者
和系統集成者
兩種角色。組件開發者按照系統集成者制定的功能spec和接口標準生產組件，系統集成者負責制定所有組件的功能spec(概要
)和接口標準(詳細、具體的
)以及組件完成後實施系統集成。
因筆者對於硬件原理和開發沒有深入涉獵，以上的與硬件相關的認知僅僅是一種介於感性和理性之間的粗淺的個人見解，如有偏頗，歡迎衆多業內有識之士不吝指出的同時也敬請諒解。另外，由於Python
語言的很多特性，非常天然地適合表述、展示和實施softchip的思想和技術，筆者選擇了Python作爲嘗試和實施的平臺(並非是爲了趕時髦
)。因此，本文中後續出現的各處code sample，均爲Python代碼。這些sample代碼可以確保在Windows XP(SP2) + Python 2.6
版本環境上能夠成功編譯和運行。
由於內容稍多，在結構組織上將以系列的形式推出。系列的第一篇(本篇
)主要是背景介紹和關鍵設計思想的陳述，作爲讀者理解後續內容的必要鋪墊和引子。由於筆者仍舊需要忙於家庭瑣事和開發工作，在時間上可能難以保障快速、連續地完成本系列的全部文章，敬請諒解。同時，這是筆者首次在CSDN上創建和發表技術博客，對於CSDN上的編輯環境使用方面還很不熟練，比較笨手笨腳，在各位大家面前難免顯得很簡陋、粗糙和不夠專業，也提前敬請諒解並歡迎批評指正，筆者今後會逐步改進提高。
在本篇剩餘的部分，將主要說明Softchip的設計思想。
【Softchip架構設計思想概述】
問題所在：
本文所針對的組件間的物理關聯，基本上以指名道姓地進行函數/方法調用的形式發生。調用的起因是調用者的功能，需要被調用者的支撐才能夠完成，這在邏輯上是合理和正常的。但是，邏輯上的關聯進而演變成物理上的依賴和牽制就是問題
了。設調用者爲A，被調用者爲B。在編譯(+鏈接)
期
，A可能需要B的頭文件、庫文件等，在運行期
，A往往還需要B的句柄或指向B的指針。這種編譯(+鏈接
)期和運行期的“赤裸裸”的依賴，是問題的關鍵環節，也是改善方案的關鍵着力點
。
應對方案：
Softchip架構的中心思想：
01 .堅決消滅編譯 (+鏈接 )期依賴 。將依賴關係推遲到運行期 發生(不得不發生時再發生吧 )。
02 .封着/屏蔽運行期依賴 ，由“軟主板softboard ”來實施 ，組件之間不會直接面對面，基本上都與softboard交互。
組件相互之間不需要/不會意識到對方的存在 ，即使是正在使用對方的服務或正在爲對方服務。組件們只知道向softboard
提出要求並 享用softboard提供的服務 或者是響應softboard提出的要求並提供自己的服務。
爲實現上述中心思想，具體的手法是：
01.Softboard提供運行期API綁定 機制。
多數類似基本服務的、可重入( re-entrant 的，被調用者不需要在調用前後保持任何數據，
只需在被調用期間利用輸入參數提供服務即可 )的函數/方法調用可以(或推薦 )以這種形式發生關聯。
例如，A (依賴者 )需要B (被依賴者 )的整數加法運算。則在運行期，B向softboard註冊 名爲add的服務，
A向softboard訂閱 add服務並從softboard處獲得add服務的入口(類似C中的函數指針 )，在使用時只需調用服務入口並
傳入指定參數即可。A不知道B的存在，也拿不到B的句柄或指向B的指針之類的東西，只有它需要的服務入口地址而已。
02.Softboard提供運行期 Event交換(switch)/分發(dispatch) 機制。
對於不適合使用API綁定機制的情況，可以利用event交換/分發機制發生關聯。
假設 A (依賴者 ) 需要B (被依賴者 )處理event X 。則在運行期，A向softboard註冊 爲X的生產者 ，B則註冊 爲X的消費者 。
softboard在所有的event生產者和消費者之間充當一個類似event交換機 一樣的角色，每當生產者生產出event X
之後，就投遞給softboard，而softboard根據event的dispatch關係表，查閱 並分發 給實際的消費者(也可能有多個 )。
根據event的性質，每次的event分發/交換過程可以是同步
的(生產者等待event處理完畢
)，也可以是異步
的(生產者不等待
)。
上述大意，以如下草圖演示：
通過以上的運行期API綁定和Event交換兩種手法，編譯(+鏈接)期的耦合不存在了。在運行期，所有組件都在
與softboard這一層次進行着交互，softboard就像紅娘一樣穿梭在依賴者和被依賴者之間，牽線搭橋。即使是依賴者
調用了被依賴者的API或event handler，也對對方的存在毫無意識，因爲真實的關聯都發生在softboard的幕布之後。
所有的組件都像是插在softboard的上的一個個的chip，是board上隱藏的線路暗地裏傳遞了控制或數據。而所有的chip
都是自由的，它只知道一件事情：“我插在board上，我爲board服務，board也爲我服務”。
在後續的篇章中，將逐步細化softchip架構設計的各部分細節並使用Python的sample code
來展示實際的場景和效果。大致的結構劃分是：
第二篇：Softchip的運轉場景：基於API綁定和Event分發的組件設計與實現。
第三篇：API綁定和event分發機制的設計與實現。
第四篇：Softchip框架設計思想所具備的優點和麪臨的課題。
OK，本系列第一篇到此爲止。感謝大家的關注！
Michael
2010-04-18 凌晨於上海。
注：對此係列文章感興趣的同道，可以使用Email聯絡：[email protected]