SonarQube中监测循环、包耦合度情况
一、为什么要监测循环、包耦合度情况？
耦合度就是某模块（类）与其它模块（类）之间的关联、感知和依赖的程度，是衡量代码独立性的一个指标，也是软件工程设计及编码质量评价的一个标准。
耦合度很高的情况下，维护代码时修改一个地方会牵连到很多地方，如果修改时没有理清这些耦合关系，那么带来的后果可能会是灾难性的，特别是对于需求变化较多以及多人协作开发维护的项目，修改一个地方会引起本来已经运行稳定的模块错误，严重时会导致恶性循环，问题永远改不完，开发和测试都在各种问题之间奔波劳累，最后导致项目延期，用户满意度降低，成本增加
有两个测试指标有助于确定过度耦合的情况，即“传入耦合”（这个对象对其他对象负有责任）与“传出耦合”（这个对象依赖于其他对象）；
高度依赖于其他对象的对象在面对变化时显得很脆弱，传入耦合与传出耦合共同组成了“不稳定性”值。
不稳定性 = 传出耦合 / (传出耦合 + 传入耦合)
另外，了解耦合度情况将可以对可维护性产生较大影响，具有高传入耦合的配件应该有大量的相关测试，因为许多代码依赖于这个配件，因此就更希望保证它是可靠的，可有效用于评估与降低软件风险。
二、如何监测循环、包耦合度情况在SonarQube中，在面板中增加相应的widget插件即可
依赖结构矩阵，DSM可以用来简洁地展示不同组件之间的依赖关系，根据不同的导航级别，这些组件可以是最基本的类级别、包或文件级别。
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”包；
如图：绿色组件依赖于蓝色组件，而同时蓝色组件依赖于橙色组件。
1.意味着“buffer”包有4个文件依赖于"collection"包，而同时"collection"包没有文件依赖于“buffer”包；
2.另外也就意味着，矩阵中右上侧的红色数字表示有可疑的依赖，即循环；
1.在矩阵中，处于软件结构最顶层的排在最上面，而处于软件结构最底层的组件排在最下面，例如每个组件所依赖的"collection"包自身依赖于更底层的“comparators”包；
2.位于上三角中的红色数字的是需要切断依赖的以便移除循环的地方，当没有循环时，DSM矩阵呈现为下三色形状；
如图：从“buffer”包到“iterators”包有2个传出耦合，此时双击“2”单元格即可看到详细信息。
双击组件可以得到子组件的详细依赖关系，可以看到这个包中不同类之间的依赖结构矩阵。
本小节官方文档链接：http://docs.codehaus.org/display/SONAR/Cycles+-+Dependency+Structure+Matrix
三、降低耦合度的方法 1、少使用类的继承，多用接口隐藏实现的细节。 java面向对象编程引入接口除了支持多态外， 隐藏实现细节也是其中一个目的。 2、模块的功能化分尽可能的单一，道理也很简单，功能单一的模块供其它模块调用的机会就少。（其实这是高内聚的一种说法，高内合，限制公共耦合的范围，避免使用内容耦合。
本小节源自：http://hi.baidu.com/roleya/item/5165ed9d65df35dd1f4271ac
