追求代码质量: 驯服复杂的冗长代码

核心提示： 观察对象导入的数量就很容易预测脆弱性，但如果使用 .* 符号（例如 com.acme.user.*）导入整个包，追求代码质量: 驯服复杂的冗长代码(3)，则很可能产生误导，为了更精确起见，这些类通常非常大，而大型的类通常拥有长方法，可能需要注意对象所拥有的惟一类型 的数量（该数量可通过解析代码获

观察对象导入的数量就很容易预测脆弱性，但如果使用 .* 符号（例如 com.acme.user.*）导入整个包，则很可能产生误导。为了更精确起见，可能需要注意对象所拥有的惟一类型 的数量（该数量可通过解析代码获得 —— 不是 import 语句）。如果应用程序的包结构大致上以某种在少数包中包含许多类的方式设计，则惟一类型度量（types metric）可能很有帮助。

包含许多 public 方法的类也有许多导入。这些类通常会成为代码基的中心，就像 Facades 或工具类那样。因为存在这种责任（通过大量 public 方法导出），所以它们具有高度的输入耦合，也会导致反向的脆弱性。如果这些类中的任何一个发生更改，各种表面上不相关的应用程序部分可能 发生中断。

复杂性是如何产生关联的

到目前为止，所给出的模式都在暗示臃肿的代码（长方法、太多的 public 方法、过多的条件和导入，等等）将影响可读性、可测试性和可维护性。因为该模式用各种度量来重复自己，所以所有这些因素都会导致相互关联。例如，长方法通常得容忍高圈复杂度值，如图 2 所示：

图 2. 长方法与圈复杂性相互关联

不过，相关性并不止于此。具有过多导入的类会有许多惟一类型。这些类通常非常大。而大型的类通常拥有长方法，长方法又常常有很高的圈复杂度值。图 3 展示了复杂性度量是如何相关的：

图 3. 复杂性度量是如何相关的