高內聚、低耦合是軟件設計的普遍原則，但在實際的工作中，有時我們並不能清楚的認識到關於它們的兩個問題：
1、爲什麼要高內聚、低耦合。
2、如何做到高內聚、低耦合。
高內聚、低耦合這個概念出現的比較早，也是我們在接觸軟件設計時被告知的第一條原則。但很多人並不清楚，它能給我們帶來什麼實際的好處，在與有些同事們討論設計方案的優劣時，有時經常聽到這樣一句話——這兩種功能不是一樣的麼？讓人啼笑皆非，我們此時討論的並非功能問題，所有的備選方案，只有滿足業務功能纔有資格成爲候選者。功能不是軟件設計階段“設計”出來的，實際上，在這個階段對功能問題，在主流活動中，除了反饋，我們沒有討價還價的餘地很小。在本階段我們要通過“設計”活動承載的是軟件的質量屬性，作爲一個可能有較長生命週期的軟件，可擴展性通常是最重要也最容易被忽視的，原因是可擴展性在軟件首次完成時不容易度量，它要靠時間來檢驗，在結果導向嚴重的環境中，導致被忽視，但它可以通過“人”來定性的評價（關於能否定量度量，我們在下文中討論），而衆多的軟件設計方法都瞄準這一點，其中最具代表性的就是面向對象。
高內聚、低耦合到底能給我們帶來什麼好處呢？它意味着一個模塊只做一件事情，關注一個變化，反之，一件事情、一個變化也只應該在一個模塊中。這一點是非常重要的，它是提高模塊組合能力的基礎，軟件業之所以稚嫩於其它傳統技術行業，正是因爲在其它成熟行業中都有着成熟的“方法”和“標準”，而軟件介質的特殊性——對設計沒有約束，而軟件業通常共生於其它行業中，這些都導致“標準”較難形成，沒有標準，導致軟件開發效率的低下。舉幾例子：建築業蓋大樓時，設計師不會去考慮鋼筋、水泥該如何生產，他需要考慮的是該用哪個規格的（實際上在大部分情況下，這些也不用他們考慮，完全可以參照業界的通過標準）。汽車業造汽車，沒有哪家汽車生產公司會親自生產全部部件。他們都運用了“組合”這一手段，組合意味着低成本、可替換、應變能力強。而在軟件內部恰恰缺乏這些，親自造輪子是常有的事情，出現這類問題的最主要原因是“人的能力和能動”問題，經常出現針對功能做設計、寫代碼，這樣編寫出的軟件，一旦功能變化，修改範圍幾乎是不可控的，而一個模塊中承載了太多的邏輯也使閱讀、理解、維護的複雜度急劇升高。
人和計算機理解問題的方式不同，馮.諾依曼計算機理解問題都是扁平和細節的，它能理解的最小和最大單位只有一個——指令，你根本不能對CPU發出“打開資源管理器”這樣的高級指令。而人的思維方式是分層的，我們更習慣於高級描述，即使面對日常生活中經常做的事情，例如——吃飯——我們也不習慣於用計算機的方式來思考——夾菜、張嘴、放菜、咀嚼、吞嚥，如果要讓計算機來完成，實際上還要分的更細。而人一旦面對大量細節，我們出錯的可能性就很大。我們的代碼不是給計算機寫的，而是給人寫的，所以應該符合人類的思維習慣——分層。在一個缺乏設計的軟件中，恰恰容易出現充斥着大量細節的模塊，這些模塊只能在當前功能下與周邊的特定模塊通信，在軟件中缺少可以被複用的“零件”，這樣的軟件可以說不具備組合能力，應對變化的能力的很差（糾正一個概念，衡量應對變化的能力不能只是通過代碼量，還要看這個變化會影響到的模塊佔全部模塊的比例）。
小結一下，高內聚、低耦合能給我們帶來什麼？
1、容易理解（再糾正一個觀念，有人覺得充斥大量細節的、平鋪直敘的代碼更容易理解，能直接看到業務是怎麼在計算機上執行心裏覺得有底，尤其在定位問題時，更習慣這種思維方式。實際情況並非這樣，如果你的代碼中沒有多少的判斷和跳轉可能是容易讀，但如果出現大量的條件和跳轉你可能就要崩潰了，不幸的的是，隨着維護的增加，判斷和跳轉將會越來越多——初始化可能是個特例。還有，這樣的代碼花力氣讀懂是可能的，在一段時間內也能記住，但如果軟件中到處都是這樣的代碼，你很難掌握全局。最後，說給抱着“定位問題”的思維讀代碼的同事，發現Bug有兩種方式，一種是軟件足夠清晰，導致Bug很難隱藏，另一種是軟件足夠複雜，）。
能否定量度量？我現在還不知道是否有這樣的工具，由於被考察對象多是代碼，這增加了度量的難度，尤其是在那些用C語言編寫的軟件中，不過似乎也不是不可以的，。
