从类中分解所有依赖项的最简单、最快的方法

Posted 2023-03-07

【中文标题】从类中分解所有依赖项的最简单、最快的方法

【英文标题】：Simplest, fastest way to break out all dependencies from a class

【发布时间】：2011-03-10 02:35:53

【问题描述】：

在处理遗留代码并尝试创建测试时，我经常从类或方法中分离出依赖项，以便我可以为这些依赖项使用模拟来编写单元测试。依赖关系最常见的形式是调用静态类和使用构造函数中的 new 关键字或该类中的其他位置创建的对象。

在大多数情况下，静态调用是通过包装静态依赖项来处理的，或者如果它的单例模式（或类似模式）以 StaticClass.Current.MethodCall() 的形式通过其接口传递该依赖项，则转而使用构造函数。

在大多数情况下，在构造函数中使用 new 关键字只是通过在构造函数中传递该接口来代替。

在大多数情况下，在类的其他部分使用 new 关键字，可以通过与上述相同的方法来处理，也可以根据需要创建一个工厂，并在构造函数中传递工厂的接口。

我总是使用 Resharpers 重构工具来帮助我完成所有这些突破，但是大多数事情仍然是手工劳动（可以自动化），而且对于一些遗留类和方法来说，这可能是一个非常乏味的过程。在这个过程中是否有任何其他重构插件和/或工具可以帮助我？是否有“一次单击即可从此类中打破所有依赖项”的重构工具？ =)

在我看来，所有这些步骤对于许多开发人员来说都很常见，也是一个常见问题，在我尝试向 Resharper 或 CodeRush 编写插件之前，我必须问一下，因为可能已经有人尝试过这个了..

添加：

反思下面的答案：即使您可能不想一次分解所有内容（单击总分解可能会导致更多问题而不是帮助）仍然能够简单地分解 1 个方法依赖项，或 1-2容易依赖，会有很大的不同。

此外，重构代码具有“尝试看看会发生什么，只是为了了解所有内容如何组合在一起”的衡量标准，即使您不签入该代码，一键式总突破也将有助于该过程大量......

【问题讨论】：

除了下面提到的经典有效地使用遗留代码之外，您可能会发现 .NET 中的棕地应用程序开发很有趣：manning.com/baley

【参考方案1】：

我认为没有任何工具可以为您自动执行此操作。使用遗留代码意味着 - 如您所知 - 一次只需少量步骤即可更改代码。这些步骤通常故意很小，以防止出现错误。通常，您应该进行的第一个更改是使该代码可测试。编写完测试后，您可以更改该部分代码以修复错误或实施 RFC。

因为您应该采取小步骤，所以我认为很难使用重构工具神奇地使您的所有依赖项消失。对于遗留系统，您几乎不会想立即进行重大更改，因为破坏的风险（并且由于缺乏测试而无法发现）太大了。然而，这并不意味着重构工具在这种情况下没有用。相反;他们帮助很大。

如果您还没有阅读，我建议您阅读 Michael Feathers 的书 Working Effectively with Legacy Code。它详细描述了一系列模式，可帮助您将遗留代码重构为更可测试的系统。

祝你好运。

【讨论】：

我真的要读那本书了！你的回答有很多道理，所以+为此！但是，即使您可能不想一次分解所有内容（单击总分解可能会导致比它帮助更多的问题）仍然能够简单地分解 1 个方法依赖项或 1-2 个依赖项，这将是很大的区别。此外，重构代码具有“尝试看看会发生什么，只是为了了解所有内容如何组合在一起”的衡量标准，即使您不签入该代码，一键式总突破将有助于该过程吨。

现在阅读了那本书，我仍然会发现这样的工具很有用，即使我可能不想签入代码。但简单地了解现有依赖项是非常有用的。每个方法、每个类或我需要更改的代码的任何部分，从而为其编写测试。此外，阅读那本书后，我也对这个工具如何实际帮助以可选的方式来实际打破依赖关系有了很多想法。

@MatteS：看看 NDepend。它允许您可视化系统各部分之间的依赖关系。

【参考方案2】：

当涉及到静态调用依赖时，您可能需要查看Moles。它能够在运行时进行代码注入，以使用您自己的测试实现排除任何静态或非虚拟方法调用。这对于测试未使用可测试的依赖注入接口设计的遗留代码非常方便。