从声明中

list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!"));

我看到两件事

1)毫无意义的话。 2)缺乏可读性。

这个方案(双关语)，称为“流畅界面”，现在变得非常流行。还可以接受，但不是我的菜。

从声明中

list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!"));

我看到两件事

1)毫无意义的话。 2)缺乏可读性。

坏习惯: setter集 getter get

如果显式地声明一个方法，为U

setPropertyFromParams(array $hashParamList) { ... }

如果可用，最好使用其他语言结构。例如，在Kotlin中，您可以使用with、apply或let。如果使用这种方法，实际上不需要从setter返回实例。

这种方法允许你的客户端代码:

对返回类型漠不关心 更容易维护 避免编译器的副作用

这里有一些例子。

val employee = Employee().apply {
   name = "Jack Sparrow"
   id = 1
   foo = "bacon"
}


val employee = Employee()
with(employee) {
   name = "Jack Sparrow"
   id = 1
   foo = "bacon"
}


val employee = Employee()
employee.let {
   it.name = "Jack Sparrow"
   it.id = 1
   it.foo = "bacon"
}

我同意所有声称这破坏了JavaBeans规范的帖子。有理由保留这一点，但我也觉得使用这个构建器模式(上面提到的)有它的一席之地;只要不是到处都用，就应该是可以接受的。对我来说，“It’s Place”的终点是对“build()”方法的调用。

There are other ways of setting all these things of course, but the advantage here is that it avoids 1) many-parameter public constructors and 2) partially-specified objects. Here, you have the builder collect what's needed and then call its "build()" at the end, which can then ensure that a partially-specified object is not constructed, since that operation can be given less-than-public visibility. The alternative would be "parameter objects", but that IMHO just pushes the problem back one level.

我不喜欢多形参构造函数，因为它们更有可能传入大量相同类型的实参，从而更容易将错误的实参传递给形参。我不喜欢使用大量的setter，因为对象可以在完全配置之前使用。此外，使用“build()”方法更好地实现基于先前选择的默认值的概念。

总之，我认为这是一个很好的实践，如果使用得当。