目标收益
- 熟悉IDE快捷键；
- 掌握TDD基本知识；
- 识别代码坏味道，熟练运用重构手法；
- 熟悉JUnit与Mockito框架；
- 了解Google Guice框架；
我们对Guess Number分解的任务为：
- 随机生成答案
- 判断每次猜测的结果
- 检查输入是否合法
- 记录并显示历史猜测数据
- 判断游戏结果。判断猜测次数，如果满6次但是未猜对则判负；如果在6次内猜测的4个数字值与位置都正确，则判胜
开始第三个任务
之所以将“验证输入是否合法”放在第三个任务，是因为它不属于happy path的范畴。它属于辅助业务，重要性相对次之。
提示：对于第三个任务，可以采用Specification By Example的方式来考虑测试用例。
问题：参数 vs. 字段
学员在定义执行该任务的类时，一种可能性是将输入的答案作为类的构造函数参数。例如：
new InputValidator("1 2 3 5").validate();
存在两个错误：
- 错误地判断了输入值的生命周期。什么内容应该放在构造函数中作为参数？换言之，构造函数参数与对象之间的关系是什么？之所以要作为构造函数参数，就是意味着在某种场景下这些参数值应该在创建该对象时就存在。这些参数值与对象“生死与共”，它们的生命周期是保持一致的。如果不是，就不应该作为构造函数的参数。你觉得输入应该作为构造函数吗？如果我要验证另一条输入应该怎么办？再创建一个InputValidator对象吗？
- 违反了阅读直觉。validate()方法验证谁？验证空吗？显然这样的接口违反了主-谓-宾的语法。
问题：封装的Answer与输入
既然已经封装了Answer对象，为何validate()方法还是要接收字符串类型的输入？阅读需求，已可寻求到答案。
问题：引入InputValidator类型是否有必要？
多数人会认为这里的验证逻辑与Answer相关，根据前面提到的“信息专家模式”，似乎应该将验证逻辑放到Answer中。然而，这里的需求明确地表示了，如果输入不符合要求，就不允许创建该Answer，而是抛出异常。所以，这里的部分验证逻辑是在创建Answer之前就应该存在，当然就不应该由Answer承担了。
针对第三个任务，验证结果的逻辑不应该由boolean型或错误码来表现。对于表达一种错误规则来说，如果你将其看做是一种业务规则，最好的表达方式是采用自定义异常，除非这门语言允许返回两个值（例如Go语言支持返回多个字，但并不支持异常）。对此，在第二个任务中已有描述，这里不再赘述。
重构：Answer的验证逻辑
在开发第二个任务时，我们已经在Answer类中定义了validate()方法。现在，InputValidator类又提供了validate()方法，且其中部分逻辑是相同的。在实现时，应该如何重构现有代码？
