継承って、どうやって使うの？

# 継承って難しい？

オブジェクト指向言語でプログラミングしていると、何がと出くわす「継承」という言葉。継承の概念は勉強はしたことがあるという人は多いとは思いますが、実際のソースコード上でどう生かしていけばよいかわかりずらいものです。
しっかりと継承の機能を使えれば、オブジェクト指向のメリットを享受できるものですが、どの場面でどう実装していけばよいか、自分の中に落とし込むのにはなかなか難しい、、、

そのような人のために、私のつたない知識ではありますが、ちょっとでも「継承」について理解の橋渡しができれば、と思っています。

# まずは定義から

よくある定義はこちら

[By wikipedia](https://ja.wikipedia.org/wiki/%E7%B6%99%E6%89%BF_(%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0))

> 継承（けいしょう、英: inheritance、インヘリタンス）とはオブジェクト指向を構成する概念の一つである。あるオブジェクトが他のオブジェクトの特性を引き継ぐ場合、両者の間に「継承関係」があると言われる。
>
> 主にクラスベースのオブジェクト指向言語で、既存クラスの機能、構造を共有する新たなクラス（派生クラス、派生型）を定義すること（subclassing、サブクラス化）ができる。またそのような派生クラスは「親クラス（スーパークラス）を継承した」という。具体的には変数定義（フィールド）や操作（メソッド）などが引き継がれる。またJavaやC#などのインタフェース実装のように、機能セットの仕様（プロトコル）のみを引き継ぐ場合もある。
>
> 一般的に、BがAを継承する場合、"B is a A."（BはAの一種である）という意味的な関係（Is-a関係）が成り立つ。従って、同じふるまいを持つからと言って、意味的に無関係なクラス間に継承関係を持たせるのは適切でない場合が多い。

「継承関係」にあるクラス、「Is-a関係」にあるクラスというのは、よく聞く話。確かに、フィールドやメソッドを継承できるのだから、同じ処理を書かずに処理を利用することはできそうですね。
処理が一か所にまとまっているのだから、共通の処理に何か変更があった場合には、そこを修正するだけで済むというメリットも生まれます。うん、何かに役立ちそうだ。

あと、よく出てくるのが、下の図。

![よくある継承関係の図](http://www.plantuml.com/plantuml/svg/SoWkIImgAStDuKhEIImkLdZQFVLvvqg5QYu587YvUFxZnfsFcxerDC7yPsjNFcxi1t9geQgVTwrHg8PpUbQ3E5nG8sngT7L12f3v83LS3gbvAK0B0G00 "よくある継承関係の図")

犬も猫も動物なので、どちらも食べるし歩く。ということを表現している図になります。確かに、「動物」クラスに`食べる()`、`歩く()`というメソッドがあるので、犬クラスを呼んでも、猫クラスを呼んでも、どちらでも2つのメソッドを使うことができます。

、、、、

それでは、ここまでの知識で実装してみましょう！
となったとき、コードに落とし込めるでしょうか？なかなか難しいですよね。ここがオブジェクト指向の難しいところだとつくづく感じます。

そう、概念だけを理解しても、わからないものなのですねぇ、、
どういうときにこの考え方が有効なのかを知って、体験して、試行錯誤することで身につくものなのかなとも思います。

# 継承を使うといい場面

さて、継承を使うタイミングはどういうときでしょうか？それは、共通処理があり、それらを一か所にまとめておきたい場合です。

「それってさっき言っていましたよね？」

そうです。もう一度言いました。
継承を使う理由はこれに限ると思うのです。でも、単に処理をまとめたいというよりは、**一連の似たようなの処理の流れがあるが、一部分に個別の処理が挟まれている場合に効果を発揮します。**
たとえば、次のような図の時です。

![共通処理と個別処理が混ざっているパターン図](http://www.plantuml.com/plantuml/svg/SoWkIImgAStDuIe0qfd9cGM9UIKAZvidFcxQ_xXvp-FcpOuA-KKfgKKAXZXLE45L675n5UNbbwGgv9S1UIXcwA1fi59ushhnPSEif-tBdazeCyIfJq6vEBioAQSq5QIZeVjfnrA83YDTGovz1OGkDEELqujIK_CgKtDoyiinT1gHwKfZabrfGhOhJSXsfIcNGsfU2Z120G00 "共通処理と個別処理が混ざっているパターン図")

`パターンA`という処理のほかに、`パターンB`という処理の流れが非常によく似たパターンがあるとします。大まかには同じなのですが、2番目と4番目の処理をパターン別に違った処理をさせたいのです。

# 継承を使わなくても書けませんか？

普段業務ロジックを書かれている読者の方々にはこのような場面に出くわしたことがあるのが多いのではないでしょうか。この図の処理を、単純に実装しようとすると次のようになるかと思います。

```java:継承を使わない実装方法
public class NoInheritance {
    public void executePattern(Pattern pattern) {
        System.out.println("共通処理1");

        if (pattern == Pattern.PATTERN_A) {
            System.out.println("個別処理2-1");
        } else if (pattern == Pattern.PATTERN_B) {
            System.out.println("個別処理2-2");
        }

        System.out.println("共通処理3");

        if (pattern == Pattern.PATTERN_A) {
            System.out.println("個別処理4-1");
        } else if (pattern == Pattern.PATTERN_B) {
            System.out.println("個別処理4-2");
        }

        System.out.println("共通処理5");
    }
}

enum Pattern {
    PATTERN_A, PATTERN_B
}
```

処理も1つのクラスにまとまっていて頭の考えていることを簡潔に言い表しているのではないのでしょうか。確かに、
`new NoInheritance().executePattern(Pattern.PATTERN_A);`
と実行すれば

> 共通処理1
個別処理2-1
共通処理3
個別処理4-1
共通処理5

となり、
`new NoInheritance().executePattern(Pattern.PATTERN_B);`
と実行すれば

> 共通処理1
個別処理2-2
共通処理3
個別処理4-2
共通処理5

ということが確認できます。期待通りの処理ができていますね。
このくらいのコード量からすれば、見通しやすいですし、見る場所も一か所で済んでいますので問題がないようにも感じます。
しかし実際には、共通処理や個別処理が十数行・数十行にわたってしまうことがほどんどです。**そうなると途端に見通しがわくるなるのが必至です。**

「処理が多いのであれば、共通処理として別メソッドに書き出せばよいのではないですか？」

そう聞こえてきそうです。よくある手法としては、共通ユーティリティクラスを作り、処理を委嘱します。

```java:共通ユーティリティクラスを使用
public class UseUtil {
    public void executePattern(Pattern pattern) {
        CommonUtil.commonProcess1();

        if (pattern == Pattern.PATTERN_A) {
            System.out.println("個別処理2-1");
        } else if (pattern == Pattern.PATTERN_B) {
            System.out.println("個別処理2-2");
        }

        CommonUtil.commonProcess3();

        if (pattern == Pattern.PATTERN_A) {
            System.out.println("個別処理4-1");
        } else if (pattern == Pattern.PATTERN_B) {
            System.out.println("個別処理4-2");
        }

        CommonUtil.commonProcess5();
    }
}

class CommonUtil {
    public static void commonProcess1() {
        System.out.println("共通処理1");
    }
    public static void commonProcess3() {
        System.out.println("共通処理3");
    }
    public static void commonProcess5() {
        System.out.println("共通処理5");
    }
}

enum Pattern {
    PATTERN_A, PATTERN_B
}
```

`CommonUtil`クラスを作成することによって、処理をうまく共通化できたようにも思えます。もし、共通処理の中身が増えたとしても、`executePattern()`メソッドの中身は増えません。
しかし、この書き方にも問題点があります。

* オブジェクト指向の考え方に、「共通ユーティリティ」クラスを作るということはなじまない
    * このままですと、`CommonUtil`クラスは`UseUtil`クラス以外にも呼び出せてしまうので、スコープが大きくなり、もしほかのクラスから`CommonUtil`クラスのメソッドを呼び出すようなことがあれば、途端にメンテナンス性が低くなります。（簡単に修正できなくなる）
* `UseUtil`クラスに対する`CommonUtil`クラスの依存性が高くなっている
    * 「CommonUtil」と書いておきながら、`UseUtil`クラス専用の処理をしているので、一つ一つのメソッドを見たときに汎用性があまりない。
    * （確かに、`CommonUtil`クラスをパッケージプライベートにしたり、それぞれのメソッドを`UseUtil`クラスに移してprivate化すればある程度スコープが小さくなりいい実装には近づきます。）

----
さらに、次のような問題も発生します。例えば、さらに似たような`パターンC`という処理が加わったとします。

![パターンCが付け加わります](http://www.plantuml.com/plantuml/svg/SoWkIImgAStDuIe0qfd9cGM9UIKAZvidFcxQ_xXvp-FcpOuA-KKfgKKAXZXLE45L6E5KuGnNmLMKbr-Igf2ON9HVNAnWfV2qTUFBXbbFsvSzdz1c29NCBqijGdE2Sd5sPL9EQIf8HqFtquwb41r6kePS-WeuT3afAASNfQRcLQRcvEINO-WqmgtJMK4v9pCzewGWCoyRGvynFYyOa-m54xAzO4Ac5qpmUy6Koo4rBmMO8W00 "パターンCが付け加わります")

よし、同様に追加すればよいのだなということで、下記のような実装にしました。

```java:パターンCを追加しようとしました
public class AddPatternC {
    public void executePattern(Pattern pattern) {
        System.out.println("共通処理1");

        if (pattern == Pattern.PATTERN_A) {
            System.out.println("個別処理2-1");
        } else if (pattern == Pattern.PATTERN_B) {
            System.out.println("個別処理2-2");
        } else if (pattern == Pattern.PATTERN_C) {
            System.out.println("個別処理2-3");
        }

        System.out.println("共通処理3");

        if (pattern == Pattern.PATTERN_A) {
            System.out.println("個別処理4-1");
        } else if (pattern == Pattern.PATTERN_B) {
            System.out.println("個別処理4-2");
        }
        // あれ、Pattern.PATTERN_Cは？？

        System.out.println("共通処理5");
    }
}

enum Pattern {
    PATTERN_A, PATTERN_B, PATTERN_C
}
```

ためしに、`new AddPatternC().executePattern(Pattern.PATTERN_C);`を実行してみると、

> 共通処理1
個別処理2-3
共通処理3
共通処理5

となります。
、、、
何か気づきませんか？そうです、**バグが発生しています。**
図からすれば、「共通処理3」と「共通処理5」の間に「個別処理4-3」表示されてほしいところですが、いざ実行してみると表示されていませんでした。このようなことになってしまったのはなぜなのでしょうか？

「ああ、一つif文を書き忘れたのね」

そのように片付けるのも簡単です。しかし、このような分岐処理が複数ありしかも数百行・数千行のコードである場合、すべてに気づいて対処しきれるでしょうか？コードを書くのも人間ですし、テストをするのも人間です。しかも開発する際には大人数で行うことがほとんどなので、必ずこのような実装ミスは発生します。
実装のミスに気付かず、本番環境にリリースしてしまった場合、お客様に指摘されてはじめて気づく、データがおかしくなり復旧に時間がかかってしまう、など余計な工数もかかることになりプロジェクトにも大きな影響をもたらす可能性があります。

# 実装のミスを防ぐための手法としての「継承」

このような実装のミスを防ぐためにはどうしたらよいでしょうか？**その一つの答えが「継承を使う」なのです。**

「でも、継承って親クラスのメソッド・フィールドが使えたり、メソッドをオーバライドして処理を変更したりすることができることだと思います。どうして実装ミスを防ぐことができるのでしょうか？」

そうですね、そう疑問に思われるのもわからなくありません。通常オブジェクト指向の継承を習う際には、継承によって得られる「機能」を教えられるのだと感じます。そのため、継承の考え方をいったん変えましょう！

それでは、お待たせしました。実装方法について紹介します。

## 方法1：処理の流れを親クラスに書く

Javaには、`abstract`というキーワードがあります。classをabstractにすると、そのクラスだけではインスタン生成することができず、必ずextendsする必要が出てきます。これを利用して書くと次のようになります。

```java:継承を使った方法
abstract class UseInheritance {
    public void executePattern() {
        System.out.println("共通処理1");

        this.individualProcess2();

        System.out.println("共通処理3");

        this.individualProcess4();

        System.out.println("共通処理5");
    }

    abstract void individualProcess2();
    abstract void individualProcess4();
}

class PatternA extends UseInheritance {
    @Override
    void individualProcess2() {
        System.out.println("個別処理2-1");
    }

    @Override
    void individualProcess4() {
        System.out.println("個別処理4-1");
    }
}

class PatternB extends UseInheritance {
    @Override
    void individualProcess2() {
        System.out.println("個別処理2-2");
    }

    @Override
    void individualProcess4() {
        System.out.println("個別処理4-2");
    }
}
```

実行の仕方は、
`new PatternA().executePattern();`
`new PatternB().executePattern();`
となります。（実行結果は同じなので割愛）

ちなみに、クラス図を描くと以下のようになります。

![継承を使った場合のクラス図](http://www.plantuml.com/plantuml/svg/SoWkIImgAStDuKfCAYufIamkKKZEIImkLWWjJlNCoqWjoYn9p4jELQZcKW02ROMo_CmKXTIArEJIajI0n9AIrA8y3KsmN5qrp8HQYAhCl9JCiioKqiISWAByvDJYOYEYLPe0LTPoGHm2jSKHweGwGeOJRwGJLOpaGWifcnfTNRYZyKawSJcavgK0Wnu0 "継承を使った場合のクラス図")

継承を使わない場合と見比べてみてください。どのような変化があるでしょうか？

* 個別処理が親クラスに一切かかれていない
* パターンごとにクラスになっている
* enumがなくなっている
* オーバライドを利用して個別処理を実現している

などなど、いろいろな発見があるかと思います。
実は、このような実装方法は、GoFのデザインパターンの「Template Methodパターン」と呼ばれるものです。気になる方は調べてみてください。

https://qiita.com/i-tanaka730/items/dbeb82ac44c031fe8df9

このような実装にするメリットは何でしょうか？それは、パターンを増やしたときに気づくことでしょう。同様に`PatternC`を作ってみます。

```java:パターンを増やしました

class PatternC extends UseInheritance {
    @Override
    void individualProcess2() {
        System.out.println("個別処理2-3");
    }
}
```

ただし、コンパイルしようとした時、エラーが発生してしまいました。

```
エラー: PatternCはabstractでなく、UseInheritance内のabstractメソッドindividualProcess4()をオーバーライドしません
class PatternC extends UseInheritance {
^
```

エラーの内容を見ると、`individualProcess4()`が抽象メソッドなのに、オーバライドしてないのでしなさいと言っています。
お分かりの通り、**この時点で実装ミスに気づくことができるのです。**
`abstract`キーワードを使うことで、個別に実装する範囲を明示していることで、パターンを書き足す人が（abstractクラスを実装した人とは違うかもしれません）何をしなくてはならないかが明確になります。

さらに、次のような特徴に気づきませんでしょうか。

* if文が取り除かれているので、バグが発生しにくくなっている
* 親クラスを見ることによって、大まかな処理の流れが把握しやすい
* 子クラスを見ることによって、パターンごとの処理・違いが把握しやすい

このような特徴というのは、開発者目線からするととてもメリットが高いと思います。
このようにして、バグの発生を減らし、効率的に開発を進めていきしょう。

## 方法2：インターフェイスを使用して、違いを吸収する

上記で示した、「Template Methodパターン」以外にも、実装方法があります。それは、`interface`というキーワードです。

```java:インターフェイスを使用した方法
class UseInterface {
    public void executePattern(Pattern pattern) {
        System.out.println("共通処理1");

        pattern.individualProcess2();

        System.out.println("共通処理3");

        pattern.individualProcess4();

        System.out.println("共通処理5");
    }
}

interface Pattern {
    void individualProcess2();
    void individualProcess4();
}

class PatternA implements Pattern {
    @Override
    public void individualProcess2() {
        System.out.println("個別処理2-1");
    }

    @Override
    public void individualProcess4() {
        System.out.println("個別処理4-1");
    }
}

class PatternB implements Pattern {
    @Override
    public void individualProcess2() {
        System.out.println("個別処理2-2");
    }

    @Override
    public void individualProcess4() {
        System.out.println("個別処理4-2");
    }
}
```

実行の仕方は、
`new UseInterface().executePattern(new PatternA());`
`new UseInterface().executePattern(new PatternB());`
となります。（実行結果は同じなので割愛）

クラス図を描くと以下のようになります。

![継承を使った場合のクラス図](http://www.plantuml.com/plantuml/svg/SoWkIImgAStDuKhEIImkLWWjJlNCAqajIajCJbMevb800cs5ilpC58NKYjJaqfBKWCGIe7IU1fHMA83GcborN9bmZL19L0Coyr8oop9JIXDp0ehoarEBYuqqDF7Acm3bQo7kWfdeI7qZdQXY91VCopOrUdfmrs8LTU922MGzFJjuU5afb1QdSZcavgK0OmG0 "継承を使った場合のクラス図")

これは、GoFのデザインパターンの「Stateパターン」と呼ばれるものです。
先ほどの「Template Methodパターン」との違いとしては、

* 個別処理を実装するメソッドの定義が、親クラスではなくインターフェイスになっている
* 処理の流れが書いてある`executePattern()`メソッドを実行するためには、個別処理の書かれた処理を引数に入れる格好となっている

となっています。この2つの実装方法には、優劣をつけるものではないとは思っていますが、こちらの実装方法は、**`UseInterface`クラスと`PatternA`・`PatternB`クラスとの間に依存性がなくなっている**という特徴があります。
依存性が低いことは、それぞれのクラスが変更しやすくなるということになるので、よりいい実装になっているということも言えるのではないでしょうか？

# さいごに

いかがだったでしょうか？「継承」を使うメリットを感じられましたでしょうか？ほう、「まだ実際に業務内で書いたことがないからわからないなぁ」。そうですよね、数をこなさないと上達していきません。これは長い道のりになりそうだ、、、

自身でコードを書くときに、「これは、継承を使った方が見通しが良いな」と気づくようになるためには、とにかくわからないなりにも使ってみるのも一つの手だと思います。
だって、バグが出るのは自分にとっても周りにとっても嫌ですもの、どんどん取り入れていきましょう。