Effective Java 輪読会

2013/12/04開発部 田中

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

• 項目 13– クラスとメンバーへのアクセス可能性を最小

限にする

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

カプセル化の手段• アクセス制御– トップレベルのクラス• API として public• 実装としてパッケージプライベート

– メンバ• 基本的にインスタンスフィールドは private• public の可変フィールドを持つクラスはスレッド

セーフではない• 例外は定数（ public static final ）

• 項目 14– public のクラスでは、 public のフィールドで

はなく、アクセッサーメソッドを使う

アクセッサー・ミューテーター• public のクラスであっても、フィールドを

直接公開すべきではない– モジュールに対するアクセスは API を通じて

行うことで、カプセル化の意味がある– フィールドに外部からアクセスする必要があ

るなら、 API としてアクセスを許可する

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

不変クラスの作成ルール• オブジェクトの状態を変更するメソッド

を提供しない• サブクラス化を禁止する• すべてのフィールドを final にする• すべてのフィールドを private にする• 参照型のフィールドをクラスの外からアク

セスできないようにする

不変クラスの作成方法• 新たなインスタンスを戻り値にする– 関数的

• static ファクトリーメソッドで既存の不変インスタンスを共有する

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

サブクラス化防止方法• クラスを final にする• コンストラクタを private （またはパッ

ケージプライベート）にし、オブジェクトの生成は static ファクトリーメソッドで行う– static ファクトリーメソッドとしてのメリット

も有効• 同じシグネチャでも別の個性を持つオブジェクト

を生成するような場合

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

継承の危険性• クラスの拡張はスーパークラスの実装に

依存する– 意図されていない具象クラスの拡張は危険

コンポジション・ラッパー• 転送クラスを通して、目的のメソッドにア

クセする– 拡張したいクラスを private のフィールドに持

ち、メソッドは全てそのフィールドに対しての呼び出し

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

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

れば継承を禁止する

自己利用（ self-use ）を文書化• オーバーライド可能なメソッドの自己利

用を文書化していない場合、オーバーライドによってスーパークラスの振る舞いを意図せず変更してしまう恐れがある

効率的なサブクラス化のために• 自己利用については記述する– 実装の詳細について記述せざるを得ない– カプセル化を破ることになる

• 可能な限りオーバーライド可能なメソッドを減らす

継承を可能にするためのルール• コンストラクタはオーバーライド可能なメ

ソッドを呼び出してはならない– スーパークラスのコンストラクタから先に実

行されるため、初期化されていないサブクラスのフィールドを参照する可能性がある