4-19:継承のために設計および文書化する、でなければ継承を禁止する
要点
継承は強力だが脆い。サブクラスがスーパークラスの実装の内部仕様に依存すると、スーパークラスの変更でサブクラスが壊れる。公開 API が増え、保守や互換性のコストが跳ね上がる。だから「拡張を公的にサポートする」か「完全に禁止する」か、どちらかにすべき。
悪い例
public class Parent {
public Parent() {
init(); // 危険：オーバーライド可能なメソッドをコンストラクタで呼ぶ
}
public void init() { /* 初期化 */ }
}
public class Child extends Parent {
private final Resource r = new Resource();
@Override
public void init() {
r.doSomething(); // r はまだ初期化されていない可能性がある -> NPE
}
}
問題点
- スーパークラスのコンストラクタがオーバーライド可能なメソッドを呼んでいる
→ サブクラスのフィールドが未初期化の状態で呼ばれる危険。 - スーパークラスがどのメソッドを「安全に」オーバーライドできるか文書化していない
→ サブクラス実装が壊れる。
良い例
設計どおりに拡張ポイント（hooks）を提供し、仕様を文書化する例：
/**
* ドキュメントに「サブクラスはこの hook を実装してよい。ただしコンストラクタではなく
* onInit() が呼ばれるタイミングで安全に使える」と明記する。
*/
public abstract class Framework {
public final void start() {
// 固定の初期化手順
initCore();
// hook を呼ぶ（安全なタイミング）
onInit();
}
private void initCore() { /* 基本初期化 */ }
/**
* 拡張ポイント: サブクラスはここを実装できる。
* implSpec: onInit は start() の中で呼ばれ、すでに基盤が初期化済みであることを保証する。
*/
protected abstract void onInit();
}
ポイント
- start() は final にして処理順を固定（サブクラスが勝手に手順を壊せない）。
- 拡張ポイント onInit() は protected にし、いつ呼ばれるか／どの条件下で安全かを Javadoc（@implSpec など）で明記する。
- サブクラスはドキュメントに従えば安全に拡張できる。
継承を禁止する／制限する方法
ライブラリ作成者は継承を禁止したいことが多い。
やり方：
1. finalクラスにする(一番簡単)
public final class Utility { ... }
2. コンストラクタをprivateにして静的ファクトリを用意(派生禁止 + インスタンス制御)
public class Foo {
private Foo() { }
public static Foo of(...) { return new Foo(...); }
}
3. パッケージプライベート（default）にして外部から継承不能にする
class InternalHelper { ... } // same package only
4. Java17+のsealedクラスで制御(明示的に許可されたサブクラスのみ)
public sealed class Base permits AllowedSub1, AllowedSub2 { ... }
5. ドキュメントで「継承はサポートしない」旨を明記し、可能ならコンパイル時に final を使う（宣言的に禁止）。
継承を「設計して文書化」する際の必須項目
ライブラリで継承を許すなら、最低でも次を文書化しておくこと：
- いつ/どの順序でサブクラスのメソッドが呼ばれるか（コンストラクタ後か、初期化完了後か等）。
- どのメソッドが拡張ポイント（override して良い）か（そしてその契約）。
- サブクラスで守るべき不変条件。
- スレッド安全性の契約（呼び出しはシングルスレッドか？マルチスレッドで呼ばれるか？）。
- 例外処理の方針（サブクラスが例外を投げてよいか、投げる場合どう扱うか）。
- super のメソッドは必ず呼べるか／呼ぶべきか（呼ぶ順序やタイミング）。
- 将来の互換性についての注意（どの部分は安定 API で、どれは将来変更される可能性があるか）。
まとめ
継承を許すなら設計と契約を明確にして文書化し、そうでなければ継承を禁止してユーザーに不確定な拡張をさせないこと。
これにより将来の保守性・互換性・安全性が格段に向上する。