問題タブ [effective-java]

おそらくBlochのEffective Javaのセクションを読んだことを覚えていますが、ほとんどの場合、

文字列は不変であるため、ほとんどの場合 a == b です。ただし、オブジェクトの一時的な構築などにより、 new String("fish") は個別のオブジェクト参照を生成します。

equals()、不変性、およびオブジェクト作成に関する Bloch の章を調べましたが、覚えているこのビットが見つかりません!! 髪をかきむしっていますが、これがなぜなのか説明がどこにあるか覚えている人はいますか? EJにもないかもしれませんが、見つけたいです。ヒント: これが説明されている場所は、私の実際の質問です。

私はEffectiveJavaを読んでいます。関数オブジェクトを戦略として使用することについて説明しているセクションには、以下の段落があります。

戦略インターフェースは、そのすべての具体的な戦略インスタンスのタイプとして機能するため、具体的な戦略をエクスポートするために具体的な戦略クラスを公開する必要はありません。代わりに、「ホストクラス」は、タイプが戦略インターフェイスであるパブリック静的フィールド（または静的ファクトリメソッド）をエクスポートでき、具象戦略クラスは、ホストのプライベートネストクラスにすることができます。

私の質問は、上記の方法を使用することの特別な利点はありますか？具体的な戦略を公開して戦略をエクスポートすることの問題点は何ですか？

効果的なJavaで記述された優れたhashCode（）を作成するためのガイドラインでは、フィールドが長い場合、作成者は次の手順について言及しています。

フィールドが長い場合は、（int）（f ^（f >>> 32））を計算します。

なぜこれが行われるのかわかりません。なぜこれを行うのですか？

有効な Java (Joshua Bloch) Item 17 は次のように述べています。

「デザインとドキュメントまたは継承またはそれ以外の禁止」

ただし、Android API をざっと見てみると、ほとんどの API クラスが非最終的なものであることがわかります。継承についても文書化されていれば問題ありません (たとえば、Viewof )。Activityただし、いくつかの非最終クラスもありますが、ドキュメントではこれらのクラスの継承については言及されていません。私の要点を説明するためのいくつかの任意の例：

• システム サービスを表すクラス ( WifiManager、NotificationManager...)
• のようなユーティリティ クラスUriMatcher。
• のようないくつかのハードウェア固有のクラスCamera。

オープン性と拡張性は Android の哲学ですが、ここでは慣例が逆転していますか? つまり、すべての Android API クラスが (明示的に文書化されているかどうかにかかわらず) 継承されるように設計されていると想定できます。最終宣言されない限り？

私はEffective Javaを読んでいますが、本にはcloneメソッドに関する以下のコメントがあります。

実際には、Cloneable を実装するクラスは、適切に機能する public clone メソッドを提供することが期待されます。一般に、クラスのすべてのスーパークラスが、パブリックかプロテクトかにかかわらず、正常に動作するクローン実装を提供しない限り、これを行うことはできません。

これができない理由の例を誰か挙げることができますか?

Joshua Bloch による「Effective Java Second Edition」を読んでいて、同時実行性に関する以下のステートメントに混乱しています -

「言語仕様では、変数が long または double 型でない限り、変数の読み取りまたは書き込みがアトミックであることを保証しています [JLS、14.4.7]。つまり、long または double 以外の変数の読み取りは、次の値を返すことが保証されています。複数のスレッドが同期せずに同時に変数を変更したとしても、何らかのスレッドによってその変数に格納されました。」

これは、誰かが手元に本を持っている場合に備えて、259 ページの最後の段落に記載されています。

複数のスレッドが変数を変更している場合でも、参照される変数は常に値を持つとは限りませんか?

私はJoshua Blochによる『Effective Java 』を読んでいますが、これまでのところ、その評判に本当に応えています。最初の項目は、コンストラクターに対する静的ファクトリ メソッドの説得力のあるケースです。古き良きコンストラクタの有効性に疑問を持ち始めたほどです:)。

本のメリット・デメリットをまとめると以下のようになります。

利点:

1. 彼らには名前があります！
2. 完全なインスタンス コントロール (シングルトン、パフォーマンスなど) があります。
3. サブタイプ/インターフェースを返すことができます
4. コンパイラは型推論を提供できます

短所:

1. プライベート クラスはサブクラス化できません
2. コンストラクターのようにドキュメントで目立たない

最初の欠点は、実際には良いことです(本で言及されているように)。2 つ目は、マイナーな欠点であり、今後の Java リリース (javadoc の注釈など) で簡単に解決できると思います。

最終的に、ファクトリ メソッドにはコンストラクターのほとんどすべての利点があり、さらに多くの利点があり、実際の欠点はないようです。

したがって、私の質問は基本的に 3 つの部分に分かれています。

1. コンストラクターよりもデフォルトで常に静的ファクトリ メソッドを使用することをお勧めしますか?
2. コンストラクターを使用することは正当化されますか?
3. オブジェクト指向言語がファクトリに言語レベルのサポートを提供しないのはなぜですか?

注:同様の質問が 2 つあります。コンストラクタを使用する場合と、getInstance() メソッド (静的ファクトリ メソッド) を使用する場合です。オブジェクトの作成: コンストラクターまたは静的ファクトリーメソッド。ただし、答えは上記のリストを提供するか、私がすでに知っている静的ファクトリメソッドの背後にある理論的根拠を繰り返します。

からダブル チェック ロックについて読んでいEffective Javaます。コードは次のことを行います。

を使用する必要はないresultように見えますが、実際には、field既に初期化されている一般的なケースで一度だけ読み取られることが保証されます。

しかし、私はこれを理解していません。if(field == null)直接行うこととの違いは何ですか？if (result == null)述べたように優れていることは言うまでもなく、 なぜ異なるのかわかりません。

Java におけるチェック済み例外と非チェック済み例外の相対的なメリットについては十分に議論されている ことを認識しており、議論全体を再検討するつもりはありません。

むしろ、Joshua Bloch の『Effective Java, 2nd Edition』を読んでいたときに頭に浮かんだ、非常に具体的な質問をしたいと思います。読んでいると、項目 59 (「チェック済み例外の不必要な使用を避ける」) で、Joshua がチェック済み例外が使用されている Java API の例を示していることに気付きました。具体的には、次のObjectとおりです。

...そして、代わりに未チェックの例外であるべきだったと主張します。

API を使用するプログラマーがこれ以上うまくいかない場合は、未チェックの例外の方が適切です。このテストに失敗する例外の一例は、CloneNotSupportedException です。Object.clone によってスローされます。これは、Cloneable (項目 11) を実装するオブジェクトでのみ呼び出す必要があります。実際には、ほとんどの場合、catch ブロックにはアサーションの失敗の特徴があります。例外のチェックされた性質は、プログラマーにとって何のメリットもありませんが、労力を必要とし、プログラムを複雑にします。

次に、彼が逆の例を持っているかどうかを調べましたが、見つけることができませんでした.

そこで、チェックされていない例外を使用するJavaのAPIの例を誰かが提供できるかどうかを尋ねたいと思いますが、チェックされた例外の方が良い選択であり、その理由を説明してください。現実世界の例が望ましいですが、それが問題を説明するのであれば、不自然な例でも構いません。

編集: これを非建設的なものとして締めくくることに投票した人たちに、私は意見、討論、議論、または拡張された議論を求めていないことを明確にしたいと思います. また、投票も行っていません。むしろ、メリットがコストを上回ることを明確に分析できる例への参照を探しています。（それは、コストがあることを認めていることを暗に示しています。）とはいえ、この質問の性質がそれを可能にするかどうかについては、私は懐疑的です。ジョン・スキートができないなら、できる可能性は低いと思います。だから多分あなたは正しいです。必要に応じて閉じます。

編集:私は反応に動揺していませんが、私の受け入れ率のためだけにジョンにこれを与えるつもりです.

項目 9 のサンプル コードは次のとおりです。

ページ 48 には次のように記載されています。

2 による乗算がビット シフトと同等であるという概念を理解しています。また、大きな数に大きな奇数の素数を掛けると、依然としてオーバーフローが発生する (したがって情報が失われる) こともわかっています。私が得られないのは、大きな奇数素数による乗算から生じる情報損失が、大きな偶数による乗算から生じる情報損失よりも好ましい理由です。