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

分步重构 静态方法 包装 委派
2021-01-27 11:21:22
7 0 0

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

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

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

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

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

定义两种方法

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

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

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

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

  3. 实现接口。

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

我们来看一个例子:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

哪个更好?

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

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

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

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

包装和委派的闪耀之处

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

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

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

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

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

作者介绍

用微信扫一扫

收藏