我是一年级计算机科学专业的学生。我们目前正在用 java 编程，我经常尝试将我的程序分解为命名良好的方法，以便我的主要方法逻辑可以尽可能接近伪代码。
我发现的问题是，我常常最终编写了如此多的小型私有方法，以至于我觉得我可能做得过火了。在决定是否进一步分解问题时，是否有任何好的经验法则或文体考虑因素需要考虑？
问问题
9667 次
5 回答
13
经验法则是单一职责原则。每个代码单元都应该只负责一件事。这适用于方法和类。如果您可以为您的许多私有方法中的每一个赋予一个简单、简洁的名称，那就没问题了。如果您只能将其描述为更大操作的“一部分”，那么它可能不应该是一个单独的方法。
但从你的问题来看，听起来你已经做得对了。
于 2010-08-16T12:31:15.130 回答
10
大多数新开发人员采取了另一种方式 - 具有许多职责的庞大功能。你的情况比这更可取！
创建许多小方法几乎没有缺点，而且有很多好处！
简短的方法是：
- 更容易重复使用
- 更容易测试
- 更容易阅读和理解
- 更容易调试
考虑到这一点，我建议你无情地将重复重构为小方法。您的 IDE 将为您提供一个提取方法重构，以使其更快。
我也认为你的目标是一种可读的伪代码，一般来说，是一个好的目标。你看到的很多代码都不会这样写，但它确实有助于提高可读性和“代码就是文档”的概念。
有些人会谈论方法调用的性能开销，但只有在极少数情况下你才会担心。
编辑 - 其他海报提到了单一责任原则。虽然这是一个很好的指导方针，但我个人认为它比这更进一步。甚至某些具有明确定义的职责的代码片段也可能被分解以实现重用和可读性。
于 2010-08-16T12:32:55.857 回答
4
我认为分解代码最重要的部分是单一职责原则（SRP）。每个对象都应该有一个单一的职责，并且该职责应该完全由类封装
于 2010-08-16T12:31:11.873 回答
2
我的理念是将代码分解为原子的、逻辑的单个工作单元。我通常可以给它起一个名字——然后我把它放到一个方法中并给它起这个名字。
于 2010-08-16T12:27:01.077 回答
2
我的一般规则是，如果一个功能不适合单个屏幕（想想旧的 24 行 x 80 列终端），最好有一个很好的理由。有时有。你必须记住，一般来说，任何阅读你的函数的人都必须理解整个事情。当它很长时，这更难做到。
话虽如此，两三行功能并没有增加太多。它们本身通常太容易理解，并且当嵌入一些更长的函数时，你给它们起的名字不会像代码本身那样传达更多的信息。
There are always exceptions. There isn't any RIGHT way. Your work will improve with experience.
于 2010-08-16T13:15:33.160 回答