質(zhì)量管理:軟件質(zhì)量之路-面向組件的大規(guī)模軟件架構(gòu)

申請免費試用、咨詢電話：400-8352-114

在中小規(guī)模的軟件中，對象和對象之間的協(xié)作關(guān)系就能夠滿足需要。但是當(dāng)軟件規(guī)模擴大，復(fù)雜度上升的時候，面向?qū)ο蠹夹g(shù)強調(diào)的協(xié)作卻表現(xiàn)出另一個極端的特點－耦合度太高導(dǎo)致的復(fù)雜度。這時候就需要有一種新的方法來彌補面向?qū)ο蠹夹g(shù)的弱點。

大規(guī)模軟件的特點

大規(guī)模軟件主要特點是復(fù)雜度。比較典型的例子是集成性的項目。軟件系統(tǒng)需要將各種各樣的硬件、遺留系統(tǒng)、外部接口整合起來。其間可能遇到不同的硬件接口，不同的操作系統(tǒng)，不同的語言，不同的平臺，不同的數(shù)據(jù)庫，不同的消息中間件，不同的網(wǎng)絡(luò)介質(zhì)。這些都使得系統(tǒng)變得非常的復(fù)雜.

面向?qū)ο蠹夹g(shù)的特點是通過對象之間的職責(zé)分工和高度協(xié)作來完成任務(wù)。這樣的好處是代碼量較少，系統(tǒng)布局合理，重用程度高。但是當(dāng)對象的個數(shù)大量增加的時候，對象之間的高度耦合的關(guān)系將會使得系統(tǒng)變得復(fù)雜，難以理解。

以前對于這個問題的方法是采用包（請參考拙作面向?qū)ο筌浖_發(fā)中對包的相關(guān)討論）作為容器來組織對象，對象之間的依賴性將轉(zhuǎn)化為包之間的依賴性。這種方法聽起來有道理，但是在實際中仍會出現(xiàn)難以解決的問題。

包僅僅只是容器。這意味著對對象的組織可以是任意的，而包之間依賴關(guān)系的設(shè)計則還是取決于對象的依賴。此外，包的設(shè)計和對象一樣，缺乏一個統(tǒng)一的風(fēng)格。而統(tǒng)一的風(fēng)格正是大規(guī)模軟件設(shè)計所必須的，因為這樣可以有效改進系統(tǒng)的可理解性，這一點非常重要。

面向組件編程

面向組件編程的縮寫是COP。COP是對OOP的補充，幫助實現(xiàn)更加優(yōu)秀的軟件結(jié)構(gòu)。組件的粒度可大可小，需要取決于具體的應(yīng)用。

在COP中有幾個重要的概念：服務(wù),服務(wù)（Service）是一組接口，供客戶端程序使用。例如，驗證和授權(quán)服務(wù)，任務(wù)調(diào)度服務(wù)。服務(wù)是系統(tǒng)中各個部件相互調(diào)用的接口；組件，組件（Component）實現(xiàn)了一組服務(wù)，此外，組件必須符合容器訂立的規(guī)范，例如，初始化，配置、銷毀。

COP 是對一種組織代碼的思路，尤其是服務(wù)和組件兩個概念。在下文會提到Spring框架中，就采用了COP的思路，將系統(tǒng)看作一個個的組件，通過定義組件之間的協(xié)作關(guān)系（通過服務(wù)）來完成系統(tǒng)的構(gòu)建。這樣做的好處是能夠隔離變化，合理的劃分系統(tǒng)。而框架的意義就在于定義一個組織組件的方式。

理解組件

組件不是一個新的概念，Java中的javaBean規(guī)范和EJB規(guī)范都是典型的組件。組件的特點在于他定義了一種通用的處理方式。例如，JavaBean 擁有內(nèi)視的特性，這樣就可以通過工具來實現(xiàn)JavaBean的可視化。而EJB規(guī)范定義了企業(yè)服務(wù)中的一些特性，使得EJB容器能夠為符合EJB規(guī)范的代碼增添企業(yè)計算所需要的能力，例如事務(wù)、持久化、池等。

所以，組件比起對象來的進步就在于通用的規(guī)范的引入。通用規(guī)范往往能夠為組件添加新的能力（就像上面所討論的），但也給組件添加了限制，例如你需要實現(xiàn)EJB的一些接口。以下我們將討論組件的一些相關(guān)問題：

組件的粒度

組件的粒度是和系統(tǒng)的架構(gòu)息息相關(guān)的。組件的粒度確定了，系統(tǒng)的架構(gòu)也就確定了。在小規(guī)模的軟件中，可能組件的粒度很小，僅相當(dāng)于普通的對象，但是對于大規(guī)模的系統(tǒng)來說，一個組件可能包括幾十，甚至上百個對象。因此，對使用COP技術(shù)的系統(tǒng)來說，需要正確的定義組件的粒度。較好的定義粒度的方法是對核心流程進行分析。

針對接口

接口和實現(xiàn)分離是COP的基礎(chǔ)，沒有接口和實現(xiàn)的分離，就沒有COP。接口的高度抽象特性使得各個組件能夠被獨立的抽取出來，而不影響到系統(tǒng)的其它部分。

接口和實現(xiàn)分離有以下幾個好處：

1.在模塊/組件/對象之間解耦。
2.輕松的抽換實現(xiàn)，而不用修改客戶端。
3.用戶只需要了解接口，而不需要了解實現(xiàn)細節(jié)。
4.增加了重用的可能性。

IOC

IOC 是Inversion of Control的簡稱。它的原理是基于OO設(shè)計原則的好萊塢原則（The Hollywood Principle）：不要訪問我，我們將訪問你。也就是說，所有的組件都是被動的（Passive），所有的組件初始化和調(diào)用都由容器負責(zé)。

IOC有幾種實現(xiàn)的類型，包括基于方法參數(shù)調(diào)用的Method-based (M) IoC，它把組件傳遞給每個方法調(diào)用；基于接口的Interface-based (I) IoC（通常稱為類型1），它使用接口來聲明組件之間的依賴性，例如，Serviceable, Configurable；基于Setter方法的Setter-based (S) IoC（通常稱為類型2），它使用setter方法來設(shè)置組件之間的依賴性；基于構(gòu)造函數(shù)的Constructor-based (C) IoC（通常稱為類型3）。

Martin Fowler將IOC模式稱為Dependency Injection模式。

IOC是框架開發(fā)的一個基本原理。在開源軟件中，不少的容器類框架都采用了IOC的思路。

組件污染

在IOC 的第一類型中，由于組件需要實現(xiàn)一些特定的接口，或是從某個類集成。這將使得組件受到一些約束（稱為Invasive），例如組件移植不便。另一種情況是組件需要依賴于一個特定的容器，最為典型的就是EJB，組件無法脫離容器單獨存在，這也使得組件受到約束。這兩種情況都屬于組件污染。

最理想的組件是只專注于自身工作的組件，它沒有其它額外的邏輯。不過按照這種標準，目前大部分的代碼都是不符合的。因此，目前在開源軟件界出現(xiàn)了一些輕量級的容器框架，典型的如上文提到的PicoContainer和spring。他們的定位就是提供一個對組件管理的統(tǒng)一模式，而組件可以單獨的使用，也可以放在另一個容器中，容器僅僅只是為組件提供了一些額外的功能，和組件本身沒有直接的依賴。

為什么我們說接口比繼承好，很重要的一個原因就是接口更加靈活，組件的依賴性更弱，同樣的，目前另一種做法則是采用一些標記性的語言來實現(xiàn)比接口更大的靈活度。例如基于xml的配置文件，以及J2SE1.5中將要引入的屬性。

組件的測試

組件和容器的依賴脫離為組件測試提供了一個很好的環(huán)境。我們在測試一節(jié)中討論過容器內(nèi)測試往往是比較麻煩的，其原因就是在于上面所說的組件污染問題。例如在 spring框架中，組件是一個標準的JavaBean，你可以直接編寫代碼來設(shè)置組件的屬性和定義組件之間的依賴關(guān)系（適用于自動化測試），也可以把這項工作交給spring容器（適用于開發(fā)和部署）。

組件測試在測試的分類中屬于集成測試。

理解服務(wù)

在討論組件時我們談?wù)摿私M件粒度的問題。當(dāng)組件的粒度不僅僅限于單個對象的時候。在構(gòu)成組件的多個對象中，有些對象處于組件內(nèi)部，不和其它的組件交互，有些對象需要和外部組件進行交互。后一種對象起的就是服務(wù)的作用。在設(shè)計模式中，這種設(shè)計被稱為Facade模式。而在OO語言中，他們相當(dāng)于接口的概念。不管如何比喻，服務(wù)訂立了組件和組件之間的契約。這種契約是穩(wěn)定的（如果業(yè)務(wù)需求是穩(wěn)定的），不會隨著組件內(nèi)部的變化而發(fā)生變化。

要理解這一點也非常的容易。對于一個提供用戶認證的組件，一個可能的服務(wù)對用戶進行認證和授權(quán)，至于組件內(nèi)部采用LDAP還是關(guān)系數(shù)據(jù)庫來存放用戶信息，對服務(wù)來說沒有任何的差別。

這樣做的好處有很多，一是組件之間能夠以一種穩(wěn)定的方式存在，組件內(nèi)部的變化不至于擴散到整個軟件系統(tǒng)。二是軟件設(shè)計將會轉(zhuǎn)向重點設(shè)計組件之間的服務(wù)，而組件的實現(xiàn)細節(jié)將會隱藏起來，這不但有助于設(shè)計者更好的把握軟件的全局架構(gòu)，而且有助于分工的細化。

服務(wù)并不是什么新穎的概念，RPC、IDL都是類似的技術(shù)。但我們談的服務(wù)側(cè)重架構(gòu)和理念，不涉及到具體的技術(shù)，這一點同SOA和WebService的關(guān)系類似－SOA是一個結(jié)構(gòu)性的概念，而WebService是實現(xiàn)SOA的一種適合的技術(shù)。

服務(wù)最好實現(xiàn)為接口。原則上服務(wù)可以是任何一種技術(shù)：JMS、WebService、RPC、或是簡單方法調(diào)用。但是出于服務(wù)的穩(wěn)定性的考慮，我們不應(yīng)該將一個服務(wù)和具體的技術(shù)綁定起來，這樣會使的服務(wù)發(fā)生變化的可能性增大。在Java語言中，接口是具有極大的靈活性的，因此，將接口實現(xiàn)為普通的Java接口是較好的選擇。不過，這樣做的話，我們也許就不能夠使用遠程調(diào)用，Web服務(wù)之類的功能了，不過這并不要緊，以下就是原因。

服務(wù)適配器

客戶端可以直接使用接口，也可以通過適當(dāng)?shù)倪m配器來將普通的接口服務(wù)轉(zhuǎn)換為特定技術(shù)實現(xiàn)的服務(wù)。


如上圖所示，一個普通的接口通過適配器模式轉(zhuǎn)換成和特定技術(shù)相關(guān)的服務(wù)。在JMX技術(shù)中，也采用這種方式，JMX平臺能夠?qū)⒁粋€普通的服務(wù)端口通過適配器進行轉(zhuǎn)換，以適用于各種的協(xié)議，例如http、sock、snmp等等。