1

当我编写一个方法时，我尝试将该方法中的代码块提取到私有方法中。

例如，如果我需要转换其中一个输入参数，我会创建一个私有方法来接受参数值并返回转换后的值。我从“main”方法的主体中调用这个私有方法——本质上，我尝试将转换操作封装在私有方法中并适当地命名该方法。

我真的在寻找人们是否认为这种通用方法是个好主意的答案。我从其他开发人员那里得到了不同的反馈，其中一些人赞成将所有代码保留在一种方法中。我认为小型私有方法封装了这些单一任务，他们认为如果代码保留在一个方法中，则类会保持清洁。

很高兴从社区获得一些关于您认为哪种方法反映了更好的设计或更符合 OOP 原则的答案。

4

3 回答 3

1

我通常出于多种原因这样做：

  • 它有助于重用。
  • 它使方法具有单一的职责。这反过来又使他们很容易传达他们的目的。我认为SRP不仅适用于类，也适用于方法。
  • 它使方法易于阅读和理解。我的方法一般不超过 6 或 7 行。
  • 它使以后重构它们变得容易（例如，如果您需要将某些行为解耦到另一个对象中，这在系统发展时很常见）。

作为一般的经验法则，我使用必须在方法体中添加注释来解释正在发生的事情是一种气味，这意味着它可以被重构为更小的部分。

高温高压

于 2012-11-07T16:46:34.563 回答
1

简而言之，这通常是一个好主意。

有关更多信息，请查看来自 DeveloperWorks的 Neal Ford 的Composed Method文章。在本文中，Neal 说明了如何重构私有方法，从而隔离适合重用的代码区域。

这个练习真正重要的好处是能够收集可重用的代码。查看清单 1 中的代码时，您看不到可重用资产；你只看到一堆代码。通过将 olio 方法分开，我发现了可重用资产。但其优势不仅仅在于重用。我还为处理应用程序中的持久性的简单框架奠定了基础。当需要创建另一个简单的边界类来从数据库中获取一些实体时，我已经有代码可以帮助我做到这一点。这是提取框架而不是在象牙塔中构建框架的本质。

于 2012-11-07T16:36:20.670 回答
0

一般来说，您应该在更多地方放入您需要的方法代码（为了不重复自己）。

如果一个方法很长，将代码放入其他方法中也是有意义的，那么将其拆分为多个方法可能是有意义的。

于 2012-11-07T16:30:04.563 回答