軟體模組劃分原理

標籤：style   io   資料   ar   問題   sp   演算法   ad   on   

在軟體高層設計中，如何分解模組是首要考慮的問題。目前業界公認模組劃分要按照“高內聚，低耦合”的原則來進行，那麼如何劃分才能滿足“高內聚，低耦合”呢？下面來對模組分解原理方面進行一些探索，有考慮不周和不成熟之處還請大家不吝指正。

模組是按功能來分解的嗎？

許多人可能有過經驗，面對一堆功能性需求，多個不同的需求可能要放到同一個模組裡，而某個需求又需要分解到多個模組裡去實現。

比如一個詞典軟體（類似金山詞霸的軟體），通常有查詢詞典的功能需求和添加使用者詞庫的功能需求，顯然不可能簡單地為這兩個功能各分解一個模組。查詢介面和添加使用者詞庫的介面處理部分會被劃成一個模組，而對詞典的資料管理（查詢，添加等）部分會被劃分成另外一個模組。

通過對以上詞典軟體的模組劃分的分析，可以得出模組並不是簡單地按功能來劃分的結論，因此按功能來分解模組並不是一個任何情況下都可行的方案。

模組按專業領域進行分解

仔細觀察上面所說的詞典軟體的模組分解就會發現，所劃分的兩個模組屬於不同的專業領域，一個是互動領域（圖形介面），另一個是資料管理領域（資料結構與演算法）。這樣看來模組劃分是按專業領域來劃分的了，是不是所有的模組劃分都是或者應該按照專業領域來進行劃分呢？

通過觀察大量的軟體的模組分解情況，其實可以發現絕大部分模組都是按照專業領域來分解的，這些專業領域包括軟體公用領域的各個子領域，軟體所處理業務的專業領域及其子領域等。

軟體公用領域常見的子領域有資料結構演算法，圖形介面，IO處理，網路通訊，資料庫，加密，安全，影像處理，數學演算法等，當然這些子領域還可以進一步劃分出更小的子領域來。

軟體所處理業務的專業領域則是指具體的業務方面所屬的專業領域，如財務軟體的業務包括了財務專業領域，CAD軟體業務包括了機械製圖方面的專業領域等。

這些不同專業領域內的內容都是被劃分到不同的模組裡，沒有人會在同一個模組裡同時實現網路通訊和資料結構演算法的功能。這樣可以得到模組分解的一個最基本的原理：

模組分解基本原理：不能在同一模組中實現兩個不同專業領域的內容

上面這句話的意思其實和模組按專業領域進行分解是一回事，只不過意思更明確一些。注意這裡說的是“實現”，有許多的模組中需要用到許多不同專業領域的介面來進行處理，即在同一模組中可能會調用許多不同專業領域的介面來進行處理，調用介面並不屬於“實現”。

模組按專業領域來分解只是一個原理，無法證明它的正確性，因此看一下它會不會與已有的一些設計特性有衝突呢，比如常說的“高內聚，低耦合”，可複用性，可擴充性等是否會產生衝突。

推論1：按專業領域分解的模組是“高內聚，低耦合”的

為什麼說按專業領域分解的模組事“高內聚，低耦合”的呢？專業的劃分都是人們經過長期的實踐和探索劃分出來的，專業領域本身就是“高內聚，低耦合”的， 比如資料結構演算法專業和網路專業耦合就很小，但每個專業的內部都是高內聚的。

推論2：按專業領域分解的模組是可複用的

這點很容易理解，模組按專業領域分解完後，顯然任何兩個不同的模組都不會有重複的內容，因此滿足可複用的特性。

推論3：按專業領域分解的模組是可擴充的

當有新增需求時，只要將新增需求分解成各個專業領域的內容，新增的內容可以分為三類：

1、在已有模組裡已經有對應的實現，

2、屬於已有模組的領域，但是沒有對應的實現

3、不屬於已有模組的領域

對第1種情況中，顯然不需要對已有模組做任何修改和添加；對第2種，需要在已有模組裡添加相應的介面來實現對應的內容；對第3種，需要增加新的模組來實現對應的內容。

所有這三種情況，都符合軟體設計中的可擴充特性，因此按專業領域分解的模組是可擴充的。

推論4：按專業領域分解的模組是可維護的

這點可以由由模組高內聚，低耦合，可擴充性的特性得出。

由此看出模組分解基本原理是和以往對設計的要求是相符合的，但是會不會有反例呢，我實在不能確定，因為這個原理是無法證明的。如果有人發現有不應該按照專業領域來分解模組的反例，請回複一下。

模組按專業領域分解的困難之處

雖然模組按專業領域進行分解看起來好像很完美，可以說絕大部分需求都可以按照這個原則來進行分解。但是並不是說就不存在問題了，實際上按專業分解的前提條件就是要將需求能夠分解成已有專業領域的內容。

困難1：如果需求的內容屬於新興未成型的專業領域的內容，那麼按專業分解就不是那麼容易了。

困難2：許多需求最終需要分解到某個專業領域的某個子領域裡來處理，而很多專業領域還在發展之中，它的許多子領域還沒定型，這時劃分模組也不是一件容易的事情。

軟體模組劃分原理