15

私が働いている会社には、Java で従うべきグッド プラクティスを説明したドキュメントがあります。thisそのうちの 1 つは、次のようにを返すメソッドを避けることです。

class Properties {

  public Properties add(String k, String v) {
   //store (k,v) somewhere
     return this;
  }

}

私はそのようなクラスを持っているので、私は書くことができます:

 properties.add("name", "john").add("role","swd"). ...

私はそのようなイディオムを何度も見てきましStringBuilderた。

彼らの議論は次のとおりです。

...同期の問題や、ターゲット オブジェクトの状態に関する期待の失敗の原因となる可能性があります。

これが当てはまる状況は考えられません。誰か例を挙げていただけますか?

編集ドキュメントは可変性について何も指定していないため、呼び出しの連鎖と実行の違いはわかりません。

properties.add("name", "john");
properties.add("role", "swd");

発案者と連絡を取ろうとしますが、銃を装填したままやりたかったので、質問を投稿しました.

解決済み: 作成者の 1 人と話をすることができました。彼の当初の意図は、Builder パターンのように、まだ準備ができていないオブジェクトを解放することを避けることだったようで、呼び出し間でコンテキストの切り替えが発生した場合、オブジェクトは無効な状態。thisメソッドを 1 つずつ呼び出すと同じ間違いを犯す可能性があり、ビルド プロセスを適切に同期させることと関係があるため、これは復帰とは関係ないと主張しました。彼は、文書がより明確になる可能性があることを認め、すぐに改訂する予定です。勝利は私の/私たちのものです！

4

4 に答える 4

5

プラクティスの唯一の重大な基礎は、変更可能なオブジェクトを避けることです。それが「混乱」であり、「期待の失敗」につながるという批判は非常に弱い. 最初にそのセマンティクスに慣れるまでオブジェクトを使用しないでください。また、Javadoc を読むことをオプトアウトする人に対応するためだけに API に制約を課すことは、まったく良い方法ではありませんthis。流暢な API 設計は、Java の標準的なアプローチの 1 つであり、非常に歓迎されるものです。

于 2013-04-17T12:56:41.960 に答える
1

たとえば、「ビルダー」パターンでは、このアプローチが非常に役立つ場合があると思います。

私の組織では、この種のことはソナーのルールによって制御されていると言えますが、そのようなルールはありません。

別の推測では、プロジェクトが既存のコードベースの上に構築された可能性があり、これは一種の従来の制限です。

したがって、私がここで提案できる唯一のことは、このドキュメントを書いた人々と話すことです :)

お役に立てれば

于 2013-04-17T12:56:22.140 に答える
0

状況によっては、そのパターンを使用してもまったく問題ないと思います。

たとえば、Swing 開発者として、私は GridBagLayout をその長所と柔軟性のためにかなり頻繁に使用しますが、これを使用したことがある人なら誰でも (GridBagConstraints の犯罪のパートナーである)、それが非常に冗長で読みにくいことを知っています。

私がオンラインで見た (そして私が使用している) 一般的な回避策は、異なるプロパティごとにセッターを持つ GridBagConstraints (GBConstraints) をサブクラス化し、各セッターがこれを返すことです。これにより、開発者は必要に応じてさまざまなプロパティを連鎖させることができます。

結果として得られるコードは、サイズが約 1/4 になり、GridBagConstaints の使用に慣れていない一般的な開発者にとっても、はるかに読みやすく、保守しやすくなります。

于 2013-04-17T14:42:20.533 に答える