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

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

---

我发现的问题是，我经常会写很多小的私有方法，我觉得我可能做得太多了。在决定是否进一步分解问题时，有什么好的经验法则或风格考虑因素需要考虑吗？

我的理念是将代码分解为原子的、逻辑的单个工作单元。我通常可以给它起个名字，然后我把这个工作放到一个方法中，给它起个名字。

我认为分解代码最重要的部分是。每个对象都应该有一个单独的职责，并且该职责应该完全由类封装。

经验法则是。每个代码单元应该只负责一件事。这适用于方法和类。如果您可以为您的许多私有方法中的每一个都指定一个简单、简洁的名称，那么就可以了。如果您只能将其描述为更大操作的“一部分”，那么它可能不应该是一个单独的方法

---

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

大多数新开发人员都选择了另一种方式——巨大的功能需要承担很多责任。你的处境比这更好

创建许多小方法没有什么坏处，也没有什么好处

简短的方法包括：

• 易于重用
• 更容易测试
• 易于阅读和理解
• 易于调试

考虑到这一点，我建议您无情地将重复重构为小方法。您的IDE将为您提供一个提取方法重构，以加快速度

我还认为，一般来说，你的目标是创建一种可读的伪代码。您看到的许多代码都不会这样编写，但它确实有助于可读性和“代码就是文档”的概念

有些人会谈论方法调用的性能开销，但只有在极少数情况下才会引起您的关注

---

编辑-其他海报提到了单一责任原则。虽然这是一个很好的指导方针，但我个人认为它比这更进一步。甚至一些具有明确定义的职责的代码片段也可能被分解以实现重用和可读性

我的一般规则是，如果一个函数不适合在一个屏幕上（想想一个旧的24行80列终端），最好有一个很好的理由。有时会有。您必须记住，一般来说，任何阅读您的函数的人都必须理解整个内容。当时间很长时，这就很难做到

也就是说，两行或三行函数不会增加太多。它们本身往往太容易理解，当嵌入到一些较长的函数中时，您给它们起的名字不会像代码本身那样传达更多的信息

---

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

这要看情况而定。太多（或者更确切地说，太小）的方法不利于可读性。一个方法可能会变得很小，以至于它不能真正告诉你关于你试图理解的程序的任何事情。但在合理的范围内，你是对的，简短的方法更可取。谢谢大家给出的好答案。非常感谢