演化架构和紧急设计: 使用 Groovy 构建 DSL

核心提示： 和 categories 实例一样，我需要 am 和 pm 作为参数而不是作为 Integer 的方法（以便在我调用它们时，演化架构和紧急设计: 使用 Groovy 构建 DSL(6)，不使用括号就可以进行访问），因此我向元类添加一个新属性作为 Integer.metaClass.getAm，能

和 categories 实例一样，我需要 am 和 pm 作为参数而不是作为 Integer 的方法（以便在我调用它们时，不使用括号就可以进行访问），因此我向元类添加一个新属性作为 Integer.metaClass.getAm。这些代码块可以接收参数，但在这我不需要（因此在代码行的开始只需要一个 -> 即可）。在代码块中，delegate 关键字指向您将要向其中添加方法的类的实例。例如，注意在 getFromToday 属性中，我创建了一个新 Calendar 实例，然后使用 delegate 值滚动日历天数（由 Integer 实例指定的）。当我执行 5.fromToday 时，我需要将日历向前滚动 5 天。

在 categories 和 expando 之间选择

既然 categories 和 expandos 给您提供相同类型的表示，您选择哪个呢？ categories 的好处是固有的词典块范围限制。对语言的核心类进行根本改变（可能是破坏）是一个常见的 DSL 反模式。Categories 强制使用限制来缓解。另一方面，Expandos 本质上是全局的：一旦 expando 代码执行，这些改变将会出现在应用程序的其余部分中。

一般来说，选择 categories，当您修改重要的类时会有潜在的副作用，您需要限制这些修改的范围。Categories 允许您将修改范围限制得很窄。然而，如果您发现使用相同的 categories 包装的代码越来越多时，您应该使用 expandos。一些修改需要被扩展，而且迫使所有修改适应块可能会导致代码错综复杂。一般说来，如果您发现自己在一个 category 中包装超过 3 个根本不同的代码块时，考虑使用 expando。

最后一点：在这测试不是可选的。许多开发人员认为他们的大量代码可以选择测试，但是修改现有类的任何代码都需要综合测试。核心类的修改能力很强，能够生成良好的问题解决方案。但是与能力随之而来的还有责任，表现为测试。