Effective java 輪読会 第3章 項目8,9,10
•Download as PPTX, PDF•
4 likes•1,385 views
3章 項目8,9,10
Recommended
More Related Content
More from Appresso Engineering Team
More from Appresso Engineering Team (20)
Effective java 輪読会 第3章 項目8,9,10
- 1. Effective Java 輪読会 第2回 （項目8～10） 2013/12/04 開発部 野口
- 4. equalsをオーバーライドしないのが 正しいとき(1/2) • クラスの個々のインスタンスは、本質的 に一意である – 例）Threadクラス • 「論理的等価性」検査を、クラスが提供 するかどうかに関心がない – 例）java.util.Randomクラス
- 5. equalsをオーバーライドしないのが 正しいとき(2/2) • スーパークラスがすでにequalsをオーバー ライドしており、スーパークラスの振る 舞いがこのクラスに対して適切である – 例）AbstractSetとほとんどのSet、AbstractList とList、AbstractMapとMap • クラスがprivateあるいはパッケージプライ ベートであり、そのequalsメソッドが決し て呼び出されないことが確かである – その場合、呼び出されないことをアサートす べき
- 6. equalsをオーバーライドするのが 適切なとき • クラスが論理的等価性という概念を持っ ている • スーパークラスが（そのクラスが必要と する振る舞いを実装するために）equalsを オーバーライドしていない • 一般に、値クラスの場合 – 例）Integer、Date
- 10. 対称性 • 簡単に破ってしまうことがある！ – pp.35- StringとCaseInsensitiveStringの例
- 11. 推移性 • これも簡単に破ってしまうことがある！ – pp.36- PointとColorPointの例 ★インスタンス化可能なクラスを拡張して、 equals契約を守ったまま値要素を追加する方法は ない →じゃあどうするの？
- 12. 推移性を保つ • instanceofのかわりにgetClassを用いる？ – LSP違反！（pp.38- CounterPointの例） • 継承ではなくコンポジションを用いる – 解決（pp.39- ColorPointの例） – See also: 項目16 継承よりコンポジションを選 びなさい ★リスコフの置換原則（Liscov Substitution Principle: LSP） 「派生型はその基本型と交換可能でなければならな
- 13. 注意 • java.sql.Timestampは対称性を守っていない （悪い）例！ – ドキュメントに注意書きもあるが、誤用して もコンパイルエラーにはならない • デバッグが困難になる • 抽象クラスの継承においては、これらの 問題は起こらない – See also: 項目20 タグ付クラスよりクラス階層 を選ぶ
- 15. 非null性 • nullとの比較でNullPointerExceptionをス ローしない • かわりにfalseを返す • 明示的なnullチェックは不要で、instanceof で十分
- 16. まとめ： 高品質なequalsのための処方箋 • 自分自身かどうかを検査するために、ま ず==を用いる • 引数の型の正しさを検査するために、 instanceofを用いる • 引数を正しい型にキャストする • 「意味のある」フィールドについて、一 致を検査する • 対称性、推移性、整合性をテストする
- 17. 補足説明 • equalsをオーバーライドするときは、常に hashCodeをオーバーライドする（項目9） • あまりにも賢くなろうとしない – 例）Fileクラスは、同じファイルを参照してい るシンボリックリンクを等しいとは見なさな い • equals宣言中のObjectを他の型で置き換え ない – この問題を防ぐため、@Overrideを用いよう
- 19. hashCodeメソッドの一般契約 • アプリケーション実行中、equalsについて 変化していないオブジェクトのhashCode は常に同じ整数を返す • equalsについて等しい2つのオブジェクト のhashCodeは同じ整数を返す • equalsについて等しくない2つのオブジェ クトのhashCodeが別々の整数を返す必要 はない – ただし、ハッシュテーブルのパフォーマンス に影響しうる
- 20. hashCodeをオーバーライドするの を 忘れた場合 • 「等しいオブジェクトは、同じハッシュ コードを持つ」という契約が破られる • equalsで等しくても、別のオブジェクトな ので、デフォルトのhashCodeは別々の値 を返す – 例）pp.45- PhoneNumberクラス
- 21. hashCodeの実装 • （正当だが）最悪な実装 @Override public int hashCode() { return 42; } • 良い実装の簡単な処方箋 – pp.47を参照 ★Eclipseには、項目8～9の指針に概ね沿ったequalsと hashCodeの自動生成機能があるようです - http://hysa.hateblo.jp/entry/20101108/1289223367
- 22. hashCodeの実装（補足） （1/2） • 主にハッシュキーとして使用されるよう なオブジェクトであれば、ハッシュコー ドのキャッシュを検討する – インスタンス生成時 – 遅延初期化 • 「パフォーマンス向上のため」として、 意味のあるフィールドを計算から除外し てはいけない – 失敗例）Javaのリリース1.2より古いString
- 26. toStringメソッドの実装 • 実用的な場合には、オブジェクトに含ま れる興味がある情報をすべて返す • すべて返すのが実用的でない場合、要約 を返す – それ自身で意味が自明であるのが理想 • ○ Manhattan white pages (1487536 listings) • △ Thread[main,5,main]
- 27. toStringメソッドのドキュメンテー ション（1/3） • 形式を明示する – ○ 標準的で曖昧さがなく、可読性があるオブ ジェクトの表現形式を提供できる – ○ Stringを引数とするファクトリメソッド／コ ンストラクタを提供できる – ✕ 形式を変更できなくなる
- 28. toStringメソッドのドキュメンテー ション（2/3） • 形式を明示しない – ○ 形式を変更できる – △ 形式を明示する場合のメリット（○）は得 られない