编写返回void的方法是一个好习惯吗？

Question

我正在研究一个由复杂的对象组合驱动的java编码的复杂企业应用程序.例如:在特定情况下,要执行操作,这是流程:

login() -> 
Followed by defined sequence of 10 to 20 method calls in different classes -> 
Followed by a logout()

在框架内,几乎所有操作(包括登录,注销和许多10到20个方法调用)都没有返回类型.任何错误的行为都由框架处理.说,在登录

public void login(){
try{
 //login actions
 //chained sequence of calls

}catch(){
 // framework handling exceptions and other rollback options
}
}

中间10到20个动作是对框架的不同层次结构的不同对象的方法调用.

随机类看起来像这样:

class someobject{

def variable

void action1(){ do something on variable }
void action2(){ do something on variable }
...
}

变量经常改变状态,这些动作只有一个我觉得很烦人的框架定义的序列.

我会说,或许如果有适当的返回类型或者至少有一些这样的方法,就像在布尔的情况下那样login(),生活将会轻松得多.由于对一系列空隙返回功能的严格遵守,我发现很难通过调试来理解流程,单元测试也成了我的噩梦.

所以现在,我的印象是,编写返回内容的函数总是更好,特别是当涉及一系列操作时.那么,这是一个安全的推定吗？我想对此发表意见.如果我错了,请纠正我.

Answer 1

方法的最基本的可测试性是通过其返回码。在login您需要（如您所述）的情况下，可以测试您现在是否已登录，并且boolean返回显然是一种方法。否则，您必须检查某些属性，这似乎不必要地是非原子的且复杂的（尽管出于其他原因可能需要）。

对我而言，此论点扩展到任何有意义的方法。使用void返回码非常普遍，但这更多是由于过时的习惯，而不是出于良好的设计原因。简单的属性设置器是一个反例，我敢肯定还有其他一些。