为什么链式装订工非常规？

在bean上实现链接非常方便：无需重载构造函数，大型构造函数，工厂，并提高了可读性。我想不出任何弊端，除非您希望对象是不可变的，在这种情况下，它就不会有任何设置方法。那么，这不是OOP约定的原因吗？

public class DTO {

    private String foo;
    private String bar;

    public String getFoo() {
         return foo;
    }

    public String getBar() {
        return bar;
    }

    public DTO setFoo(String foo) {
        this.foo = foo;
        return this;
    }

    public DTO setBar(String bar) {
        this.bar = bar;
        return this;
    }

}

//...//

DTO dto = new DTO().setFoo("foo").setBar("bar");

那么，为什么这不是OOP约定呢？

我最好的猜测：因为它违反了CQS

您已经将命令（更改对象的状态）和查询（返回状态的副本-在这种情况下，对象本身）混合到了同一方法中。这不一定是问题，但确实违反了一些基本准则。

例如，在C ++中，std :: stack :: pop（）是返回void的命令，而std :: stack :: top（）是返回对堆栈顶部元素的引用的查询。传统上，您希望将两者结合起来，但是您不能这样做并且要保证例外安全。（在Java中不是问题，因为Java中的赋值运算符不会抛出）。

如果DTO是值类型，则可能会达到类似的目的

public DTO setFoo(String foo) {
    return new DTO(foo, this.bar);
}

public DTO setBar(String bar) {
    return new DTO(this.foo, bar);
}

同样，在处理继承时，链接返回值是一个巨大的痛苦。请参阅“奇怪的重复模板模式”

最后，存在一个问题，默认构造函数应让您保留处于有效状态的对象。如果必须运行一堆命令以将对象恢复到有效状态，则说明出现了非常错误的情况。

1. 节省一些击键并不引人注目。可能不错，但是OOP约定更关心概念和结构，而不是按键。

2. 返回值是没有意义的。

3. 由于用户可能期望返回值具有意义，因此返回值甚至比毫无意义的还容易产生误导。他们可能期望这是一个“不变的二传手”

   public FooHolder {
       public FooHolder withFoo(int foo) {
           /* return a modified COPY of this FooHolder instance */
       }
   }
   

   实际上，安装员会更改对象。

4. 它不能很好地继承。

   public FooHolder {
       public FooHolder setFoo(int foo) {
           ...
       }
   }
   

   public BarHolder extends FooHolder {
       public FooHolder setBar(int bar) {
           ...
       }
   } 
   

   我会写

   new BarHolder().setBar(2).setFoo(1)

   但不是

   new BarHolder().setFoo(1).setBar(2)

对我来说，＃1至＃3是重要的。编写良好的代码不是关于排列整齐的文本。编写良好的代码是有关基本概念，关系和结构的代码。文本只是代码真正含义的外在反映。

我认为这不是OOP约定，它与语言设计及其约定有关。

看来您喜欢使用Java。Java具有JavaBeans规范，该规范将setter的返回类型指定为void，即它与setter的链冲突。该规范被广泛接受并以多种工具实现。

当然，您可能会问，为什么没有链接规范的一部分。我不知道答案，也许那时这种模式还不为人所知。

正如其他人所说的，这通常被称为流利的界面。

通常，setter是调用程序传入的变量，以响应应用程序中的逻辑代码。您的DTO班就是一个例子。设置程序什么都不返回的常规代码对此通常是最好的。其他答案已经解释了方式。

但是也有少数情况下，流畅的界面可能是一个很好的解决方案，这些有共同之处。

• 常量通常传递给二传手
• 程序逻辑不会更改传递给设置器的内容。

设置配置，例如fluent-nhibernate

Id(x => x.Id);
Map(x => x.Name)
   .Length(16)
   .Not.Nullable();
HasMany(x => x.Staff)
   .Inverse()
   .Cascade.All();
HasManyToMany(x => x.Products)
   .Cascade.All()
   .Table("StoreProduct");

使用特殊的TestDataBulderClasses（对象母亲）在单元测试中设置测试数据

members = MemberBuilder.CreateList(4)
    .TheFirst(1).With(b => b.WithFirstName("Rob"))
    .TheNext(2).With(b => b.WithFirstName("Poya"))
    .TheNext(1).With(b => b.WithFirstName("Matt"))
    .BuildList(); // Note the "build" method sets everything else to
                  // senible default values so a test only need to define 
                  // what it care about, even if for example a member 
                  // MUST have MembershipId  set

但是，创建良好的流利界面非常困难，因此仅当您具有大量“静态”设置时，才值得这样做。流利的界面也不应与“普通”类混为一谈；因此，经常使用构建器模式。

我认为在大多数情况下将一个setter链接在一起不是一个惯例，这是因为在这种情况下，在构造函数中看到options对象或参数更为典型。C＃也具有初始化程序语法。

代替：

DTO dto = new DTO().setFoo("foo").setBar("bar");

一个人可能会这样写道：

（在JS中）

var dto = new DTO({foo: "foo", bar: "bar"});

（在C＃中）

DTO dto = new DTO{Foo = "foo", Bar = "bar"};

（在Java中）

DTO dto = new DTO("foo", "bar");

setFoo并setBar随后不再需要初始化，并且以后可以用于突变。

虽然可链接性在某些情况下很有用，但不要为了减少换行符而将所有内容都塞在一行上，这一点很重要。

例如

dto.setFoo("foo").setBar("fizz").setFizz("bar").setBuzz("buzz");

使得阅读和理解正在发生的事情变得更加困难。重新格式化为：

dto.setFoo("foo")
    .setBar("fizz")
    .setFizz("bar")
    .setBuzz("buzz");

更容易理解，并使第一个版本中的“错误”更加明显。将代码重构为该格式后，就没有真正的优势了：

dto.setFoo("foo");
dto.setBar("bar");
dto.setFizz("fizz");
dto.setBuzz("buzz");

该技术实际上在Builder模式中使用。

x = ObjectBuilder()
        .foo(5)
        .bar(6);

但是，通常避免使用它，因为它不明确。返回值是对象（因此您可以调用其他设置器）还是返回对象是刚分配的值（也是常见模式），这一点并不明显。因此，“最不惊奇原则”建议您不要试图假设用户想要看到一个解决方案，除非它是对象设计的基础。

这更多的是评论，而不是答案，但是我无法发表评论，所以...

只是想提一下，这个问题令我感到惊讶，因为我一点也不觉得这很罕见。实际上，在我的工作环境（Web开发人员）中非常常见。

举例来说，这是Symfony的学说如何：生成：实体命令自动生成所有的 setters，默认情况下。

jQuery 有点以非常相似的方式链接了大多数方法。