為什么我們說接口比繼承好，很重要的一個原因就是接口更加靈活，組件的依賴性更弱，同樣的，目前另一種做法則是采用一些標記性的語言來實現比接口更大的靈活度。例如基于xml的配置文件，以及J2SE1.5中將要引入的屬性。
組件的測試
組件和容器的依賴脫離為組件測試提供了一個很好的環境。我們在測試一節中討論過容器內測試往往是比較麻煩的，其原因就是在于上面所說的組件污染問題。例如在spring框架中，組件是一個標準的JavaBean，你可以直接編寫代碼來設置組件的屬性和定義組件之間的依賴關系(適用于自動化測試)，也可以把這項工作交給spring容器(適用于開發和部署)。
組件測試在測試的分類中屬于集成測試。
理解服務
在討論組件時我們談論了組件粒度的問題。當組件的粒度不僅僅限于單個對象的時候。在構成組件的多個對象中，有些對象處于組件內部，不和其它的組件交互，有些對象需要和外部組件進行交互。后一種對象起的就是服務的作用。在設計模式中，這種設計被稱為Fa?ade模式。而在OO語言中，他們相當于接口的概念。不管如何比喻，服務訂立了組件和組件之間的契約。這種契約是穩定的(如果業務需求是穩定的)，不會隨著組件內部的變化而發生變化。
要理解這一點也非常的容易。對于一個提供用戶認證的組件，一個可能的服務對用戶進行認證和授權，至于組件內部采用LDAP還是關系數據庫來存放用戶信息，對服務來說沒有任何的差別。
這樣做的好處有很多，一是組件之間能夠以一種穩定的方式存在，組件內部的變化不至于擴散到整個軟件系統。二是軟件設計將會轉向重點設計組件之間的服務，而組件的實現細節將會隱藏起來，這不但有助于設計者更好的把握軟件的全局架構，而且有助于分工的細化。
服務并不是什么新穎的概念，RPC、IDL都是類似的技術。但我們談的服務側重架構和理念，不涉及到具體的技術，這一點同SOA和WebService的關系類似-SOA是一個結構性的概念，而WebService是實現SOA的一種適合的技術。 Stairway to Heaven - Service Oriented Architectures(http://www.enterpriseintegrationpatterns.com/docs/stairwaytoheaven.pdf)一文討論了SOA需要注意的問題，并提出了實現SOA的三個階段，本文所討論的服務為文中所討論的階段3，也是最理想的階段。
服務最好實現為接口。原則上服務可以是任何一種技術：JMS、WebService、RPC、或是簡單方法調用。但是出于服務的穩定性的考慮，我們不應該將一個服務和具體的技術綁定起來，這樣會使的服務發生變化的可能性增大。在Java語言中，接口是具有極大的靈活性的，因此，將接口實現為普通的Java接口是較好的選擇。不過，這樣做的話，我們也許就不能夠使用遠程調用，Web服務之類的功能了，不過這并不要緊，以下就是原因。
服務適配器
客戶端可以直接使用接口，也可以通過適當的適配器來將普通的接口服務轉換為特定技術實現的服務。
如上圖所示，一個普通的接口通過適配器模式轉換成和特定技術相關的服務。在JMX技術中，也采用這種方式，JMX平臺能夠將一個普通的服務端口通過適配器進行轉換，以適用于各種的協議，例如http、sock、snmp等等。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
