java - javaのBooleanのようなWrapperクラスが不変なのはなぜですか?

Question

Boolean ラッパー クラスが不変になった理由がわかりません。

Boolean Wrapper が実際にリセットできる Commons lang の MutableBoolean のように実装されなかった理由。

誰かがこれについて何か考え/理解を持っていますか? ありがとう。

Answer 1

は 2 です。明日2ではありません3。

特にマルチスレッドの状況では、イミュータブルがデフォルトとして常に優先され、読みやすく保守しやすいコードになります。Date適切な例:設計上の欠陥だらけの Java API。不変であればDate、API は非常に合理化されます。Date操作によって新しい日付が作成され、それらを変更する API を探す必要がないことはわかっています。

Concurrency in Practiceを読んで、不変型の真の重要性を理解してください。

ただし、何らかの理由で変更可能な型が必要な場合はAtomicInteger AtomicBoolean、などを使用することにも注意してくださいAtomic。可変性を導入することで、スレッドセーフの必要性が導入されたためです。型が不変のままだった場合、これは必要ありませんでした。そのため、可変型を使用する場合は、スレッドセーフについて考え、concurrentパッケージの型を使用するという代償も払わなければなりません。並行プログラミングのすばらしい世界へようこそ。

また、 for Boolean- Boolean が変更可能かどうかを気にする、実行したい操作を 1 つ挙げてください。true に設定しますか? を使用しmyBool = trueます。それは再割り当てであり、突然変異ではありません。否定？ myBool = !myBool. 同じルール。不変性は制約ではなく機能であることに注意してください。したがって、それを提供できる場合は提供する必要があります。これらの場合、もちろん提供できます。

これは他のタイプにも適用されることに注意してください。整数で最も微妙なことは ですが、値をアトミックに取得することに関心がない限りcount++、それは単なるcount = count + 1です...その場合は可変を使用しAtomicIntegerます。

Answer 2

Java のラッパー クラスは不変であるため、ランタイムは 2 つの Boolean オブジェクト (1 つは true、もう 1 つは false) のみを持つことができ、すべての変数はこれら 2 つのいずれかへの参照です。そして、それらは決して変えることができないので、あなたの下から引き出されることは決してないことを知っています. これによりメモリが節約されるだけでなく、コードの推論が容易になります。受け渡しているラッパー クラスの値が決して変更されないことがわかっているため、突然新しい値にジャンプすることはありません。他の場所で同じ値を参照します。

同様に、Integer にはすべての符号付きバイト値 (-128 から 127) のキャッシュがあるため、ランタイムはこれらの共通の Integer 値の追加のインスタンスを持つ必要はありません。

Answer 3

パタシュが一番近い。Java のばかげた設計上の選択の多くは、VM の実装方法の制限によるものでした。当初、彼らは C または C++ 用の VM を作成しようとしたと思いますが、難しすぎた (不可能?) ため、この別の類似言語を作成しました。1つ書いて、どこでも実行してください！他の男の噴出のようなコンピューター科学の正当化は、事後的なフォルダーです。ご存じのとおり、Java と C# は C と同じくらい強力になるように進化しています。確かに、それらはよりクリーンでした。数十年後に設計された言語用であるべきです! 簡単なトリックは、「ホルダー」クラスを作成することです。または、最近はクロージャーを使用してください！Java が JavaScript に進化しているのかもしれません。笑。