我是一名大一的计算机科学专业学生。我们目前正在使用Java进行编程，我经常尝试将我的程序分解成命名良好的方法，以便我的主方法逻辑尽可能接近伪代码。
但问题在于，我发现自己经常写了很多小的私有方法，感觉可能有些过头了。在决定是否进一步分解问题时，有没有什么好的经验法则或风格上的考虑？
5个回答
13
经验法则是 单一职责原则。每个代码单元应该只负责一个事情。这适用于方法以及类。如果你可以给你的许多私有方法中的每一个都取一个简单、精准的名字，那么它就是没问题的。但是如果你只能将其描述为“大型操作”的一部分，那么它可能不应该成为单独的方法。
但从你的问题来看，似乎你已经做得很好了。
- jalf
10
大多数新开发人员会采用另一种方式 - 包含多个职责的巨大函数。与此相比，您的情况无疑更可取！
创建许多小方法几乎没有负面影响，但有很多优势！
短小的方法：
- 更容易重用
- 更容易测试
- 更易于阅读和理解
- 更易于调试
考虑到这一点，我建议您毫不留情地将重复内容重构为小方法。您的IDE将提供提取方法的重构工具以加快速度。
我认为，你的目标是追求可读的伪代码，总体上是一个好的想法。很多代码不会像这样编写，但它可以真正帮助可读性和“代码是文档”的概念。
有些人会谈论方法调用的性能开销，但只有在非常罕见的情况下才会对您构成问题。
编辑-其他帖子中提到了单一职责原则。尽管这是一个很好的指导方针，但我个人认为这超出了这个范围。即使某个代码片段具有明确定义的一个职责，也可能会分解以实现重用和可读性。
- Benjamin Wootton
1
它取决于情况。过多（或者说太小）的方法并不能提高可读性。一个方法可以变得如此之小，以至于它并没有告诉你有关你试图理解的程序的任何信息。但在合理范围内，你是对的，短的方法更可取。 - jalf
2
我的理念是将代码分解成原子化的逻辑单元，每个单元只处理一个任务。通常我会为其命名，并将其放入一个方法中，并给该方法命名。
- Noel M
2
我的一般规则是，如果一个函数不能适应单个屏幕（考虑旧的24行80列终端），那么必须有一个很好的理由。有时确实如此。您必须记住，通常情况下，任何阅读您的函数的人都必须理解整个函数。当它很长时，这更难做到。
话虽如此，两三行的函数并没有太多作用。它们通常太容易理解了，而且您给它们的名称在嵌入某些较长函数时不会传达太多信息。
总是有例外。没有正确的方法。您的经验将随着工作的进行而提高。
话虽如此，两三行的函数并没有太多作用。它们通常太容易理解了，而且您给它们的名称在嵌入某些较长函数时不会传达太多信息。
总是有例外。没有正确的方法。您的经验将随着工作的进行而提高。
- Andrew
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接