タグ付けされた質問 「mutable」

不変の型、特にコレクションを使用する主な利点として、スレッドセーフが常に/しばしば言及されているようです。 メソッドが文字列の辞書（C＃では不変）を変更しないようにしたい状況があります。できるだけ物事を制約したいと思います。 ただし、新しいパッケージ（Microsoft Immutable Collections）に依存関係を追加する価値があるかどうかはわかりません。パフォーマンスも大きな問題ではありません。 したがって、私の質問は、ハードパフォーマンス要件がなく、スレッドセーフの問題がない場合に、不変コレクションを強く推奨するかどうかだと思いますか？値のセマンティクス（私の例のように）も要件である場合とそうでない場合があることを考慮してください。

53 immutability  semantics  collections  mutable 

モノのストリームがあり、それらを途中で「強化」したい場合peek()、これを行うために使用できます。たとえば： streamOfThings.peek(this::thingMutator).forEach(this::someConsumer); コードのこの時点でthingMutatorモノを変更することは正しい動作であると仮定します。たとえば、メソッドは「lastProcessed」フィールドを現在の時間に設定できます。 ただし、peek()ほとんどのコンテキストでは、「見て、触れないでください」という意味です。 ストリーム要素の突然変異にアンチパターンを使用peek()していますか？ 編集： より一般的な代替アプローチは、消費者を変換することです。 private void thingMutator(Thing thing) { thing.setLastProcessed(System.currentTimeMillis()); } パラメータを返す関数に： private Thing thingMutator(Thing thing) { thing.setLastProcessed(currentTimeMillis()); return thing; } map()代わりに使用します： stream.map(this::thingMutator)... しかし、それは機能的なコード（return）を導入しpeek()、同じオブジェクトを返すことを知っているので、それがより明確であるとは確信していませんがmap()、同じクラスのオブジェクトであることは一目でさえわかりません。 さらに、peek()あなたは突然変異するラムダを持つことができmap()ますが、列車の残骸を構築する必要があります。比較する： stream.peek(t -> t.setLastProcessed(currentTimeMillis())).forEach(...) stream.map(t -> {t.setLastProcessed(currentTimeMillis()); return t;}).forEach(...) 私は思うpeek()ので、何の「神秘的」副作用はありません、バージョンが明確で、かつラムダは明らかに変異されます。同様に、メソッド参照が使用され、メソッドの名前が明らかに突然変異を暗示している場合、それも明確で明白です。 個人的には、peek()突然変異に使うことをためらわない-非常に便利だと思う。

37 java  anti-patterns  java8  stream-processing  mutable