2

据我所知，包含长序列操作的方法被认为是一件坏事，需要重新设计。不仅如此，我听到一个意见，方法不应该大于屏幕（即所有方法代码应该立即在 IDE 屏幕中可见，无需滚动）。

对此有什么一般规则吗？例如，“如果方法超过 15 行，就应该重构”？如果是这样，你如何重构它？只是使用提取方法的方式吗？

4

3 回答 3

6

这取决于你问谁。 罗伯特马丁会告诉你有两条规则：

  1. 方法应该很小。
  2. 一个方法应该比那个小。

不要从行数的角度来考虑它。行数是一个任意且不重要的指标。根据该方法在逻辑上的作用来考虑它。最好的规则是：

  • 一个方法应该做一件事。

或者，换一种更好的方式：

  • 一种方法应该只有一个改变的理由。

（仍然在这里引导鲍勃叔叔，我最近一直在努力实现清洁代码。）

将此与其他逻辑规则结合起来，例如：

而且，一般来说，你最终会得到非常小的方法。然而，也有例外。在许多情况下，“一件事”用一行代码表示，可能是两三行。但它是简单而富有表现力的代码，并且很清楚“一件事”是什么。（当然，方法的名称应该清楚地反映一件事。）

然而，有时，“一件事”是一个较长的步骤序列。也许您有一种方法在您的域中封装了单个原子进程，但该进程恰好由十几个或更多步骤组成。每个步骤都是它自己的“一件事”，并且它可能在内部在其他方法中还有其他“一件事”，依此类推。

每个单独的方法都做“一件事”。但是将较小的步骤聚合成较大的原子过程的高级封装方法会变得更长一些，因为它们的“一件事”是由许多较小的“一件事”组成的。这是罕见的，但它会发生。当它发生时，通常的结果是一个方法，它只不过是一系列方法调用。（这并不是说这是长方法的借口。仔细检查代码的逻辑以确定重构更大的方法是否真的有意义。）

这种更大的封装方法通常是将事务脚本模式应用于业务逻辑的结果。有一个步骤，响应一个请求，它由业务逻辑中的一个多步骤过程组成。

方法应该很小。它们应该比这还要小。如果不是，请仔细检查它们以确定原因。如果有不止一层缩进，这通常表明它应该被重新分解。如果输入中有多个制衡，它可能会使用一些重构。如果方法做不止一件事或有不止一个改变的理由，它肯定应该被重构。

于 2012-07-10T12:12:57.720 回答
0

将大型函数拆分为较小的函数通常是一个非常好的主意。
如果它们设计得很好并且很容易理解正在发生的事情，这不是问题。但功能越大，就越难做到。保持功能简单将使您以后更容易跟踪问题。

于 2012-07-10T12:07:53.057 回答
0

早期的程序员过去常常将他们的方法长度限制在 10 行代码以内。如果他们的方法更长，那么他们将其分开。这是一种过时的编程风格，不再被广泛使用。大多数专家都同意，只要对它们有意义，方法就可以存在。（也就是说，只要没有逻辑断点，它们就不应该被分解）

就个人而言，我争取更短的方法。但话虽如此，除非有一个明显的逻辑断点，否则我不会强调打破一个长的。这样做的唯一原因是它使我的代码更易于阅读和调试；特别是如果方法名称是描述性的。

于 2012-07-10T12:14:52.527 回答