在java中分解，什么时候足够了？

Question

我是第一年的计算机科学专业的学生。我们目前正在用java编程，我经常尝试将我的程序分解为命名良好的方法，以便我的主方法逻辑可以尽可能接近伪代码。

我发现的问题是，我经常写这么多小的私人方法，我觉得我可能会过度使用它。在决定是否进一步分解问题时，是否有任何良好的经验法则或风格考虑因素需要考虑？

Answer 1

经验法则是Single Responsibility Principle。每个代码单元都应该对一个事物负责。这适用于方法和类。如果您可以将简单，简洁的名称添加到 的每个私有方法中，那么它就没问题了。如果你只能将它描述为一个更大的操作的“一部分”，那么它可能不应该是一个单独的方法。

但是从你的问题来看，听起来你已经做对了。

Answer 2

Answer 3

我认为分解代码最重要的部分是Single Responsibility Principle (SRP)。每个对象都应该承担一个责任，并且该责任应该完全由类

封装

Answer 4

我的理念是将代码分解为原子的逻辑单一工作单元。我通常可以给出一个名字 - 然后我将这项工作放入一个方法并给它起名字。

Answer 5

我的一般规则是，如果一个功能不适合单个屏幕（想想旧的24行80列终端），那么最好有充分的理由。有时会有。你必须记住，一般来说，阅读你的功能的任何人都必须了解整个事情。当它很长时，那就更难了。

话虽如此，两三线功能并没有增加多少。它们通常很容易理解，当你嵌入一些较长的函数时，你给它们的名称不会传递与代码本身一样多的信息。

总有例外。没有任何正确的方法。你的工作将随着经验而改善。