演化架构与紧急设计: 对设计进行重构

核心提示： 像上面这样使用反射代表了一种权衡：复杂性和简洁性，基于反射的版本最初比较难以理解，演化架构与紧急设计: 对设计进行重构(10)，但是它提供了一些优点，首先，重构与设计的交互是一个非常丰富的主题；下期文章将继续这个主题，讨论如何使用指标查找代码中最需要进行重构的部分，它自动为 Employee 类

像上面这样使用反射代表了一种权衡：复杂性和简洁性。基于反射的版本最初比较难以理解，但是它提供了一些优点。首先，它自动为 Employee 类处理所有属性。准备好这些代码后，您可以安全地向 Employee 添加新属性，而不需要考虑创建 comparator 来对它们进行排序。其次，这种方法可以更加高效地处理大量属性。如果结构化复制不严重的话，那么也可以忍受。但是您必须要问问自己：当属性数量达到多少时，您必须使用反射来解决此问题？10 个、20 个还是 50 个？这个数字对于不同的开发人员和团队来说可能会发生变化。然而，如果试图寻找一种比较客观的衡量，为什么不衡量一下反射相对于单个 comparator 的复杂度呢？

在 “测试驱动设计，第 2 部分” 中，我引入了圈复杂度 指标，可以度量单一方法的相对复杂度。一种可以度量 Java 语言圈复杂度的非常不错的开源工具就是 JavaNCSS 工具。如果我对单个 comparator 类运行 JavaNCSS，它将返回 1，这并不奇怪：类中的单个方法只有一行代码而没有代码块。当我对整个 EmployeeSorter 类运行 JavaNCSS 时，所有方法的圈复杂度的总值为 8。这表示当属性数达到 9 时需要改用反射；这时结构复杂度超过了基于反射的方法的复杂度。

总之，每种解决方法都有利弊，这取决于您如何权衡。我已经习惯在 Java 语言和其他语言中使用反射，因此我将更加积极地推行这种方法，因为我不喜欢在软件中使用各种形式的重复。

结束语

在本期文章中，我首先讨论了使用重构作为手段来帮助理解和识别紧急设计。我介绍了与基础设施的耦合及其对设计的不利影响。文章主要介绍了几种不同形式的复制。重构与设计的交互是一个非常丰富的主题；下期文章将继续这个主题，讨论如何使用指标查找代码中最需要进行重构的部分，因此这些部分也最有可能包含等待发现的惯用模式。