使用接收对象的方法并在方法中设置该对象的属性而不是返回结果是一件好事吗?
在某些情况下,返回结果将需要两个类似的方法,但有一些差异。
从技术上讲,在途中不需要“代码重复”并且会更快地完成任务,但我认为当没有返回结果时代码不清楚。
HTML分析器示例:
void parseLinks(Page page){
//processing
page.setLinks(links);
page.setEmails(emails);
//page.set...;
}
或
List<Link> getLinks(SomeParameter parameter){
//same processing
return links;
}
List<Email> getEmails(SomeParameter parameter){
//same processing
return emails;
}
page.setLinks(getLinks(parameter));
page.setEmails(getEmails(parameter));
//page.set...
答案 0 :(得分:3)
好的做法是明确区分以某种方式修改域对象的方法和不以任何方式修改它们的方法。当你知道你使用的某些方法不会产生副作用时,在复杂系统中工作会更容易(一般来说,在计算机科学中,所有改变某些对象状态的方法都是非副作用的。)
将尽可能多的程序逻辑放入函数中, 返回结果且没有可观察到的副作用的操作。 严格隔离命令(导致修改的方法) 可观察状态)进入非常简单的不返回操作 域名信息。通过移动复杂来进一步控制副作用 当一个概念符合责任时,逻辑成为VALUE OBJECTS 出现。
(领域驱动设计:解决软件核心中的复杂性,Eric Evans)
答案 1 :(得分:1)
您是否强烈感觉该方法的调用者需要一些信息 一旦被叫者做了一些工作?
如果是,那么你应该退货。
*unit testing will be easy if callee returns something*
答案 2 :(得分:0)
对象数据是封装的。在代码中与对象交互的位置无关紧要。
干杯
答案 3 :(得分:0)
您的示例看起来像函数编程,而不是OOP。 parseLinks应该是Page Class on的一种方法应该在“this”实例上工作,而且 - 如果你在任何页面上以任何方式这样做 - 我建议你在构造函数中这样做。 在完成之后 - getLinks和getEmails看起来像这个对象的常规getter方法。
这就是我在这个例子中看到的情况,但这实际上取决于你想做什么。
好的,现在我在为问题添加一些上下文之后了解更多: 我会实现类似这样的东西 - 在解析方法中我将返回一个 new Page实例(使用clone或将正确的参数添加到构建新实例的方法中),并将其字段设置为一个。像这样的东西:
Page parse(String content){
Page page = new Page()
//processing
page.setLinks(getLinks(content));
page.setEmails(getEmails(content));
//page.set...;
}