高內聚低耦合

高內聚、低耦合是軟體設計的普遍原則，但在實際的工作中，有時我們並不能清楚的認識到關於它們的兩個問題：

1、為什麼要高內聚、低耦合。

2、如何做到高內聚、低耦合。

高內聚、低耦合這個概念出現的比較早，也是我們在接觸軟體設計時被告知的第一條原則。但很多人並不清楚，它能給我們帶來什麼實際的好處，在與有些同事們討論設計方案的優劣時，有時經常聽到這樣一句話——這兩種功能不是一樣的麼？讓人啼笑皆非，我們此時討論的並非功能問題，所有的備選方案，只有滿足業務功能才有資格成為候選者。功能不是軟體設計階段「設計」出來的，實際上，在這個階段對功能問題，在主流活動中，除了反饋，我們沒有討價還價的餘地很小。在本階段我們要通過「設計」活動承載的是軟體的質量屬性，作為乙個可能有較長生命週期的軟體，可擴充套件性通常是最重要也最容易被忽視的，原因是可擴充套件性在軟體首次完成時不容易度量，它要靠時間來檢驗，在結果導向嚴重的環境中，導致被忽視，但它可以通過「人」來定性的評價（關於能否定量度量，我們在下文中討論），而眾多的軟體設計方法都瞄準這一點，其中最具代表性的就是物件導向。

高內聚、低耦合到底能給我們帶來什麼好處呢？它意味著乙個模組只做一件事情，關注乙個變化，反之，一件事情、乙個變化也只應該在乙個模組中。這一點是非常重要的，它是提高模組組合能力的基礎，軟體業之所以稚嫩於其它傳統技術行業，正是因為在其它成熟行業中都有著成熟的「方法」和「標準」，而軟體介質的特殊性——對設計沒有約束，而軟體業通常共生於其它行業中，這些都導致「標準」較難形成，沒有標準，導致軟體開發效率的低下。舉幾例子：建築業蓋大樓時，設計師不會去考慮鋼筋、水泥該如何生產，他需要考慮的是該用哪個規格的（實際上在大部分情況下，這些也不用他們考慮，完全可以參照業界的通過標準）。汽車業造汽車，沒有哪家汽車生產公司會親自生產全部部件。他們都運用了「組合」這一手段，組合意味著低成本、可替換、應變能力強。而在軟體內部恰恰缺乏這些，親自造輪子是常有的事情，出現這類問題的最主要原因是「人的能力和能動」問題，經常出現針對功能做設計、寫**，這樣編寫出的軟體，一旦功能變化，修改範圍幾乎是不可控的，而乙個模組中承載了太多的邏輯也使閱讀、理解、維護的複雜度急劇公升高。

人和計算機理解問題的方式不同，馮.諾依曼計算機理解問題都是扁平和細節的，它能理解的最小和最大單位只有乙個——指令，你根本不能對cpu發出「開啟資源管理器」這樣的高階指令。而人的思維方式是分層的，我們更習慣於高階描述，即使面對日常生活中經常做的事情，例如——吃飯——我們也不習慣於用計算機的方式來思考——夾菜、張嘴、放菜、咀嚼、吞嚥，如果要讓計算機來完成，實際上還要分的更細。而人一旦面對大量細節，我們出錯的可能性就很大。我們的**不是給計算機寫的，而是給人寫的，所以應該符合人類的思維習慣——分層。在乙個缺乏設計的軟體中，恰恰容易出現充斥著大量細節的模組，這些模組只能在當前功能下與周邊的特定模組通訊，在軟體中缺少可以被復用的「零件」，這樣的軟體可以說不具備組合能力，應對變化的能力的很差（糾正乙個概念，衡量應對變化的能力不能只是通過**量，還要看這個變化會影響到的模組佔全部模組的比例）。

小結一下，高內聚、低耦合能給我們帶來什麼？

1、容易理解（再糾正乙個觀念，有人覺得充斥大量細節的、平鋪直敘的**更容易理解，能直接看到業務是怎麼在計算機上執行心裡覺得有底，尤其在定位問題時，更習慣這種思維方式。實際情況並非這樣，如果你的**中沒有多少的判斷和跳轉可能是容易讀，但如果出現大量的條件和跳轉你可能就要崩潰了，不幸的的是，隨著維護的增加，判斷和跳轉將會越來越多——初始化可能是個特例。還有，這樣的**花力氣讀懂是可能的，在一段時間內也能記住，但如果軟體中到處都是這樣的**，你很難掌握全域性。最後，說給抱著「定位問題」的思維讀**的同事，發現bug有兩種方式，一種是軟體足夠清晰，導致bug很難隱藏，另一種是軟體足夠複雜，）。

能否定量度量？我現在還不知道是否有這樣的工具，由於被考察物件多是**，這增加了度量的難度，尤其是在那些用c語言編寫的軟體中，不過似乎也不是不可以的，。

高內聚低耦合

高內聚,低耦合

高內聚，低耦合

高內聚低耦合

高內聚 低耦合

高內聚,低耦合

高內聚，低耦合

高內聚低耦合

相關推薦

高內聚低耦合