使用局部变量重构的最佳实践答案

【问题标题】：Best Practices for Refactoring with local variables使用局部变量重构的最佳实践
【发布时间】：2009-02-10 19:45:53
【问题描述】：

我一直在花一些时间重构我的 C# 代码，我对局部变量的参数列表变得如此之大感到震惊，尤其是当您开始深入几个级别并且必须从更高层传递局部变量时调用堆栈。

例如，我有一些使用 Linq to sql 的相当复杂的代码。我在过程的早期实例化数据上下文并在整个过程中使用它。但是，在重构之后，我发现我在所有子方法中都传递了这个 DC，以及其他各种状态变量。

当然，一种解决方案是将这些局部变量变为成员变量，但这会使整个类成为非线程安全的，并且在处理异步 i/o 时，这意味着使用锁和互斥锁来破坏事物以使其安全.

在考虑局部变量时，您的最佳做法是什么？你让他们成为会员吗？还是您随身携带国家行李？还是你做别的事？

编辑：我不确定您需要更多详细信息。我不想转储一堆代码，因为本质上为了说明这一点，我必须展示一组非常复杂的程序。

我有许多局部变量，例如 Linq to Sql DC、处理的各个阶段、处理并写入数据库的大量原始数据的各个更新阶段。

我想过创建一个状态上下文并传递它，但这对我来说似乎有点骇人听闻，尽管我想这正是 Linq to SQL dc 的内容。

【问题讨论】：

【解决方案1】：

不要不要将它们变成成员/全局变量。即使没有多线程，它们也使关于应用程序状态的推理变得更加困难 - 正如您所说，有了它，它就变成了一场噩梦。

如果您注意到某些参数总是以组的形式传递，您可以尝试将它们折叠成简单的对象并传递它们。

【讨论】：

【解决方案2】：

可能，让它们成为另一种类型的成员。嵌套类型在这里也能很好地工作。如果它们形成一个逻辑组，并且让您使用相同的类型编写多个方法，那就很有意义了。

除此之外，我怀疑我们必须知道你正在做什么的细节才能进一步发表评论。

【讨论】：

【解决方案3】：

取决于项目。我试图以单一职责规则为目标，它允许我像疯子一样重构。

碰巧我创建了虚拟持有者类来保存我需要传递的信息。我也不喜欢为我的方法设置超过 1 或 2 个参数，但这取决于信息的重要性以及项目的重要性。

【讨论】：