确定注射剂和测试单位

Question

比方说，我们有一个类，至少有一个可见方法和几个私有方法。可见的方法调用私有的方法，私有的方法调用其他私有的方法，以此类推。在这个类中，有一个 单元测试 100%覆盖了这个类的所有路径，包括它的私有方法。

在某些时候，开发者决定在另一个类中提取一些私有方法，因为原类太大。提取的代码没有机会重用，因为它只能用于原类。

现在有第二个类需要在某个地方被实例化，以便能够使用它的方法。新类现在有一个可见的方法。

问题：新类是否应该是一个依赖关系？

1. 新类是否应该是一个依赖关系，这是一个问题。依赖注入? 还是认为它是一个帮助器，可以在有意义的地方实例化（构造函数或方法）？
2. 我们是否应该为新类写一个额外的单元测试？
3. 如果新类的可见方法中的参数在原类中已经验证过，是否应该再次验证？

这个问题很笼统，没有具体的例子。

Answer 1

你所遇到的代码气味叫做 构造函数超注 而您的重构结果与 门面服务重构 其中 DIPP&P (§6.1.2，第168页))的定义是：。

一个门面服务隐藏了一个自然的互动集群，它是一个自然的服务集群。依赖性的行为，以及他们在单一 抽象.

然而，要想让你的重构成为Facade Services的重构，它规定使用一个新的抽象，并且抽象的行为隐藏了一个或多个依赖关系。如果提取的逻辑有 无依赖性，并且不包含易失性行为（见下文），可以考虑将该方法做成静态的。

1 新类应该是一个依赖注入的问题？还是把它看作是一个助手，可以在有意义的地方（构造函数或方法）实例化？

这两种方案都是可行的，什么是最好的解决方案取决于很多因素。你可能要问自己的事情是

• 提取的逻辑是否和原来的类属于同一个模块？ 如果不属于，那么 拨码 规定将外部代码隐藏在抽象后面，并将其注入构造函数中。
• 提取的逻辑是否包含 反覆无常? 换句话说，它的逻辑是否需要以任何方式或形式被替换（比如在测试过程中被Mocked，利用 策略模式或装饰或拦截以适用于 贯穿各领域的问题)? 在这种情况下，行为应该被抽象并注入到构造函数中，因为否则会阻碍可测试性和可维护性。
• 该帮助类的依赖关系是否会定期变化？ 在这种情况下，至少应该将依赖关系注入到构造函数中，因为否则的话，帮助类的依赖关系的变化会波及到消耗类。

一般来说，我倾向于说，你最好的选择是为这个助手类定义一个新的抽象，并将其注入到构造函数中。当有疑问时，我当然会选择最后一种，因为定义新的抽象有时会导致对应用程序领域的新见解。

2 我们是否应该为新类写一个额外的单元测试？

这要看情况。从测试的角度来看，你仍然可以决定将类和它的助手一起测试。这可以让你保持测试中的逻辑不变。复杂的类往往会带有一套复杂的测试。从这个角度来看，隔离测试两个类可能是有意义的，也许有一些测试可以在集成中测试两个类。如果你的测试已经覆盖了大部分情况，你应该可以重用大部分的测试代码。

3 如果新类的可见方法中的参数已经在原类中验证过，是否应该再次验证？

如果你发现有重新验证一组参数的冲动，可以考虑将它们提取到一个 参数对象. 参数对象的构造函数可以进行验证，你可以将参数对象从客户端传递给消费者，从消费者传递给帮助者。