清单 2 中的 handleDefaultParameters() 方法将原有的重复结构封装到一条 if 语句中。它接收一 个指定 Struts 参数名的参数，并通过编程方式使用反射获取适当的字段。然后，它对原始代码进行 null 检查，最终调用 Struts addParameter() 方法。

有了 handleDefaultParameters 方法后，就可以大大减少原有代码的行数（以及圈复杂度）。我为所 有适用的 Struts 参数名创建一个 String 数组，然后迭代那个数组，在每次迭代中调用 handleDefaultParameters() 方法。

将所有参数检查合并到一个简洁的地方，这不仅仅是消减了方法的大小。原始的方法的圈复杂度是 43 。之前每个 if 块占用 3 行代码（并贡献了 1 个点的圈复杂度）。我用一个含 9 行代码的方法（圈复 杂度为 4）消除了重复，减少了 66 行代码（22 个参数，每个参数需要 3 行代码）。这意味着这个简单 的改变使这个类因这个新方法而减少了 57 行代码，并使圈复杂度减少 18 个点（1 个 CC 点 x 22 个参 数 - 4 个 CC 点）。因为那样小的一个改变，我大大改善了应用程序的可读性、指标、大小和可维护性 。如果将来需要改变调用 Struts addParameter() 方法的方式，只需在一个地方做出更改。

这是一个短期的修复，这是为了演示简单的改变如何对代码的简洁度产生深远的影响。但是，如果是 我的代码库，我会采用一个长期的解决方案。

演化架构与紧急设计: 积累惯用模式(6)

改进代码，第 2 部分

如果是我的项目，我会将整个参数处理机制抽象到它自己的一组类中，构建 Struts 中的一个子框架 。处理参数的代码的复杂性，以及它的广泛性和数量，意味着应该将它当做 Struts 中的一等公民。这不 是一篇文章所能详述的，但是可以看到，Struts 中有大量的复杂性是围绕这个问题产生的。

紧急设计和惯用模式

您认为 Struts 的原设计者曾经想到过处理参数所需的代码有多少吗？软件就是这样。有时候可以根 据问题域的理论知识预测复杂性，但是在编写代码时，又会产生新的约束和机会，这些实际上是无法预测 的。实际上，资深的开发人员在预测那样的 “硬骨头” 方面并不会做得更好。他们只是更相信，那个神 秘的硬骨头最终会出现。

紧急设计的魅力之一是有这样的认识：我们不能可靠地预测什么会变成硬骨头，但是我们应该对此保 持警惕。如果带着发现抽象和模式的期望去看代码库，就更容易有所发现。

最后我以一个案例研究作为结束，该案例研究基于一个 ThoughtWorks 项目，这是我间歇性地从事的 一个项目。在这个大型 Ruby on Rails 项目的早期，技术主管意识到，在一些单独的情况下需要异步行 为（例如，上传大量的图像时，用户需要能够暂时离开页面，之后再回到页面）。如果我们存着 Big Design Up Front 的思维，那么就会立即寻求一个消息队列。但是，在项目一开始，我们还不能完全知道 有哪些地方需要异步，一般的态度是寻求最大的消息队列，以确保能处理将来的新需求。但是我们的技术 主管非常明智地没有那样做。他决定我们已有的足以适合当前状况。

时间往后推移 2 年。到现在，应用程序有 3 个不同的异步行为，当前解决方案开始成为瓶颈。现在 ，是时候使用一个消息队列了。但是，由于技术主管推迟了如此长的时间才做决定，我们现在十分清楚这 个应用程序在消息传递方面的需求，因此可以采用最简单的工具来完成该任务。由于耐心等到最后可靠时 刻才做决定，我们避免了因一个并不那么需要的工具带来的意外复杂性而做的数年的工作 — 从而获得更 简洁的代码，使新特性具有更高的速度，也减少了相关的烦人的工作。

让代码引领设计，这意味着对需求有更好的理解。设计决定推迟得越久，最终做出具有长期意义的决 定时，便

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!