命令式与疑问式方法
实现类时，更好的做法是返回方法的值（疑问式）还是直接在方法内直接操作类属性（命令式）。
例如，我有一个类，它构建一个要输出到 CSV 文件的字符串。我可能会这样做：
String output = ""
String records[] = //list of record strings
void extract()
extractHeader()
extractRecords()
void extractHeader()
output += "FirstName,LastName,PhoneNumber"
void extractRecords()
For Each record In Records
output += records.toString()
或者，我可能会这样做：
void extract()
output += extractHeader()
output += extractRecords()
string extractHeader()
// return header string
string extractRecords()
// return records as string
这只是个人喜好问题，还是有普遍接受的最佳实践指南？
干杯，
安德鲁
When implementing a class, is it better practice to return a value for methods (interrogative) or to simply manipulate class attributes directly within the method (imperative).
For example, I have a class which builds a string to be output to a CSV file. I might do it this way:
String output = ""
String records[] = //list of record strings
void extract()
extractHeader()
extractRecords()
void extractHeader()
output += "FirstName,LastName,PhoneNumber"
void extractRecords()
For Each record In Records
output += records.toString()
Or, I might do it this way:
void extract()
output += extractHeader()
output += extractRecords()
string extractHeader()
// return header string
string extractRecords()
// return records as string
Is it simply a matter of personal preference, or is there a generally accepted best practice guideline?
Cheers,
Andrew
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
关注点分离是我的衡量标准（而且它也不是一个硬性的衡量标准）。这通常与保持程序DRY直接相关。
这是我看到的两个问题：逻辑和用法。
extractRecords的核心逻辑是运行 for 循环。如果您想再次重用该逻辑，那么您的第一个选择现在将该逻辑紧密耦合（而不是 松耦合）与该逻辑的非常具体的应用/使用。这种想法就是为什么我默认总是倾向于函数式编程，而不是任何需要状态或面向对象的东西（如果可以的话）。
这篇文章也相关，也许只是同一件事的不同措辞： "tell,不要问”。
Separation of Concerns is my metric (and it's not a hard-and-fast one either). This really is often directly related to keeping programs DRY.
Here are the two concerns that I see: logic and usage. The core logic of
extractRecordsis to run a for loop. If you ever wanted to re-use that logic again, your first option now has that logic very much coupled (as opposed to loosly-coupled) with a very specific application/usage of that logic.This thinking is then why I will by default always lean toward functional programing and not anything requiring state or Object-Oriented-ness if I can.
Also related and perhaps maybe just a different wording of the same thing is this article: "tell, don't ask".
阅读可在此处预览的《Code Complete 2》一书的第 5 章：http://www.cc2e.com/< /a> 它将耦合纳入适用于该问题的角度。
Have a read of Chapter 5 of Code Complete 2 book available for preview here: http://www.cc2e.com/ It puts coupling into perspective that is applicable for this question.