セッターのチェインが型破りなのはなぜですか？

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（）はスタックの最上位要素への参照を返すクエリです。古典的には、この2つを組み合わせたいと思いますが、それを行うことはできず、例外に対して安全です。（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には、セッターの戻り値の型をvoidに指定するJavaBeans仕様があります。つまり、セッターのチェーンと競合しています。この仕様は広く受け入れられ、さまざまなツールに実装されています。

もちろん、なぜ仕様の一部を連鎖させないのかと尋ねるかもしれません。答えはわかりませんが、このパターンは当時知られていないか、人気がなかったかもしれません。

他の人々が言っ​​たように、これはしばしば流interfaceなインターフェースと呼ばれます。

通常、セッターは、アプリケーションのロジックコードに応じて変数を渡す呼び出しです。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（Object Mothers）を使用して、単体テストでテストデータを設定する

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

しかし、優れた流fluentなインターフェイスを作成するのは非常に難しいので、多くの「静的な」セットアップがある場合にのみ価値があります。また、流なインターフェイスを「通常の」クラスと混在させないでください。したがって、ビルダーパターンがよく使用されます。

セッターを次々とチェーンするのが慣例ではない理由の多くは、コンストラクターでオプションオブジェクトまたはパラメーターを表示するのがより一般的だからだと思います。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、初期化に必要なくなり、後で突然変異に使用できます。

連鎖性は状況によっては便利ですが、改行文字を減らすためだけにすべてを1行に詰め込まないようにすることが重要です。

例えば

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);

ただし、一般的にはあいまいであるため回避されます。戻り値がオブジェクトであるか（他のセッターを呼び出すことができるか）、または戻りオブジェクトが割り当てられたばかりの値であるか（これも共通のパターンであるか）は明らかではありません。したがって、Least Surpriseの原則では、オブジェクトのデザインの基本でない限り、ユーザーが1つのソリューションまたは他のソリューションを見たいと思い込まないでください。

これは答えというよりはコメントですが、コメントすることはできませんので...

ちょうど私がこのように表示されていないので、この質問は、私を驚かせたことを言及したかった珍しいすべてで。実際、私の作業環境（Web開発者）では非常に一般的です。

エンティティは自動-生成するコマンド：生成します。例えば、これはどのようにsymfonyの教義であるすべて setters、デフォルトで。

jQueryのは、ちょっとチェーン非常によく似た方法で、そのメソッドのほとんどを。