我同意所有声称这破坏了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()”方法更好地实现基于先前选择的默认值的概念。

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

Paulo Abrantes提供了另一种使JavaBean setter流畅的方法:为每个JavaBean定义一个内部构建器类。如果您正在使用的工具被返回值的setter弄得不知所措，Paulo的模式可能会有所帮助。

如果你不想从setter返回'this'，但又不想使用第二个选项，你可以使用下面的语法来设置属性:

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

顺便说一句，我认为它在c#中略干净:

list.Add(new Employee() {
    Name = "Jack Sparrow",
    Id = 1,
    Foo = "bacon!"
});

从声明中

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

我看到两件事

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

我不懂Java，但我用c++做过。 也有人说这会让文字变得很长，很难读懂， 但我这样做过很多次:

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

这个更好:

list.add(
    new Employee("Jack Sparrow")
    .Id(1)
    .foo("bacon!"));

至少我是这么认为的。但如果你愿意，欢迎你给我投反对票，称我为糟糕的程序员。我不知道Java中是否允许这样做。

我过去更喜欢这种方法，但我已经决定不这么做了。

原因:

可读性。将每个setFoo()放在单独的行上可以使代码更具可读性。通常情况下，您阅读代码的次数要比编写代码的次数多得多。 副作用:setFoo()应该只设置字段foo，没有其他。返回this是一个额外的“WHAT was that”。

我看到的Builder模式没有使用setFoo(foo). setbar (bar)约定，而是使用了更多的foo(foo).bar(bar)。也许正是出于这些原因。

这总是一个品味问题。我只是喜欢“最少惊喜”的方法。