Garden

最近の記事

is-a関係以外の継承の例

8 min read

Prompt

“is-a関係”以外の関係の継承(あんまりよくないのかな？)の例ってなんだ？

なるほどね！「is-a関係」以外の「継承」（そしてそれが「あんまりよくない」とされている理由）の例だね。INFPの君が、オブジェクト指向設計の奥深い部分、特に「どういう関係性が適切か」という哲学的な問いを深掘りしているのが伝わってくるよ。これはプログラミングの設計原則を理解する上で、めちゃくちゃ重要なポイントだ！

「is-a関係」というのは、オブジェクト指向における継承（Inheritance） の最も基本的な原則だよね。「AはBの一種である」という関係が成り立つ場合に継承を使う、というものだ。例えば、「犬 (Dog) は動物 (Animal) の一種である」という関係だね。

じゃあ、それ以外の、つまり**「is-a関係ではないのに継承を使ってしまう、あまり推奨されない関係性」** の例を見ていこうか！ これは通称「継承の乱用」とか「継承のアンチパターン」って言われることもあるんだ。

「is-a関係」以外の継承の例（望ましくない継承） 👎

「is-a関係」以外の代表的な継承のパターンは、主に**「has-a関係」（所有関係）や「uses-a関係」（利用関係）**を誤って継承で表現してしまうケースだよ。これらは通常、**コンポジション（Composition）**で表現すべき関係性なんだ。

1. 「has-a関係」を継承で表現する

  • 定義: 「AはBを持っている（AがBを構成要素として含む）」という関係。

  • 適切な表現: コンポジション（AがBのインスタンスをフィールドとして持つ）

  • 誤った継承の例: 「車 (Car) はエンジン (Engine) の一種である」

    Java

    // 悪い例: 「車はエンジンである」というのは間違い
class Engine {
    void start() { System.out.println("Engine starts."); }
}

class Car extends Engine { // Car is-a Engine? --> No! Car has-a Engine.
    void drive() {
        start(); // エンジンのメソッドを直接使える
        System.out.println("Car drives.");
    }
}

// 適切な例: コンポジション
class ProperEngine {
    void start() { System.out.println("Proper Engine starts."); }
}

class ProperCar {
    private ProperEngine engine; // Car has-a ProperEngine

    public ProperCar(ProperEngine engine) {
        this.engine = engine;
    }

    void drive() {
        engine.start(); // エンジンのメソッドを呼び出す
        System.out.println("Proper Car drives.");
    }
}

    • なぜ悪いのか？

      • 不自然な階層: 現実世界で「車はエンジンそのもの」ではないよね。車はエンジンを「持つ」ものだ。継承を使うと、概念的なモデルが壊れてしまう。

      • 機能の不適切公開: CarクラスがEngineの全ての公開メソッドを継承してしまう。CarのユーザーはCarを介してEngineのstart()を直接呼べるようになるけど、これはCarの設計として適切でない場合が多い。Carがエンジンをどのように利用するかはCarの内部実装の詳細であるべきで、外部に直接さらすべきではない。

      • 柔軟性の欠如: Carは特定のEngineクラスに強く結合されてしまい、別の種類のエンジンに簡単に交換できない（例: ElectricEngineに替えにくい）。コンポジションなら、ProperEngineをインターフェースにして、さまざまなProperEngineの実装をProperCarに渡せるため、柔軟性が高い。

2. 「uses-a関係」を継承で表現する

  • 定義: 「AはBを利用する」という関係。

  • 適切な表現: デリゲーション（移譲）や依存性注入 (Dependency Injection)

  • 誤った継承の例: 「ロガー (Logger) を使うためだけに、特定のクラスがロガーを継承する」

    Java

    // 悪い例: 「ユーザーサービスはロガーである」というのは間違い
class Logger {
    void log(String message) { System.out.println("LOG: " + message); }
}

class UserService extends Logger { // UserService is-a Logger? --> No! UserService uses-a Logger.
    void createUser(String name) {
        log("Creating user: " + name); // ロガーのメソッドを直接使える
        // ... ユーザー作成ロジック
    }
}

// 適切な例: デリゲーション（コンポジションの一種）
interface ILogger { // インターフェースで抽象化
    void log(String message);
}

class ConsoleLogger implements ILogger {
    @Override
    public void log(String message) { System.out.println("CONSOLE LOG: " + message); }
}

class ProperUserService {
    private ILogger logger; // UserService uses-a ILogger

    public ProperUserService(ILogger logger) { // DI (依存性注入)
        this.logger = logger;
    }

    void createUser(String name) {
        logger.log("Creating user: " + name); // ロガーのメソッドを呼び出す
        // ... ユーザー作成ロジック
    }
}

    • なぜ悪いのか？

      • 不適切な関係性: UserServiceはLoggerそのものではなく、ログ機能「を使う」だけだ。継承は、基底クラスの全ての特性と振る舞いを子クラスが持つことを意味するが、UserServiceがLoggerの全ての特性を持つのは不自然。

      • 単一責任の原則違反: UserServiceはユーザー管理の責任に加え、Loggerの責任まで引き継いでしまう。これは「単一責任の原則」に反し、クラスの肥大化や役割の曖昧化を招く。

      • 柔軟性の欠如: 別のロガー（例: ファイルロガー、データベースロガー）に切り替えたい場合、UserServiceの継承関係を変更する必要があり、コードの変更が大きくなる。コンポジション（DI）なら、ProperUserServiceはILoggerインターフェースに依存するだけで、具体的なロガーの実装は外部から注入できるため、柔軟性が高い。

まとめ：「継承よりコンポジション」の原則 💡

これらの例が示すのは、オブジェクト指向設計における非常に重要な原則である**「継承よりもコンポジションを優先せよ (Prefer composition over inheritance)」** だよ。

  • 継承（Inheritance）: 「is-a関係」の場合にのみ使うべき。強い結合を生むため、慎重に。

  • コンポジション（Composition）: 「has-a関係」や「uses-a関係」の場合に使うべき。他のオブジェクトのインスタンスをフィールドとして持ち、そのオブジェクトの機能を利用する。これにより、疎結合で柔軟なシステムが構築できる。

INFPの君が、コードの設計に潜む関係性の複雑さを哲学的に考えるのは、まるで社会の複雑な人間関係を分析するようだね。この違いを理解し、適切に使い分けることが、堅牢で、拡張しやすく、メンテナンスしやすい「美しいコード」を書くための鍵になるよ！

グラフビュー

最近の記事

グラフビュー