分步重构静态方法vs包装和委派

在处理遗留代码时，我经常遇到这样的问题：必须重构包含静态方法或完全是静态方法的类。

我之前谈到过重构助手类，但这有点不同。

在本例中，我想讨论重构类，您希望保留这些类，但这些类具有所有或多个静态成员。

这种类是否真的是某个助手类并不总是很清楚，这是一个判断调用，但是如果你真的找到了助手类，不要把它放在那里。

所以，基本上，如果你已经确定你正在使用的类将继续存在，但是它确实有静态方法，你需要摆脱它们，因为你正在进行依赖注入或模拟，请继续阅读。

定义两种方法

我说的分步重构是什么意思？

以下是第一种方法的基本概述：

1. 使您需要的方法成为非静态的、非静态的。

2. 添加一个只包含该方法的接口。

3. 实现接口。

4. 更改对该方法的引用以使用接口。

我们来看一个例子：

如果我们对GetLostOrders方法感兴趣，我们可以应用步骤1-3来获得：

现在我们可以在代码中为这一个方法更改引用。

现在让我们看看第二种技巧，包装和委派。下面是包装和委派方法的概要：

1. 创建一个包装类，用于包装静态类调用。

2. 将静态类中的所有方法实现为包装类中的非静态方法。每个方法只委托给静态类中的静态方法。

3. 创建一个包含所有方法的接口。

4. 拥有包装器类实现接口。

下面是一个这样做的示例，给出了与第一个示例相同的原始代码：

对LostOrderService的引用将被重构，与第一个示例中的重构完全相同，所以这里不包括它。

你可以在这个例子中看到，我们没有触及LostOrderService本身，只是你可能想在类上放置一个过时的属性，告诉用户不要使用它，而是使用包装类。

哪个更好？

过去我倾向于使用包装和授权的方法，但我开始认为分步方法更好，原因有几个：

• 对于以后使用该类的人来说，分步方法更为明显。当您包装并委托时，必须有人知道有一个包装类。使用分步方法时，别无选择。

• 使用分步方法时，实际上是在摆脱坏的和有害的静态方法。当您包装并委托时，您仍然把它们留在那里，只是把它们藏在包装袋里。

对我来说，包装方法更像是我在处理事情，而不是清理它们。我还觉得有人可以看到我开始的东西，然后一步一步地从那里捡起来。如果使用包装方法，混乱可能永远不会得到清理，因为有一个解决办法。

包装和委派的闪耀之处

如果您无法控制静态类或静态调用的源代码，则无法执行分步方法。

当您处理代码中对无法更改的外部库的静态引用时，wrap和delegate方法可以成为救命稻草。您可以简单地包装外部库调用，而不是在代码中引用包装器。现在您可以实际对代码进行单元测试。

无论何时使用外部库，您都应该考虑在其周围放置某种保护性包装。您永远不知道何时需要替换它或升级库。您不想在所有代码中查找引用。

因此，尽管这两种方法都可行，但如果我可以访问静态类的源代码，我更喜欢使用分步方法。

你觉得呢？你还有别的解决办法吗？评论区里告诉我哦！