問題タブ [effective-java]

有効な Javaから(項目 1 :コンストラクターの代わりに静的ファクトリ メソッドを検討する):

静的ファクトリ メソッドによって返されるオブジェクトのクラスは、メソッドを含むクラスが作成された時点で存在する必要さえありません。このような柔軟な静的ファクトリ メソッドは、Java Database Connectivity API (JDBC) などのサービス プロバイダー フレームワークの基礎を形成します。サービス プロバイダー フレームワークは、複数のサービス プロバイダーがサービスを実装するシステムであり、システムはクライアントが実装を利用できるようにし、クライアントを実装から切り離します。

メソッドを含むクラスが書かれた時点で、静的ファクトリメソッドによって返されるオブジェクトのクラスは存在する必要さえないという本がなぜ言っているのか、私は特に理解していません。例としてJDBCを使用して説明できますか。

有効な Java の項目 1 では、静的ファクトリ メソッドにより、コレクション フレームワークが以前よりもはるかに小さくなったと述べられています。誰かがその方法を説明してもらえますか? 静的ファクトリメソッドを使用しているという理由だけで、次のことがどのように可能になるのか理解できませんか? つまり、これらの個別の実装をまだ実装する必要がありますね。

コレクション フレームワーク API は、便利な実装ごとに 1 つずつ、32 の個別のパブリック クラスをエクスポートした場合よりもはるかに小さくなっています。

これは、ITEM 40 の一部を理解するための試みです。Effective Java 2nd Edition から慎重にメソッド シグネチャを設計します。

メソッド シグネチャの読みやすさを改善するために提案されていることの 1 つは、4 つ以下のパラメーターを目指すことです。より長いパラメーター リストは、次のようなさまざまな手法を使用して管理することをお勧めします。

最初の 2 つの側面を組み合わせた 3 つ目の手法は、Builder パターン (項目 2) をオブジェクト構築からメソッド呼び出しに適応させることです。多くのパラメーターを持つメソッドがある場合、特にその一部がオプションの場合、すべてのパラメーターを表すオブジェクトを定義し、クライアントがこのオブジェクトに対して複数の「セッター」呼び出しを行うことができるようにすると、有益な場合があります。単一のパラメーターまたは関連する小さなグループを設定します。目的のパラメータが設定されると、クライアントはオブジェクトの「execute」メソッドを呼び出します。これにより、パラメータの最終的な有効性チェックが行われ、実際の計算が実行されます。

オブジェクトの構築に使用される Builder パターンには精通していますが、それをメソッド呼び出しに適応させる方法を正しく理解しているかどうかはわかりません。

ここに私がこれまでに持っているものがあります:(
メソッドのメソッド呼び出しを改善しようとしましたmove)

Joshua Bloch のアドバイスに対する私の解釈は正しいですか?

「EffectiveJava、Second Edition」の項目71では、インスタンスフィールドを遅延インスタンス化するために、ダブルチェックイディオムとシングルチェックイディオムが導入されています。

イディオムを再確認する

シングルチェックイディオム

ダブルチェックのイディオムであるJoshuaは、結果変数を使用して、揮発性フィールドが1回だけ読み取られるようにし、パフォーマンスを向上させると述べています。これは理解できますが、とにかくフィールドを1回しか読み取らないため、シングルチェックイディオムでなぜそれが必要なのかわかりません。

Builderパターンを使用してJoshuaBlochのスタイルでクラスを作成したいと思います。しかし、このクラスをDTOオブジェクトとして使用し、EJBから転送したいと思います。したがって、パブリックの引数なしコンストラクターが必要です。ビルダーパターンでこのJavaBeanスタイルを実現するにはどうすればよいですか？Builder効果的なJavaオブジェクトには、オブジェクトを引数として受け入れるコンストラクターが1つだけあります。そこにpublicno-argコンストラクターを追加すると、Java-beanパターンよりもビルダーの利点が失われます。

これはEffective Java 2からそのままです。アイテム2のこのステートメントが何を意味するのかわかりません

Builder パターンは柔軟です。単一のビルダーを使用して、複数のオブジェクトを構築できます。ビルダーのパラメーターは、オブジェクトを作成するたびに微調整して、オブジェクトを変えることができます。

これを行う例を思いつくことができません。例でこれを理解するのを手伝ってください。

Java のオブジェクトのコンパイル時型と実行時型の違いは何ですか? 私はEffective Java bookを読んでいます.Joshua Blochは、主にキャスト警告を抑制することが安全な場合があることを説明するために、アイテム26の配列インスタンスのコンパイル時の型と実行時の型について何度も言及しています。

ここで著者は、これらのさまざまなタイプtypesの配列について話しています。compile time typesしかし、この質問を通じて、 vs run time typesfor any type of objectの違いを理解したいと思います。

このコードは、本Effective Javaからのものです

私は主にここのコメントに興味があります。それはリストを作りますunmodifiableか？リストが内部的にロックされているとはどういう意味ですか? このロックはどのくらい保持されますか? List を array に変換するより良い方法はありますか?

効果的なJavaアイテム26から ジェネリック型を優先

他のすべての条件が同じであれば、スカラー型よりも配列型へのチェックされていないキャストを抑制する方がリスクが高く、2番目の解決策が提案されます。ただし、Stackよりも現実的なジェネリッククラスでは、コード内の多くのポイントで配列から読み取る可能性があるため、2番目のソリューションを選択するには、E []への単一のキャストではなく、Eへの多数のキャストが必要になります。最初のソリューションがより一般的に使用されます[Naftalin07、6.7]。

著者はここで何を意味し、scalar type彼はここで何を伝えようとしているのですか？オプション2よりも危険と見なされるオプション1は何ですか？

コード ：

VS

有効な Javaジェネリックの章UnaryFunctionで定義されているインターフェイスを考えてみましょう。

を返すための次のコードUnaryFunction

のキャストが安全なのはなぜIDENTITY_FUNCTIONですか(UnaryFunction<T>)?

この本は、私が尋ねている質問についてこれを述べていますが、ここで論理に従うことはできません。applyID 操作を行う関数はどこで呼び出しているのでしょうか。何も変更せずに渡された同じオブジェクトを返すのはその関数であるため、私は混乱しています。

IDENTITY_FUNCTION のキャストは、 for everyではない ため(UnaryFunction<T>)、チェックされていないキャスト警告を生成します。しかし恒等関数は特別です: 引数を変更せずに返すので、 の値が何であれ、それを として使用しても型安全であることがわかっています。したがって、このキャストによって生成されるチェックされていないキャストの警告を自信を持って抑制することができます。これが完了すると、コードはエラーや警告なしでコンパイルされます。UnaryFunction<Object>UnaryFunction<T>TUnaryFunction<T>T