セッターに「これ」を返すのは悪い習慣ですか？

Javaのセッターに「これ」を返すようにするのは良いことですか、悪いことですか？

public Employee setName(String name){
   this.name = name;
   return this;
}

このパターンは、次のようにセッターをチェーンできるので便利です。

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

これの代わりに：

Employee e = new Employee();
e.setName("Jack Sparrow");
...and so on...
list.add(e);

...しかし、それは一種の標準的な慣習に反します。セッターが何か便利なことをできるからといって価値があるのではないでしょうか。このパターンがいくつかの場所（JMock、JPAなど）で使用されているのを見てきましたが、一般的ではないようで、このパターンがどこでも使用されている非常に明確に定義されたAPIでのみ使用されます。

更新：

私が説明したことは明らかに有効ですが、私が本当に探しているのは、これが一般的に受け入れられるかどうか、および落とし穴や関連するベストプラクティスがあるかどうかについての考えです。Builderパターンについては知っていますが、私が説明しているものより少し複雑です。JoshBlochが説明しているように、オブジェクトを作成するための静的なBuilderクラスが関連付けられています。

特に問題はないと思いますが、それは単なるスタイルの問題です。次の場合に役立ちます。

• 一度に多くのフィールドを設定する必要があります（構築時を含む）
• コードの作成時に設定する必要があるフィールドがわかっている。
• 設定するフィールドにはさまざまな組み合わせがあります。

この方法の代替案は次のとおりです。

1. 1つのメガコンストラクター（欠点：多くのnullまたはデフォルト値を渡す可能性があり、どの値が何に対応するかを知るのが難しくなります）
2. いくつかのオーバーロードされたコンストラクター（欠点：数が多くなると扱いにくくなる）
3. ファクトリー/静的メソッド（欠点：オーバーロードされたコンストラクターと同じ-数が多いと扱いにくくなる）

一度にいくつかのプロパティのみを設定する場合は、「これ」を返す価値はないと思います。後でステータス/成功インジケータ/メッセージのような何か他のものを返すことにした場合、それは確かに落ちます。

それは悪い習慣ではありません。それはますます一般的な習慣です。ほとんどの言語では、不要な場合は返されたオブジェクトを処理する必要がないため、「通常の」セッターの使用法の構文は変更されませんが、セッターをチェーン化できます。

これは一般にビルダーパターンまたは流暢なインターフェイスと呼ばれます。

これはJava APIでも一般的です。

String s = new StringBuilder().append("testing ").append(1)
  .append(" 2 ").append(3).toString();

要約する：

• これは「滑らかなインターフェース」または「メソッドチェーン」と呼ばれます。
• これは「標準の」Javaではありませんが、最近はもっと見られるようになります（jQueryでうまく機能します）
• これはJavaBean仕様に違反しているため、さまざまなツールやライブラリ、特にJSPビルダーやSpringで機能しなくなります。
• JVMが通常行う最適化を妨げる可能性があります
• コードをクリーンアップすると考える人もいれば、「恐ろしい」と考える人もいます。

言及されていない他のいくつかの点：

• これは、各関数が1つ（そして1つだけ）のことを実行するという原則に違反しています。あなたはこれを信じるかどうかはわかりませんが、Javaではうまくいくと思います。

• IDEはこれらを生成しません（デフォルト）。

• 最後に、これが実際のデータポイントです。このように構築されたライブラリの使用に問題がありました。Hibernateのクエリビルダーは、既存のライブラリでのこの例です。Queryのset *メソッドはクエリを返すため、シグネチャを見てもその使用方法を知ることはできません。例えば：

  Query setWhatever(String what);

• それは曖昧さをもたらします：メソッドが現在のオブジェクト（あなたのパターン）を変更するか、あるいはおそらくQueryは本当に不変（非常に人気があり、価値のあるパターン）であり、メソッドは新しいものを返します。ライブラリを使いにくくするだけで、多くのプログラマーはこの機能を利用しません。セッターがセッターである場合、それを使用する方法はより明確になります。

私はこれに「with」メソッドを使用することを好みます：

public String getFoo() { return foo; }
public void setFoo(String foo) { this.foo = foo; }
public Employee withFoo(String foo) {
  setFoo(foo);
  return this;
}

したがって：

list.add(new Employee().withName("Jack Sparrow")
                       .withId(1)
                       .withFoo("bacon!"));

警告：このwithX構文は一般に不変オブジェクトの「セッター」を提供するために使用されるため、これらのメソッドの呼び出し元は、既存のインスタンスを変更するのではなく、新しいオブジェクトを作成することを合理的に期待する場合があります。多分もっと合理的な言い回しは次のようなものになるでしょう：

list.add(new Employee().chainsetName("Jack Sparrow")
                       .chainsetId(1)
                       .chainsetFoo("bacon!"));

chainsetXyz（）命名規則を使用すると、実質的に誰もが満足するはずです。

'this'セッターから戻りたくないが2番目のオプションを使用したくない場合は、次の構文を使用してプロパティを設定できます。

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

余談ですが、C＃では少しクリーンだと思います。

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

これは、getter / setterの規則を破るだけでなく、Java 8メソッド参照フレームワークも破ります。MyClass::setMyValueはでありBiConsumer<MyClass,MyValue>、myInstance::setMyValueはConsumer<MyValue>です。setter returnがある場合this、それはもはやの有効なインスタンスでConsumer<MyValue>はなく、Function<MyValue,MyClass>であり、それらのsetterへのメソッド参照を使用するものはすべて無効になります（それらがvoidメソッドであると想定）。

私はJavaを知りませんが、C ++でこれを行いました。他の人々は、それが行を非常に長くし、非常に読みにくくすると言っていましたが、私はこのように何度もそれをしました：

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

これはさらに良いです：

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

少なくとも、私は思います。しかし、私に反対票を投じて、希望があれば私をひどいプログラマーと呼んでも構いません。また、Javaでこれを実行することさえ許可されているかどうかはわかりません。

「流暢なインターフェース」と呼ばれるこの計画（しゃれた意図）は、現在非常に人気が高まっています。許容範囲ですが、実際には私のお茶ではありません。

voidを返さないため、有効なJavaBeanプロパティセッターではなくなりました。あなたが視覚的な「Bean Builder」ツールを使用している世界の7人のうちの1人であるか、JSP-bean-setProperty要素を使用している17人のうちの1人である場合、それは問題になるかもしれません。

少なくとも理論的には、呼び出し間で誤った依存関係を設定することにより、JVMの最適化メカニズムに損傷を与える可能性があります。

これは構文上の砂糖であるはずですが、実際には、超インテリジェントJava 43の仮想マシンに副作用を引き起こす可能性があります。

それが私が反対票を投じる理由です、それを使用しないでください。

それは全く悪い習慣ではありません。ただし、JavaBeans Specとの互換性はありません。

そして、それらの標準的なアクセサに依存する多くの仕様があります。

いつでもそれらを共存させることができます。

public class Some {
    public String getValue() { // JavaBeans
        return value;
    }
    public void setValue(final String value) { // JavaBeans
        this.value = value;
    }
    public String value() { // simple
        return getValue();
    }
    public Some value(final String value) { // fluent/chaining
        setValue(value);
        return this;
    }
    private String value;
}

これらを一緒に使用できます。

new Some().value("some").getValue();

ここに不変オブジェクトの別のバージョンがあります。

public class Some {

    public static class Builder {

        public Some build() { return new Some(value); }

        public Builder value(final String value) {
            this.value = value;
            return this;
        }

        private String value;
    }

    private Some(final String value) {
        super();
        this.value = value;
    }

    public String getValue() { return value; }

    public String value() { return getValue();}

    private final String value;
}

今、これを行うことができます。

new Some.Builder().value("value").build().getValue();

アプリケーション全体で同じ規則を使用する場合、問題はないようです。

一方で、アプリケーションの既存の部分が標準の規則を使用している場合は、それに準拠し、より複雑なクラスにビルダーを追加します

public class NutritionalFacts {
    private final int sodium;
    private final int fat;
    private final int carbo;

    public int getSodium(){
        return sodium;
    }

    public int getfat(){
        return fat;
    }

    public int getCarbo(){
        return carbo;
    }

    public static class Builder {
        private int sodium;
        private int fat;
        private int carbo;

        public Builder sodium(int s) {
            this.sodium = s;
            return this;
        }

        public Builder fat(int f) {
            this.fat = f;
            return this;
        }

        public Builder carbo(int c) {
            this.carbo = c;
            return this;
        }

        public NutritionalFacts build() {
            return new NutritionalFacts(this);
        }
    }

    private NutritionalFacts(Builder b) {
        this.sodium = b.sodium;
        this.fat = b.fat;
        this.carbo = b.carbo;
    }
}

Paulo Abrantesは、JavaBeanセッターを流暢にする別の方法を提供します。各JavaBeanの内部ビルダークラスを定義します。値を返すセッターによって混乱するツールを使用している場合は、Pauloのパターンが役立ちます。

私は「これ」のリターンを持つセッターを支持しています。Beanに準拠していなくてもかまいません。「=式/ステートメント」を使用しても問題ない場合は、値を返すセッターで問題ありません。

私は以前このアプローチを好んでいましたが、私はそれに反対しました。

理由：

• 読みやすさ。各setFoo（）を別々の行に置くと、コードが読みやすくなります。通常は、コードを1回書くよりも何度も何度もコードを読みます。
• 副作用：setFoo（）はフィールドfooのみを設定し、それ以外は設定しないでください。これを返すことは余分な「それは何でしたか」です。

私が見たビルダーパターンは、setFoo（foo）.setBar（bar）規約を使用せず、さらにfoo（foo）.bar（bar）を使用しています。おそらくそれらの理由のためでしょう。

それはいつものように好みの問題です。私は「最小の驚き」アプローチが好きです。

この特定のパターンは、メソッドチェーンと呼ばれます。ウィキペディアリンク、これにはさまざまなプログラミング言語でどのように行われるかについてのより多くの説明と例があります。

PS：特定の名前を探していたので、ここに残しておくことを考えました。

ひと目で：「おどろく！」

さらに考えて

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

実際よりもエラーが発生しにくい

Employee anEmployee = new Employee();
anEmployee.setName("xxx");
...
list.add(anEmployee);

とても面白いです。ツールバッグにアイデアを追加しています...

はい、いいアイデアだと思います。

私が何かを追加できるとしたら、この問題はどうですか？

class People
{
    private String name;
    public People setName(String name)
    {
        this.name = name;
        return this;
    }
}

class Friend extends People
{
    private String nickName;
    public Friend setNickName(String nickName)
    {
        this.nickName = nickName;
        return this;
    }
}

これは動作します：

new Friend().setNickName("Bart").setName("Barthelemy");

これはEclipseでは受け入れられません。：

new Friend().setName("Barthelemy").setNickName("Bart");

これは、setName（）がFriendではなくPeopleを返し、PeoplesetNickNameがないためです。

クラスの名前の代わりにSELFクラスを返すセッターをどのように作成できますか？

このようなものは問題ありません（SELFキーワードが存在する場合）。これはとにかく存在しますか？

class People
{
    private String name;
    public SELF setName(String name)
    {
        this.name = name;
        return this;
    }
}

一般的には良い方法ですが、set-type関数でブール型を使用して、操作が正常に完了したかどうかを判断する必要がある場合もあります。これも1つの方法です。一般的に、これが良いとかベッドだとか言うドグマはありません。もちろん、それは状況から来ています。

ステートメントから

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

私は2つのものを見ています

1）意味のないステートメント。2）読みやすさの欠如。

これは読みにくいかもしれません

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

またはこれ

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

これは次の方法よりも読みやすくなっています。

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

私はかなり長い間セッターを作成してきましたが、唯一の実際の問題は、厳密なgetPropertyDescriptorsを使用してBeanリーダー/ライターBeanアクセサーを取得するライブラリにあります。このような場合、Javaの「bean」には期待したような書き手がありません。

たとえば、私は確実にテストしていませんが、json / mapsからJavaオブジェクトを作成するときに、Jacksonがそれらをセッターとして認識しないことに驚かないでしょう。私はこれについて間違っていることを願っています（すぐにテストします）。

実際、私は軽量のSQL中心のORMを開発しており、これを返す認識されたセッターにgetPropertyDescriptorsにいくつかのコードを追加する必要があります。

ずっと前の答えですが、私の2セント...それで結構です。この流暢なインターフェースがもっと頻繁に使われたらいいのに。

「factory」変数を繰り返しても、以下の情報は追加されません。

ProxyFactory factory = new ProxyFactory();
factory.setSuperclass(Foo.class);
factory.setFilter(new MethodFilter() { ...

これはきれいです、私見：

ProxyFactory factory = new ProxyFactory()
.setSuperclass(Properties.class);
.setFilter(new MethodFilter() { ...

もちろん、すでに述べた回答の1つとして、継承やツールなどの一部の状況では、これを正しく行うためにJava APIを微調整する必要があります。

可能であれば、他の言語構造を使用することをお勧めします。たとえば、Kotlinでは、with、apply、またはletを使用します。このアプローチを使用する場合、セッターからインスタンスを返す必要はありません。

このアプローチにより、クライアントコードは次のようになります。

• 戻り値の種類に関係なく
• メンテナンスが簡単
• コンパイラの副作用を回避する

下記は用例です。

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"
}

APIを作成している場合は、「return this」を使用して、一度しか設定されない値を設定します。ユーザーが変更できる他の値がある場合は、代わりに標準のvoidセッターを使用します。

しかし、それは実際には好みの問題であり、私の意見では、セッターのチェーンはかなりクールに見えます。

これがJavaBeans仕様に違反していると主張するすべての投稿者に同意します。これを保持する理由はありますが、このBuilderパターン（ほのめかした）の使用がその場所にあると私は感じています。それがどこでも使用されていない限り、それは受け入れられるべきです。私にとって「それは場所」は、エンドポイントが「build（）」メソッドの呼び出しであるところです。

もちろん、これらすべてを設定する方法は他にもありますが、ここでの利点は、1）多くのパラメーターのパブリックコンストラクターと2）部分的に指定されたオブジェクトを回避できることです。ここでは、ビルダーに必要なものを収集させ、最後にその「build（）」を呼び出します。これにより、部分的に指定されたオブジェクトが構築されないようにすることができます。代替案は「パラメータオブジェクト」ですが、そのIMHOは問題を1レベル戻します。

多くのパラメーターのコンストラクターは、同じタイプの引数が多く渡される可能性が高くなるため、パラメーターに間違った引数を渡すことが容易になるため、嫌いです。オブジェクトが完全に設定される前に使用される可能性があるため、多くのセッターを使用するのは嫌いです。さらに、以前の選択に基づいてデフォルト値を持つという概念は、「build（）」メソッドを使用するほうが適切です。

つまり、適切に使用すれば、良い習慣だと思います。

悪い癖：セッターがゲッターをゲット

メソッドを明示的に宣言することについてはどうですか

setPropertyFromParams(array $hashParamList) { ... }