値オブジェクトにメソッドチェーンパターンを使用することは許容可能/適切な方法ですか(これの代わりに新しいオブジェクトを返すなど)?このソリューションが実装されているケースはありますか?
欠点は考えられませんが、ご意見をお聞かせください。
値オブジェクトにメソッドチェーンパターンを使用することは許容可能/適切な方法ですか(これの代わりに新しいオブジェクトを返すなど)?このソリューションが実装されているケースはありますか?
欠点は考えられませんが、ご意見をお聞かせください。
結論: この方法は完全に受け入れられます。
これは、不変オブジェクトがある場合に一般的に発生することだと思います。元のオブジェクトを変更する代わりに、指定された値で新しいオブジェクトを作成して返します。メソッドチェーンでこれを行うことの賛否両論は、可変オブジェクトと不変オブジェクトを使用する場合とほぼ同じです。
私が持っている唯一の懸念は、これがクラスの呼び出し元に明確にされることです-彼らはチェーンされたオブジェクトとの同一性に依存することはできず、呼び出しが元のオブジェクトを変更していないことを明確にする必要があります. ただし、実際に呼び出しを連鎖させていたとしても、中間オブジェクトを割り当てていないため、このリスクはあまりありません。重要なのは、メソッド チェーンの最後のオブジェクトのみを使用することです。
例として java.lang.String を使用するには、これを行う String のクライアント:
myString.trim().replace("a", "b").substring(3, 9);
... は何も意味せず、一般的にプログラマーの誤解を示しています。彼らがすべきことはこれです:
String myNewString = myString.trim().replace("a", "b").substring(3, 9);
...そしてmyNewString
、その後の操作で使用します。興味深いことに、Java の静的解析ツールである Findbugs は、この誤解のインスタンスを検出し、バグの可能性があるとして報告できます。
クライアントの理解が主なケースです。その他の欠点としては、値オブジェクトの作成に非常にコストがかかる場合、各チェーンで新しい値オブジェクトを作成するとパフォーマンスが低下します。これが問題になる可能性があるかどうかは、独自のシナリオから判断できるはずです。この場合、メソッド チェーンごとに新しいオブジェクトを作成するのではなく、ビルダー パターンを実装することをお勧めします。
それらを除けば、他の問題は考えられません。
多くの Java クラスは不変の値オブジェクトを提供します。java.lang.String、java.math.BigInteger、および java.math.BigDecimal は不変の値オブジェクトであり、それらのメソッドは新しいオブジェクトを返します。それの最大の欠点は、新しい人がそれが不変であることを理解せず、オリジナルを変更していると思うことです。
一部の言語は、他の言語よりも不変性を強調しています。Ruby では文字列は変更可能であり、コレクションは多くの場合、コピーを返すバージョンと、既存のコピーを変更する別のバージョンを提供します (たとえば、Array#sort と Array#sort!)。Clojure では不変性が標準です。