問題タブ [effective-java]

次のコードは、Effective Java book からのものです。

このコードはコンパイルされませんでした。著者は、次のようにコンパイラに正確な型を伝えることで、この問題を回避することを提案しています。

共用体の署名が次のような場合、以前のプログラムがコンパイルされないのはなぜですか?また、この特定の回避策のイディオムは何と呼ばれていますか?

クローンとコピーコンストラクタに関するこのArtimaの記事から：

オブジェクトのcloneメソッドは非常に注意が必要です。これはフィールドコピーに基づいており、「言語外」です。コンストラクターを呼び出さずにオブジェクトを作成します。コンストラクターによって確立された不変条件を保持するという保証はありません。Sunの内外を問わず、オブジェクトのクローンを作成するまでチェーンの上位でsuper.cloneを繰り返し呼び出すと、オブジェクトの浅いコピーが作成されるという事実に起因して、長年にわたって多くのバグが発生しています。

Joshua Blochは、言語外とはどういう意味ですか？

Joshua Bloch の著書『Effective Java』では、クラスが内部動作へのフックとして「慎重に選択された保護されたメソッド」を提供する方法についての議論があります。
次に、著者は次のドキュメントを引用しますAbstractList.removeRange()。

このメソッドはclear、このリストとそのサブリストに対する操作によって呼び出されます。リスト実装の内部を利用するためにこのメソッドをオーバーライドすると、clearこのリストとそのサブリストに対する操作のパフォーマンスが大幅に向上します。

私の質問は、このメソッドをオーバーライドすると、パフォーマンスがどのように改善されるのでしょうか (単純にオーバーライドしないだけではありません)。誰でもこれの例を挙げることができますか?

JoshuaBlochの著書「EffectiveJava」の第7版では、特にファイルを閉じるためにfinallyステートメントを使用しないようにアドバイスしています。「ファイルを閉じるためにファイナライザーに依存するのは重大なエラーです」。2ページ後、彼は、それが正当である2つのユースケースの1つは、明示的な終了メソッドパターンにあると述べています。

終了メソッドを持つクラスには、FileInputStreamとFileOutputStreamが含まれます。つまり、finallyステートメントでファイルを閉じるということではないでしょうか。

1）Joshua Blochのアイテム7は矛盾していますか？

2）終了方法のパターンは必要ですか？同じ効果を持つfinallyステートメントなしで上記のコードを書くことはできませんか？

私はEffectiveJavaの本を読み、将来の参考のためにメモを作成していましたが、BuilderPatternに出くわしました。

私はそれが何であるか、そしてそれがどのように使用されると想定されているかをよく理解しました。その過程で私はビルダーパターンの2つの例のバリエーションを作成しました。

それぞれの違いと利点をリストアップするのに助けが必要ですか？確かに私は、Example 1公開するメソッドが少なく、制限が少なく、より一般的であることに気づきました。これにより、より柔軟に使用できるようになります。

私が見逃した他のことを指摘してください？

例1

例2

効果的なJavaブックのアイテム番号74には、以下のように言及する段落（アイテム74の最後から2番目の段落）があります。

内部クラス（アイテム22）はSerializableを実装するべきではありません。コンパイラによって生成された合成フィールドを使用して、囲んでいるインスタンスへの参照を格納し、囲んでいるスコープからローカル変数の値を格納します。これらのフィールドがクラス定義にどのように対応するかは、匿名クラスとローカルクラスの名前と同様に指定されていません。 したがって、内部クラスのデフォルトのシリアル化された形式は明確に定義されていません。

内部クラスがコンパイラによって生成された合成フィールドを使用して、囲んでいるインスタンスへの参照を格納することを知っています。たとえば、囲んでいるクラスがMyEnclosingで、内側のクラスがMyInnerの場合、囲んでいる参照はMyEnclosing.thisです。しかし、私はBOLD部分を取得できません。意味を理解するのを手伝ってください。ありがとう！！！

『Effective Java, 2nd Edition, Item 11』では、次のディープ コピーの例を見つけることができます。

これがどのようにディープ コピーを作成するのか理解できません。キーと値はオブジェクトであるため、プリミティブ型はありません。だから私の理解では、

Entry元のキーと値への参照を使用して新しいを作成しEntryますか?

ディープ コピーとは基本的に、プリミティブ型に到達するまで下に移動し、それらをクローンにコピーすることを意味するのではないでしょうか?

これに関するヒントをありがとう！

ほとんどの人がこれについて知っているように、double check idiom for lazy initialization of instance field. しかし、誰かが FieldType のシングルトン オブジェクトをどのように作成するのか、私はばかげた疑問を抱いています。関数（シングルトンインスタンスを作成する）を呼び出すにgetField()は、クラスのインスタンスが必要ですが、今まではインスタンスがありませんでした。ちょっと困っています、教えてください。ありがとう！！！

だから私はいくつかのEffective Javaを読んでいます！この本の中で最も刺激的なセクションの 1 つは、Bloch が "Builder" (単なる POJO ではなくクラス) について書いている Immutable Object/Builder セクションです。

注: ここではモデル オブジェクトについて話しています。たとえば、ArticleやCarなどです。

これは、以前にこれらのオブジェクトを書いた方法です。

ご覧のとおり、この設計には多くの点で欠陥があり、可変性が必要であり、最初にコンストラクターを使用してオブジェクトを構築し、次に名前を設定する必要があります。

もちろん、nameフィールドを final にして、コンストラクターの引数として使用することもできますが、たとえば多数の SQL テーブルをラップする大きなオブジェクトがある場合は、次のような醜いコンストラクターが作成されます。

これは、オブジェクトを作成するときに読み取れなくなります。これはたった 6 つのフィールドです!

したがって、ブロッホは次のことを提案しています（不変性を伴う）

これで不変性が得られます。また、プリミティブまたは不変ではないオブジェクトがある場合は、それらをBuilderのセッターにコピーし、Carのゲッターに再度コピーします。

しかし、それは非常に冗長で、クラスが十分に小さい場合はコンストラクター引数を使用してきました。クラスに可変フィールドが必要な場合、クラスに十分なプロパティ (> 4 何か) がある場合は、そのフィールドを可変にします。

もう 1 つの問題は、Android を使用していて、クラスにたとえばBitmap.

このような質問をたくさん見てきましたが、この質問に対する適切な答えを見つけることができないようです。これらの設計に標準はありますか?また、その設計はどのようになっていますか? メリット/デメリットは？

前もって感謝します！

編集：

質問は：

不変である必要があり、A) 少数のフィールドと B) 多数のフィールドを持つオブジェクト モデルを構築する最良の方法は何ですか? Bitmap上記の問題および同様の問題を処理するにはどうすればよいですか? 特定のフィールドを変更可能にしますか?

曖昧でごめんなさい。

Joshua Bloch は、彼の著書 ( Effective Java - 2nd Ed ) の項目 4で言及しています。

クラスを拡張する代わりに、静的フィールドと静的メソッドのみを含むクラス (ユーティリティ クラス) を使用して、最終クラスのメソッドをグループ化できます。

この文を説明できる人はいますか？