從介面層次運用元件，增加程式產能

自從物件導向的設計方法流行以來，許多物件導向設計中的重要觀念，一直被程式人們奉為圭臬，而資訊隱藏（Information Hiding）以及封裝（Encapsulation）的想法，更是深深影響到程式人們設計的態度。

元件式的軟體開發，幫助程式人快速組裝應用程式
封裝的目的是希望透過介面，隱藏物件實作的細節，透過能見度（Visibility）的控制，降低物件與使用物件的程式碼之間的耦合程度。元件式的軟體開發（Component-Based Software Development）更進一步發展了封裝的觀念。在元件式的軟體開發下，希望將軟體單元都封裝成為元件，每個元件皆有規格，而元件的使用者則毋需了解元件內部如何實作，只需依據元件公開的規格介面，加以控制及使用元件。

此種基於元件的開發方式，優勢便在於能夠將開發中可重複使用的軟體單元，封裝成元件，之後便可透過「組裝」現成元件的方式，更快速地完成應用程式的開發。在此種模式的理想情況下，會有專門的角色開發個別的元件，而應用程式的開發者，只需從型錄中挑選所需，接著加以組裝，便能輕易地打造出應用程式。這樣的模式，倘若真能落實，不僅可以透過再利用，節省無謂的重複性開發，也可以大幅提升開發效率，更有利於日後的維護。

有人用「軟體IC」一詞說明元件式開發的元件，足以準確地描述人們對此種開發方式的期待。許多有名的技術，諸如OMB的CORBA、昇陽的EJB、以及微軟的COM，都是奠基於元件式開發的技術。

元件式開發的重點：規格化及介面化元件
這種開發模式有一個重點，是要讓元件規格化及介面化。每個元件都有所遵循的規格，元件的使用者只會依據這份規格，撰寫與之相溝通的程式碼，而不會碰觸到元件確切的實作方式。

例如，當你使用微軟的DirectShow架構開發多媒體應用程式時，你會留意到，DirectShow的架構是一種基於元件的架構。在DirectShow中，播放一段影片或音樂時，得先建立一個IFilterGraph的實作，裡頭是許許多多的IFilter實作物件，相互以IPin連接，而多媒體的資料就從IFilterGraph中最前端的IFilter（也稱為source filter）開始沿著IFilterGraph中的IFilter流動。

每個IFilter的實作本身都有獨特的作用，例如它可能是一個MP3的解碼器，從輸入的IPin收到MP3的音訊內容後加以解碼，並且利用輸出的IPin傳送至下游的IFilter實作。

在DirectShow的命名慣例下，不論是IFilterGraph、IFilter、IPin等名稱，首字的 「I」，皆意謂它們都是代表介面（Interface），對開發DirectShow應用程式的程式人而言，他們在概念上，並不理會每個IFilter實際上究竟是如何實作的，只要該IFilter的實作輸入之IPin及輸出的IPin，能夠滿足需求即可。所以，應用程式開發者和元件開發者（開發IFilter及IPin實作品的人），各司其職。

採取這樣架構的優點之一是，或許你現在正採用某一家廠商所開發的MPEG 4解碼器，只要這個解碼器符合IFilter的介面，那麼你便可以將它輕易地更換成另一家廠商所開發的MPEG 4解碼器，而不會對原有的應用程式產生任何衝擊和影響。

對你的DirectShow應用程式來說，只不過是將若干個個別作用不同的元件（IFilter）組裝在一塊，並使之依據你所期待的方式運行罷了。因此，DirectShow的架構，充份地發揮元件式開發的優點，也彰顯了特色所在。

使用軟體元件，必須克服想要探究細節的好奇心
你會注意到，元件式的開發，為了達到具彈性、輕易的組裝方式，它更為強調封裝的重要性。在現今我們所從事的開發中，就算沒有完全依據元件式的開發方式，也深受元件式開發的觀念所影響，極力朝向更進一步的封裝而努力。

我們可以觀察到現今的應用軟體開發，越來越有生產力，人們所建立的系統越來越龐大，而建造速度也越來越快。我們能夠克服軟體開發時的驚人複雜度，其中將軟體單元做某種程度的元件化，可說影響很大。

如今，我們想開發各種應用軟體，充斥著各種現有的元件，舉凡視訊、音訊的編解碼、3D的繪圖、網路通訊、資料庫處理及各類數學運算等，都因為元件化的特性，使應用程式的開發者得以輕易將它們整合到自己的應用程式，因而在很短的時間內完成應用程式開發。

另一方面，想要設計出元件化的軟體，程式人得具備一定的設計能力。程式人得學習如何適當地抽象化，他必須決定元件中有那些是不欲外界所知悉的實作細節，並且將它們隱藏起來，也必須決定對外公開的介面應當容納那些元素，以提供個人端程式人所需。

若想要使用軟體元件，個人端程式人必須克服自己想要探究每一個細節的好奇心，他必須將自己檢視軟體的焦點，擺在適當的抽象層次上。也就是說，他必須讓自己學會以介面的角度，看待每個軟體元件，站在介面層次運用每個元件。這也正是我們不斷提起的「針對介面撰寫程式，而不要針對實作」的設計原則。

我們時常會說，「你可以把XXX模組或YYY子系統，當做是一個黑盒子」，便是利用「黑盒子（Black Box）」一詞指涉那些被我們封裝起實作細節的軟體元件。這個詞十分傳神地表達出封裝的概念。

一名程式人，要學會將他人或自己所設計軟體元件視為黑盒子，需要一些訓練。有許多初學的程式人，總是試著在運用元件前搞清楚它的細節，或者是在設計自己的元件時曝露太多的細節，這違反了封裝的原始精神及用意，而且對於應用程式的開發也沒有多大的用處。

越是擅長設計的程式人，越能設計合宜的黑盒子
軟體的黑盒子，基本上便是設計者的抽象化產物，抽象化的程度及方式，決定了黑盒子所包裝的範圍及空間大小。越是擅長設計的程式人，越能設計出合宜的黑盒子，供自己及他人使用。

而個人端程式人在將軟體元件視為黑盒子時，也是同樣以一種抽象的眼光，去看待所面對的元件。這意謂著客戶端程式人是以一種更高階、更一般化的方式，思考應如何撰寫程式碼，而寫下的程式碼也將具備更多抽象、更少具象實作的特質，使得這些程式碼更為一般化，也能搭配更多可能的實作而毋需更動。

如此將軟體元件視為黑盒子的設計方式，可以說是許多主流的設計觀念，例如重複使用、多型、封裝及介面化所結合在一起的產物。當越能自在地以這些觀念從事設計時，你會發現所做的設計以及看待這些設計的方式，已經全然黑盒子化了。

透過這樣的設計方式，你可以輕易地重複使用別人所設計的元件，並且直接獲得生產力的補充。在建立自有元件時，可以藉此阻隔不必要的實作細節，撰寫出更一般化的程式碼，更具因應變動的能力，同時更容易擴充。當程式人放棄探究隱藏在黑盒子中的細節，上述好處都是所收到的回報。

作者簡介─王建興
	清華大學資訊工程系的博士研究生，研究興趣包括電腦網路、點對點網路、分散式網路管理、以及行動式代理人，專長則是Internet應用系統的開發。曾參與過的開發專案性質十分廣泛而且不同，從ERP、PC Game到P2P網路電話都在他的涉獵範圍之內。