• 功能內(nèi)聚（Functional Cohesion）：一個(gè)模塊只做一件事。它們表現(xiàn)出了低耦合與高度重用。
• 順序內(nèi)聚（Sequential Cohesion）：一個(gè)模塊包含多個(gè)需按一定次序執(zhí)行的任務(wù)。
• 通訊內(nèi)聚（Communication Cohesion）：一個(gè)模塊包含多個(gè)基于相同輸入的操作，但這些操作在執(zhí)行次序方面沒(méi)有任何要求。

• 過(guò)程內(nèi)聚（Procedural Cohesion）：與順序內(nèi)聚相似，只不過(guò)各個(gè)任務(wù)所處理的數(shù)據(jù)各有不同。正如Steve所說(shuō)：“這種內(nèi)聚常常是‘為降低耦合度，人為把活動(dòng)分組’的結(jié)果”。
• 時(shí)間內(nèi)聚（Temporal Cohesion）：一個(gè)模塊里的任務(wù)僅在時(shí)間上相關(guān)。“如果有任務(wù)要換在別的時(shí)間執(zhí)行，那么這種模塊會(huì)帶來(lái)維護(hù)上的難題。”
• 邏輯內(nèi)聚（Logical Cohesion）：一個(gè)模塊里的活動(dòng)由于“看似具有共同的實(shí)現(xiàn)”而被聚集起來(lái)。
• 偶然內(nèi)聚（Coincidental Cohesion）：一個(gè)模塊里的任務(wù)的唯一共同之處，就是它們均在此模塊之中。

正如同耦合（coupling）一樣，內(nèi)聚（cohesion）對(duì)于分布式對(duì)象與服務(wù)來(lái)說(shuō)仍然重要。例如，如果你僅僅因?yàn)橐唤M方法具有相似的實(shí)現(xiàn)就把它們放在一個(gè)對(duì)象里，那么你將犯“創(chuàng)建邏輯內(nèi)聚對(duì)象（logically cohesive object）”的錯(cuò)誤。

考慮到向“新的”計(jì)算方式的轉(zhuǎn)變常常伴隨著對(duì)舊的方式的直接批評(píng)，所以如今對(duì)SOA的關(guān)注引起對(duì)分布式對(duì)象的激烈反對(duì)并不出乎意料。不幸的是，其實(shí)許多適合分布式對(duì)象系統(tǒng)的質(zhì)量標(biāo)準(zhǔn)也同樣適用于分布式服務(wù)與SOA。因此，有些人為了順應(yīng)潮流而被迫忽略它們是十分遺憾的。不過(guò)，也許不要緊，因?yàn)槲覀兛梢灾苯幼匪莸綄?duì)象之前的時(shí)期，搞清楚像耦合和內(nèi)聚這樣的度量標(biāo)準(zhǔn)，并重新運(yùn)用它們。

有 些軟件是高內(nèi)聚、緊耦合的。這意味著，盡管它經(jīng)過(guò)合理的設(shè)計(jì)，但由于存在緊密的相互依賴關(guān)系，所以不容易被修改。那是很糟糕的；而且很不幸地是，這在企業(yè) 應(yīng)用中很常見(jiàn)。還記得若干年前的確給你留下深刻印象，但如今維護(hù)起來(lái)卻令你痛苦不堪的軟件嗎？原因就在于它是緊耦合的。

松耦合、低內(nèi)聚的軟件是另一種糟糕的軟件。這意味著模塊之間少有明顯的相互依賴；但是，沒(méi)有一個(gè)模塊是在系統(tǒng)中某方面處 于權(quán)威地位的。這進(jìn)而造成需用“散彈法（scattergun approach）”來(lái)解決持續(xù)的系統(tǒng)演化，因?yàn)榧词购苄〉母膭?dòng)也會(huì)波及多個(gè)組件或系統(tǒng)。也就是我們今天所認(rèn)識(shí)到的SOA。

一方面，我們傾向于（而且確實(shí)在SOA那 幫人的慫恿之下）認(rèn)為這種架構(gòu)是非常符合目標(biāo)的，因?yàn)樗菢O度松耦合的。既然每個(gè)組件或服務(wù)都與其他別的組件或服務(wù)沒(méi)有耦合，那么應(yīng)該可以像玩樂(lè)高積木那 樣、按無(wú)數(shù)種方式來(lái)組織或調(diào)整它們。書上教我們用一組基礎(chǔ)服務(wù)來(lái)構(gòu)建“業(yè)務(wù)服務(wù)（business services）”。事實(shí)上，我們甚至可以用BPM工具“選擇-點(diǎn)擊”來(lái)輕而易舉地達(dá)到那個(gè)目標(biāo)，從而避免了如開(kāi)發(fā)者與一直伴隨左右的變更管理這樣的開(kāi) 銷。是嗎？ 不。實(shí)際上根本不是。[……] 這是對(duì)架構(gòu)的幻想，在真實(shí)世界的企業(yè)系統(tǒng)里是不可能的。實(shí)際上，一個(gè)不解決業(yè)務(wù)問(wèn)題的服務(wù)根本沒(méi)有資格進(jìn)入SOA。

嗯，有人一直試圖單槍匹馬地用一種“面向其他架構(gòu)（Something Else Oriented Architecture）”來(lái)推翻SOA， 那就是MEST支持者Jim Webber。[……] 我覺(jué)得他這篇文章純屬誤導(dǎo)。也許有些地方我理解不當(dāng)，但Jim說(shuō)的是內(nèi)聚與松耦合的關(guān)系。[……] 在我看來(lái)，內(nèi)聚（cohesion）聽(tīng)起來(lái)是個(gè)不錯(cuò)的工程原則，它很像“依賴結(jié)構(gòu)矩陣（Dependency Structure Matrix）”。[……] 松耦合（loose coupling）的目標(biāo)正是降低內(nèi)聚。一個(gè)互聯(lián)的（connected）系統(tǒng)是不存在內(nèi)聚的。內(nèi)聚和耦合不可能同時(shí)存在。即使在英語(yǔ)里，把這兩個(gè)詞聯(lián)系 在一起也是很糟糕的。

松耦合的目標(biāo)，是使得在不同時(shí)間、用不同技術(shù)、具有不同安全模型的代碼片斷可以一同工作。

SOA是 要遠(yuǎn)離內(nèi)聚的系統(tǒng)、轉(zhuǎn)而支持更廣泛的重用場(chǎng)景。多層內(nèi)聚的系統(tǒng)提供“多層”（像庫(kù)一樣的）重用模型：上層可以重用下層。不幸的是，它強(qiáng)迫我們以一種與理想 的信息系統(tǒng)架構(gòu)不兼容的方式來(lái)創(chuàng)建系統(tǒng)。問(wèn)題出在內(nèi)聚，而解決之道在于松耦合。Jim，你真以為人們都在試圖“把東西放在一個(gè)模塊里”嗎？

有些人老拿他們5年前形成的觀念來(lái)看“SOA”，而那只是被他們自己錯(cuò)誤理解的SOA，這種情形讓我覺(jué)得越來(lái)越不愉快。Jim所展現(xiàn)的是一幅陳舊的、并不能代表2008年的SOA的情景。

…… 對(duì)于服務(wù)的接口與實(shí)現(xiàn)設(shè)計(jì)，內(nèi)聚（cohesion）完全是一種沒(méi)有必要的約束，它實(shí)際上會(huì)降低一個(gè)服務(wù)的重用程度、并減弱它參與不同組裝的能力。也許我 們?cè)搶?duì)現(xiàn)代松耦合的概念作一些了解了，比如：雙向接口（bi-directional interfaces）、組裝（assemblies）、編制語(yǔ)言（orchestration languages）、可擴(kuò)展及語(yǔ)義可達(dá)的數(shù)據(jù)結(jié)構(gòu)（extensible and semantically accessible data structures）。過(guò)去設(shè)計(jì)出那些古老的編程技巧，就是因?yàn)榫幊棠Ｐ屠餂](méi)有這些概念。

但是爭(zhēng)論仍在繼續(xù)。內(nèi)聚跟SOA是不是本質(zhì)對(duì)立的？例如，我們是否需要重寫軟件工程書籍以涵蓋跟SOA有關(guān)的內(nèi)聚？當(dāng)然，內(nèi)聚本身并無(wú)壞處；不過(guò)，也許內(nèi)聚跟耦合一樣是分不同程度的，而且不能搞一刀切？

本文轉(zhuǎn)自infoQ中文站  作者 Mark Little   譯者 徐涵

標(biāo)簽: 技術(shù)趨勢(shì), SOA