我所認識的軟件開發原則：封裝

[size=medium]
在Google搜索封裝，給出信息隱藏這樣的一個概念。把複雜度隱藏於實體內部，對外提供簡單，精練的訪問接口。這個原則普遍存在於現實生活中，在軟件開發領域也始終提倡着。Java向來倡導程序封裝，面向接口編程，以提高工程開發和維護效率。

說到封裝，讓我想起大四的一次面試經歷。面試官拋出的惟一與技術有關的一個問題是：你覺着面向對象思想的特點中，哪個特點是最重要的？ 以當時熟背面向對象思想，寫過兩三天Java程序的經驗，我很鄭重地回答：封裝。之後這次不成功的面試經歷留給我最大的疑問就是，難道封裝不是最重要的麼？

當然什麼是面向對象思想最重要的特點，以當年淺顯的認識是不敢再去探究的。時至今日，也不敢對當初的問題做出肯定的回答，但這個簡單有效的原則在軟件設計和開發過程中所使用的頻度，很明顯地確立着它的重要性。

日常開發中，頻繁使用接口對調用者隱藏邏輯實現。就是在自己的具體實現中，模塊與模塊之間做到有序封裝，這種思想可以體現在最基礎的那個方法或是那行代碼上。例如提供時間格式轉換的類，與調用者之間的聯繫就是你給我時間等參數，我給你正確的時間格式。至於具體怎樣實現，調用者不需要關注。

從最底層的邏輯實現到中層的數據包裝，再到高層的服務，層與層之間的關係變得簡單明瞭。OSI七層協議是最好的例子，每層只關注自己在數據交換中所扮演的角色：包裝上層傳入的數據；對從下層接收到的數據做解包裝。研究網絡不同領域的技術人員只專注於不同的處理層，對於每層邏輯實現的變更，不會影響與其它層的數據傳輸接口。
[img]http://devcentral.f5.com/weblogs/images/devcentral_f5_com/weblogs/macvittie/125/o_osi-model-7-layers.png[/img]

對於這樣的成功的例子可以列舉出很多，但它們遵循的封裝原則是類似的。這些例子的殊途同歸預示着我們可以總結出運用封裝原則的一些基本點。下面就我最關心的一個問題做初步的分析。

[b]什麼時候開始封裝[/b]：
[list]
[*][color=darkred]模塊之間邏輯糾纏不清[/color]：這種糾纏小到底層實現，大到系統與系統，網絡與網絡的交互。 [color=blue]在代碼實現層面[/color]，我們一般使用代碼結構化封裝，如類與方法。類處理自己分攤到的系統職責，管理一系列與職責相關的具體實現。方法獨立或與其它方法配合完成任務，方法間做到責任明確，協作簡單。[color=blue]在模塊層面[/color]，各模塊管理衆多類來完成較大任務，也需要保持獨立，簡潔的數據傳遞。當然正常情況下這種模塊間的交互不是很複雜。在這裏就可以採用很多設計模式提高代碼的結構與表達能力。[color=blue]在更高層，系統或網絡之間[/color]，我們必須保證不能有複雜的邏輯交互，因爲有網絡帶寬，系統負載等條件的影響。系統之間可以傳輸簡單有效的數據。可以在響應時間，處理效率上做出讓步。
[*] [color=darkred] 責任劃分[/color]：正常情況下，系統或模塊有衆多人員開發維護。對模塊的封裝，有利於每個人理清自己的責任。
[*] [color=darkred]安全考量[/color]：對於有些涉及安全問題的模塊，如權限或機密業務數據，單獨開發維護，只對外提供基本的服務。
[*] [color=darkred]發揮專業性[/color]：每個人所擅長的領域不一樣，在模塊封裝時就可以考慮把合適的事情交給最擅長的人去做。比如項目需考慮業務處理時效率，就可以編程語言來劃分不同的模塊達到有效交互的目的。
[*] [color=darkred]降低使用複雜度[/color]：用戶始終需要最簡潔方便的交互。一個只會QQ聊天的用戶只應該覺着上網如此簡單，而不在乎這個東西到底是多麼的紛繁複雜。程序與程序之間，暴露過多內部實現細節，會讓調用者無比困惑。[/list]
上面說了太多封裝原則的好處，至少讓我覺的，這個簡單的原則可以適用於任何地方。就是非要找它的缺點，以我的理解應該有這樣一些方面：
[list] [*][color=darkred]增加學習成本[/color]：對於想了解系統或模塊具體業務實現的人來說，層層封裝顯得過於封閉。愛因斯坦拆鬧鐘的時候也許非常急躁吧。
[*] [color=darkred]封裝的異常情況[/color]：把檯燈插到插座上沒亮，經過很多測試，得出是插座的問題。那到底是插座裏面的線斷掉了還是插座的接線斷掉了，無從得知。模塊接收到調用者的請求後如果沒法處理數據，應該怎麼辦?把任務拋棄什麼也不做，還是返回錯誤狀態告訴調用者這裏出錯了。這些錯誤情況的處理方式 對於調用者來說有着很大的區別。如果能返回正確有錯誤狀態，那麼調用者就可以做相應的異常處理機制。否則會很莫名，只有千萬百計深入到模塊內部查看問題。[/list]
其實呢，對於這樣一個普遍的原則，過多的解釋和定義是不恰當的，有引簡爲繁的誤解。但歸根結底，我想表述的是這種原則的重要性。無論在是生活還是在編碼中，處處可見它的身影，讓我體會到很多益處。物極必反，過多使用封裝也有增加程序的複雜度。[/size]


[size=medium][url=http://langyu.iteye.com/blog/746179] 我所認識的軟件開發原則：權衡[/url]
[url=http://langyu.iteye.com/blog/745053] 我所認識的軟件開發原則：簡單表述[/url]
[url=http://langyu.iteye.com/blog/744442] 我所認識的軟件開發原則：二八原則[/url]
[url=http://langyu.iteye.com/blog/745296] 我所認識的軟件開發原則：減少等待時間[/url][/size]