1. Effective Java 輪読会
2013/12/04
開発部 田中

2. 第4章 クラスとインタフェース
（項目13～17）

3. • 項目13
– クラスとメンバーへのアクセス可能性を最小
限にする

4. カプセル化
• 実装とAPIを明確に分離する
– 小さな独立した機能を組み合わせる
• 並行したモジュールの開発
• デバッグが容易

5. カプセル化の手段
• アクセス制御
– トップレベルのクラス
• APIとしてpublic
• 実装としてパッケージプライベート
– メンバ
• 基本的にインスタンスフィールドはprivate
• publicの可変フィールドを持つクラスはスレッド
セーフではない
• 例外は定数（public static final）

6. • 項目14
– public のクラスでは、public のフィールドでは
なく、アクセッサーメソッドを使う

7. アクセッサー・ミューテーター
• publicのクラスであっても、フィールドを
直接公開すべきではない
– モジュールに対するアクセスはAPIを通じて行
うことで、カプセル化の意味がある
– フィールドに外部からアクセスする必要があ
るなら、APIとしてアクセスを許可する

8. • 項目15
– 可変性を最小限にする

9. 不変クラスの作成ルール
• オブジェクトの状態を変更するメソッド
を提供しない
• サブクラス化を禁止する
• すべてのフィールドをfinalにする
• すべてのフィールドをprivateにする
• 参照型のフィールドをクラスの外からア
クセスできないようにする

10. 不変クラスの作成方法
• 新たなインスタンスを戻り値にする
– 関数的
• staticファクトリーメソッドで既存の不変
インスタンスを共有する

11. 不変クラスのメリット
• スレッドセーフ
– 同期が必要ない

12. サブクラス化防止方法
• クラスをfinalにする
• コンストラクタをprivate（またはパッケー
ジプライベート）にし、オブジェクトの
生成はstaticファクトリーメソッドで行う
– staticファクトリーメソッドとしてのメリット
も有効
• 同じシグネチャでも別の個性を持つオブジェクト
を生成するような場合

13. • 項目16
– 継承よりコンポジションを選ぶ

14. 継承の危険性
• クラスの拡張はスーパークラスの実装に
依存する
– 意図されていない具象クラスの拡張は危険

15. コンポジション・ラッパー
• 転送クラスを通して、目的のメソッドに
アクセする
– 拡張したいクラスをprivateのフィールドに持
ち、メソッドは全てそのフィールドに対して
の呼び出し

16. いつ継承すべきか
• 「is-a」関係

17. • 項目17
– 継承のために設計および文書化する、でなけ
れば継承を禁止する

18. 自己利用（self-use）を文書化
• オーバーライド可能なメソッドの自己利
用を文書化していない場合、オーバーラ
イドによってスーパークラスの振る舞い
を意図せず変更してしまう恐れがある

19. 効率的なサブクラス化のために
• 自己利用については記述する
– 実装の詳細について記述せざるを得ない
– カプセル化を破ることになる
• 可能な限りオーバーライド可能なメソッ
ドを減らす

20. 継承を可能にするためのルール
• コンストラクタはオーバーライド可能な
メソッドを呼び出してはならない
– スーパークラスのコンストラクタから先に実
行されるため、初期化されていないサブクラ
スのフィールドを参照する可能性がある