1、高内聚

首先我們來看看内聚的含義：軟件含義上的内聚其實是從化學中的分子的内聚演變過來的，化學中的分子間的作用力,作用力強則表現為内聚程度高。在軟件中内聚程度的高低，标識着軟件設計的好壞。

我們在進行架構設計時的内聚高低是指，設計某個模塊或者關注點時，模塊或關注點内部的一系列相關功能的相關程度的高低。

例如：下單模塊：

一般情況下，下單模塊都會有如下的信息，訂單的信息，産品的信息及誰下的單(買家信息)。這是基本的，那麼我們設計的時候就要把相關的功能内聚到一起。當然這是從大功能(下單管理)上來說，當然這些模塊還可以再細化分成産品、訂單、會員等子模塊。

例如我們在設計數據庫操作輔助類提供的方法有：

通過這樣的方式，那麼這個組件隻負責數據庫操作。這樣帶來的好處也是顯而易見的。高内聚提供了更好的可維護性和可複用性。而低内聚的模塊則表名模塊直接的依賴程度高，那麼一旦修改了該模塊依賴的對象則無法使用該模塊，必須也進行相應的修改才可以繼續使用。

低内聚的模塊設計的壞處有：首先模塊的功能不單一，模塊的職責不明确，比較松散，更有甚者是完成不相關的功能。這樣的設計往往是不可取的。可以通過重構來完善。

下面我們來說下高内聚的簡單解釋：什麼樣的模塊算是高内聚，并且能夠在系統中很好的使用。

那麼我們在設計的過程中如何去完成高内聚呢？

以上基本上講述了高内聚的好處，并且闡述了如何實現高内聚的步驟和原則。下面我們來說說可能高内聚帶來的壞處。

高内聚有時候也不是說所有的情況都采用這樣的原則，當然高内聚還是要适度的，下面來舉例說明：例如内聚性要求強的話就像Windows32中系統提供的API，裡面的函數太多了，都放在一個Dll中，那麼每個函數完成一個功能。這樣強大的功能，會比較複雜，所以并不是完全的高内聚越高越好，還是要看實際的需要。當然維護起來也不是特别的方便。

2、低耦合

首先我們來看看低耦合的定義：低耦合是用來度量模塊與模塊直接的依賴關系。耦合當然也可以這樣簡單的理解，我想懂電腦的應該都知道，CPU與主闆之間的關系，CPU如果是特殊的CPU必須使用特殊的主闆來支持，那麼如果說這個CPU不唯一依賴唯一主闆，那麼就認為這個CPU與主闆的關系是低耦合的關系。

下面我們來舉例說明低耦合的設計與高耦合的設計：

這是一個簡單的低耦合的設計，電器與插座之間是低耦合的關系，就算我替換了不同的插座，電器依然可以正常的工作。因此簡單的描述如下，就是A模塊與B模塊存在依賴關系，那麼當B發生改變時，A模塊仍然可以正常工作，那麼就認為A與B是低耦合的。

1、筆記本接音響可以正常的使用。

2、筆記本接專配耳機正常的使用。

對應一般的音響來說，筆記本是通用的，音響和筆記本直接的關系是低耦合的，但是筆記本和耳機卻是高耦合的，隻有專配的耳機才能和筆記本互聯使用，而不

是通用的，所以說筆記本和專配耳機存在着較強的依賴關系。當然最簡單的方式就是筆記本提供統一的耳機接口，可以滿足一般性的需求。

下面我們将來分析如何構建低耦合的設計。

總結

上面我們已經講解了低耦合和高内聚的二個原則，通過這2個原則我們知道，滿足這2個原則是衡量一個架構設計好壞的一個參考标準。下面我們将來講解通過功能分離的方式來滿足上面的2個原則。

1、如何按功能進行模塊化的分離。

我們在将一個系統進行功能劃分時，首先我們先把功能職責劃分成獨立的單元。

例如現在有個B2C系統，那麼我們按照B2C的需求，如下分析：

我們這裡簡單的分析下B2C應該具有的功能模塊，當然這些模塊的劃分中，有些模塊還可以繼續的分離，當然我這裡隻是實例分析出來。

2、對分離出來的模塊化進行抽象，例如我們以支付為例。

這裡通過支付接口向外提供服務。那麼外界模塊不關心支付系統模塊的變化，隻需要調用接口即可，如果具體的支付方式，比如支付寶的方式發生改變，在調用支付服務的模塊中也不需要做任何的修改就可以正常的提供服務。顯然這樣的方式是不錯的實現方式。

通常情況下我們在系統分離式隻是以接口的方式提供服務，供其他的模塊進行使用。在模塊内部有大量的信息是不要向外部暴露的，所以模塊在設計時訪問域的定義就要劃分好，防止因為訪問域的定義而對模塊的信息造成破壞。

下面我們來看下功能分離在不同的設計理念下都是什麼樣的表現：

上面隻是實體性的分析了功能分離的好處及應用的廣度，當然我們在後續會結合實例來講解如何來實現這樣的軟件設計模式。當然這隻是軟件的架構設計，那麼如

果細化到具體的實現呢？我們如何去設計每個功能點呢？這就是下章我們要講解的内容了，那麼本文先列出二種常見的方式。

下篇我們将針對設計原則中的實現方式，進行詳細的剖析與具體實現進行舉例講解，希望大家多提意見。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!