为什么类Money通过示例扩展Kent Beck的TDD中的表达？

Question

我正在学习TDD示例到目前为止，我发现它是一本好书。但是有一点他告诉我们写：

// in class Money:
Expression plus(Money addend) {
    return new Money(amount + addend.amount, currency);
}

除非我们声明，否则不会构建：

class Money implements Expression {...

这对我来说真的没有意义。作者创建了Expression作为Sum的接口，Money与Sum没有任何共同之处。稍后，他在两个类中都添加了共同的方法reduce()，但是Money中的reduce仅仅返回this。

使Money实现Expression只是从plus()方法中消除错误的最省力的途径，但是它用不必要的信息填充代码（由于该决定，它必须实现reduce（））并增加熵。

我没有考虑太多，但是做这样的事情会更干净吗？

class Money {
    Expression plus(Money addend) {
        return new Expression(amount + addend.amount, currency).reduce();
    }
}

编辑：在下一章中，作者将在另一个类（名为reduce()）中实现Bank方法，该方法可在两种货币之间转换Money。我仍然发现这是一个奇怪的解决方案，Sum和Expression名称暗示我们应该为此任务使用一个转换表达式类。作者可能打算做的是使用递归以其他货币添加资金。无论哪种方式，在我看来他都做了一些遥远的计划，这似乎与书中介绍的TDD不兼容。

Answer 1

关于提前计划

TDD不禁止提前计划。这个过程是关于获得计划的快速反馈，而不是浪费数天（或数周）来制定详尽的计划，而只是看到它们“无法与现实接触”（换句话说，赫尔姆特·冯·莫尔特克）。可以提前考虑。

仍然，肯特·贝克在第17章中透露这不是他的第一个牛仔竞技场：

“我已经编程制作了至少3倍的钱。我以另外6次以印刷为例进行了编程。我又有15次在舞台上进行了编程。我编写了三到四次代码，准备编写[...]。然后，在编写本文时，我想到了使用expression作为隐喻，并且设计的方向与以前完全不同。“]

所以，如果您认为他在作弊：是，他是

。不过，他对此持开放态度。我认为这样做的动机是提出一个令人信服的例子。他还写道，这部分是基于对本书的早期评论。

关于API

不能解释为什么代码看起来像它，但是有这样的原因。它实际上是一个不错的API。

你为什么不能写类似return new Expression(amount + addend.amount, currency).reduce()？

您不能，因为reduce方法不是无效的。它需要参数。您必须同时提供银行（用于保存货币兑换率）和目标货币。

请记住代码正在解决的问题。人们总是会犯错，我认为肯特·贝克（无意间）通过给示例命名[[Money

。]加剧了混乱。问题不是建模

money

，而是建模不同货币的投资portfolios。如果您有25.000美元和10.000瑞士法郎的投资组合，将其减少为一种货币会隐藏重要的细节。使用多种货币的投资组合，您可以分散风险。投资组合所有者将希望看到其投资组合的多个视图。有时，他们希望查看按货币分组的投资组合，而在其他时候，他们希望查看以单一货币显示的投资组合的“当前总价值”。本书中的API启用了这两种视图。

底层“隐喻”之所以被称为

expression

的原因是，该API只是专门的表达式树。事实证明还不错，因为它是合法的。限于本书it informally gives rise to a monoid中介绍的子类型。