Java 中的私有辅助方法与公共静态实用程序方法

Question

我有一个正在变长的 Java 类。 当我通过代码质量工具运行它时，我被标记为类中的行数。

这是一个较低层的类，由带有Spring 的@Autowired上层使用。 该类有许多非静态的私有实例方法。 它们不使用任何实例字段，只处理方法参数。

我可以在某个单独的实用程序类中安全地将这些方法作为public static方法移动吗？ 有什么缺点？

Answer 1

这里的“错误”心态。

你没有重做你的课程，因为工具抱怨这个或那个。

您希望提高源代码的质量 ; 这些工具可以帮助识别“值得思考的主题”。 你把他们的反馈作为暗示 ; 不是“秩序”。

因此，您不必担心类中的“代码行”。 相反，您担心这门课的责任 。 含义：行号计数本身不是问题 - 但违反单一责任原则的是。

因此：你退后一步，看看你班上到底在做什么。 当它显然不止一件事时，你将这些方面提取到其他类中！

含义：如果您确实发现所有这些代码都“属于”该类的责任; 然后把它留在那里。 不要开始将内部实现细节放入不相关的帮助程序类中; 只是因为某些工具会警告你行数。

另一方面，将私有方法转换为静态/包保护的东西将允许您对这些方法进行单元测试。 这可能是一个优势。 但正如所说：只要我们谈论实施细节 ，他们应该保持私密; 并且他们不应该进行单元测试。

长话代码：了解并理解“干净代码”的含义; 并尝试遵循那里概述的想法。

Answer 2

方法的划分应该是目的/应用/逻辑（你的名字），而不是技术属性。

长源代码可以分成几个小的类，每个类都有自己独立的目的/责任。

Answer 3

我经常使用包含静态方法的Utility类，并且发现它非常方便。 如果这些方法仅供单个类使用，则可以将Utility类作为静态私有类放在原始类中。 但是我发现在很多情况下，一些静态实用程序方法可以被几个类使用，所以在这种情况下我创建一个单独的实用程序类，其中包含一组可以由几个类使用的静态方法。

另外，我非常赞同GhostCat在一般思维方面的答案。 至于班级的规模 - 这可能是一个问题，但通常我不担心这么多。 我真正寻找的是你的方法的大小。 我喜欢简短和自我解释的方法，从名称和参数名称和顺序以及逻辑开始。 如果有大块内部逻辑 - 将其提取到单独的方法中。 这使得代码更易于阅读和维护。

Answer 4

代码质量无法通过行数来衡量。 如果您发现类文件日益增长，请确保您的课程遵循单一责任原则。

当您的课程不遵循原则时，将它们分成单独的类并将类分成一个包。

否则，您可以将基类作为抽象类 ，并将您的util方法设为abstract 。 有一个子类，它扩展了基类，为基类中的抽象方法提供了实现。

当你可以将你的方法设置为静态时，这是一个很好的答案

正如@Zack Jannsen所说，

当您知道某些事物不会在实例中发生变化时，“静态”通常很有价值。 如果是这种情况，我会真正考虑“单一责任原则”，这意味着一个班级应该有一个责任，因此只有一个改变的理由。 我觉得应该考虑将“ConvertMpgToKpl（双mpg）”函数和类似的方法移动到他们自己的类中。 汽车对象的目的是允许汽车的实例化，而不是在它们之间进行比较。 那些应该是班级的外部。

虽然static允许您在没有创建对象的情况下访问该方法，但在尝试将该方法设置为静态时，请始终记住以下内容

• 该方法根据输入参数生成一致的结果
• 你总是需要那个方法在内存中（即;你经常需要这个方法） - 访问一个巨大的方法可能会更好，这个方法在对象创建的帮助下只能访问很少次，而不是通过static访问它
• 经常使用的实用方法可以是static

Answer 5

在我看来，使用正在执行一些“魔术”的私有方法有点危险，因为您无法真正对其进行单元测试。 是的，您当然可以对调用该私有方法的公共方法进行单元测试，但请考虑一下您将拥有的渐近复杂性。 通常我更喜欢为这些方法使用实用程序类并编写一些大量的单元测试。