一、爲什麼要監測循環、包耦合度情況？
耦合度就是某模塊（類）與其它模塊（類）之間的關聯、感知和依賴的程度，是衡量代碼獨立性的一個指標，也是軟件工程設計及編碼質量評價的一個標準。
耦合度很高的情況下，維護代碼時修改一個地方會牽連到很多地方，如果修改時沒有理清這些耦合關係，那麼帶來的後果可能會是災難性的，特別是對於需求變化較多以及多人協作開發維護的項目，修改一個地方會引起本來已經運行穩定的模塊錯誤，嚴重時會導致惡性循環，問題永遠改不完，開發和測試都在各種問題之間奔波勞累，最後導致項目延期，用戶滿意度降低，成本增加
有兩個測試指標有助於確定過度耦合的情況，即“傳入耦合”（這個對象對其他對象負有責任）與“傳出耦合”（這個對象依賴於其他對象）；
高度依賴於其他對象的對象在面對變化時顯得很脆弱，傳入耦合與傳出耦合共同組成了“不穩定性”值。
不穩定性 = 傳出耦合 / (傳出耦合 + 傳入耦合)
另外，瞭解耦合度情況將可以對可維護性產生較大影響，具有高傳入耦合的配件應該有大量的相關測試，因爲許多代碼依賴於這個配件，因此就更希望保證它是可靠的，可有效用於評估與降低軟件風險。
二、如何監測循環、包耦合度情況
How to Hunt for Cycles?
如何尋找循環呢？在SonarQube中，在面板中增加相應的widget插件即可
Dependency Structure Matrix
依賴結構矩陣，DSM可以用來簡潔地展示不同組件之間的依賴關係，根據不同的導航級別，這些組件可以是最基本的類級別、包或文件級別。
Row Selection
點擊某行中的組件將選中該行，如圖選中了.set包：1.選中了.set包意味着“bidimap”包有3個文件依賴於“set”包；
2.縱列表示“set”包的傳出耦合，即“set”包分別有1、6、3、8個文件依賴於“list”、“collection”、“iterators”、“collections”包；
3.橫排表示“set”包的傳放耦合，即“bag”、“bidimap”、“splitmap”、“map”包分別有5、3、1、8個文件依賴於“set”包；
Colors Meaning
不同的顏色便於使得矩陣中的依賴關係一目瞭然
如圖：綠色組件依賴於藍色組件，而同時藍色組件依賴於橙色組件。
Cell Selection
點擊依賴矩陣中的數字可以選中單元格，如圖：1.意味着“buffer”包有4個文件依賴於"collection"包，而同時"collection"包沒有文件依賴於“buffer”包；
2.另外也就意味着，矩陣中右上側的紅色數字表示有可疑的依賴，即循環；
DSM Sorting and Cycles
依賴結構矩陣的排序與循環1.在矩陣中，處於軟件結構最頂層的排在最上面，而處於軟件結構最底層的組件排在最下面，例如每個組件所依賴的"collection"包自身依賴於更底層的“comparators”包；
2.位於上三角中的紅色數字的是需要切斷依賴的以便移除循環的地方，當沒有循環時，DSM矩陣呈現爲下三色形狀；
Find Usages for Dependencies
依賴關係的使用如圖：從“buffer”包到“iterators”包有2個傳出耦合，此時雙擊“2”單元格即可看到詳細信息。
Zoom into a Component to get Dependencies Between Sub-components
雙擊組件可以得到子組件的詳細依賴關係，可以看到這個包中不同類之間的依賴結構矩陣。
本小節官方文檔鏈接：http://docs.codehaus.org/display/SONAR/Cycles+-+Dependency+Structure+Matrix
三、降低耦合度的方法
1、少使用類的繼承，多用接口隱藏實現的細節。 java面向對象編程引入接口除了支持多態外， 隱藏實現細節也是其中一個目的。
2、模塊的功能化分儘可能的單一，道理也很簡單，功能單一的模塊供其它模塊調用的機會就少。（其實這是高內聚的一種說法，高內聚低耦合一般同時出現，爲了限制篇幅，我們將在以後的版期中討論）。
3、遵循一個定義只在一個地方出現。
4、少使用全局變量。
5、類屬性和方法的聲明少用public，多用private關鍵字，
6、多用設計模式，比如採用MVC的設計模式就可以降低界面與業務邏輯的耦合度。
7、儘量不用“硬編碼”的方式寫程序，同時也儘量避免直接用SQL語句操作數據庫。
8、最後當然就是避免直接操作或調用其它模塊或類（內容耦合）；如果模塊間必須存在耦合，原則上儘量使用數據耦合，少用控制耦
合，限制公共耦合的範圍，避免使用內容耦合。
本小節源自：http://hi.baidu.com/roleya/item/5165ed9d65df35dd1f4271ac
