【SOLID】リスコフの置換原則を完全に理解したい

# SOLIDの原則とは？

SOLIDは

- 変更に強い
- 理解しやすい

などのソフトウェアを作ることを目的とした原則です。
次の5つの原則があります。

- Single Responsibility Principle (単一責任の原則)
- Open-Closed Principle (オープン・クローズドの原則)
- Liskov Substitution Principle (リスコフの置換原則)
- Interface Segregation Principle (インタフェース分離の原則)
- Dependency Inversion Principle (依存関係逆転の原則)

上記5つの原則の頭文字をとって**SOLID**の原則と言います。
今回の記事では **Liskov Substitution Principle (リスコフの置換原則)** について解説します。

その他の原則に関しては下記参照。

- [Single Responsibility Principle (単一責任の原則)](https://qiita.com/k2491p/items/af380369b7060a2f8ac5)
- [Open-Closed Principle (オープン・クローズドの原則)](https://qiita.com/k2491p/items/db69dd2dc43a5a678b4f)
- [Liskov Substitution Principle (リスコフの置換原則)](https://qiita.com/k2491p/items/d442344a462d3a574acc)
- [Interface Segregation Principle (インターフェース分離の原則)](https://qiita.com/k2491p/items/7b4e56789964ac6328b3)
- [Dependency Inversion Principle (依存関係逆転の原則)](https://qiita.com/k2491p/items/686ee5dd72b4baf9a81a)


# 簡単に言うと...

「**あるクラスを継承するとき、継承元と継承先のクラスの振る舞いを同じにしよう**」ということです。
あるいは「**あるクラスを複数のクラスに継承するとき、継承先のクラスの振る舞いを同じにしよう**」と表現することもできます。

簡単な具体例を出しますと、

- 継承元クラスAと継承先クラスB1, B2が存在する
- 以下のようにインスタンスを生成するとき、
  - `A hoge = new B1();`
  - `A hoge = new B2();`
- hogeのメソッドを呼ぶときに同じような振る舞いをする

ということです。

では、**同じような振る舞い**とは一体何を指しているのでしょうか。
もう少し詳しく見ていきましょう。

# リスコフの置換原則の定義

「アジャイルソフトウェア開発の奥義」という書籍では、

> S型のオブジェクトo1の各々に、対応するT型のオブジェクトo2が1つ存在し、Tを使って定義されたプログラムPに対してo2の代わりにo1を使ってもPの振る舞いが変わらない場合、SはTの派生型であると言える。

と書かれています。難しくてよくわからないですね。
Wikipediaはもう少し平易に表現していますが、

>**リスコフの置換原則**（りすこふのちかんげんそく、[英](https://ja.wikipedia.org/wiki/英語): Liskov substitution principle）は、[オブジェクト指向プログラミング](https://ja.wikipedia.org/wiki/オブジェクト指向プログラミング)において、[サブタイプ](https://ja.wikipedia.org/wiki/サブタイピング_(計算機科学))のオブジェクトはスーパータイプのオブジェクトの仕様に従わなければならない、という原則である。

これでもまだ難しいですね。
また、同じくWikipediaにて、リスコフの置換原則を満たすために、下記の項目の守る必要があるとされています。

> 1. 事前条件（preconditions）を、派生型で強めることはできない。派生型では同じか弱められる。
> 2. 事後条件（postconditions）を、派生型で弱めることはできない。派生型では同じか強められる。
> 3. 不変条件（invaritants）は、派生型でも保護されねばならない。派生型でそのまま維持される。
> 4. 基底型の例外（exception）から派生した例外を除いては、派生型で独自の例外を投げてはならない。

今回はこのうち1-3の項目それぞれについて、具体例を用いながら解説していきます。

## 事前条件について

そもそも事前条件とは何でしょうか。
Wikipediaには

> 事前条件 (precondition) は、メソッド開始時に保証されるべき条件の表明である。

と示されています。
例えば、「除算をするメソッドの中で割る数が0ではない」というのは事前条件に当たります。

それでは、

> 事前条件（preconditions）を、派生型で強めることはできない。派生型では同じか弱められる。

とはどういうことでしょうか。

下図は、RPGのキャラクターについて表現した図です。
![事前条件.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2529362/51f0a355-700a-3271-8c30-0c7c0f66c625.png)



剣士と魔法使いはプレーヤーを継承しています。
引数に武器を受け取る攻撃という振る舞いを持っています。
プレーヤーは武器を参照しています。
剣と魔法の杖は武器を継承しています。

ここで、

- 剣士が使える武器は剣のみ
- 魔法使いが使える武器は魔法の杖のみ

という条件をつけくわえます。
プレーヤーの攻撃メソッドを見ると、引数の武器に対する制限はとくにありません。
つまり、プレーヤーの攻撃メソッドはどんな武器でも扱えるということになります。
プレーヤーを継承したサブクラス (剣士クラスや魔法使いクラス) では、使える武器に制限があります。
使える武器の制限を表現するため、攻撃メソッド内で武器の種類チェックなどを挟む必要があるでしょう。

プレーヤーの攻撃メソッドの事前条件は「**すべての武器**」であるのに対し、
剣士の攻撃メソッドの事前条件は「**剣のみ**」、
魔法使いの攻撃メソッドの事前条件は「**魔法の杖のみ**」
となっており、事前条件が狭まっています。
言い換えると、事前条件を強めています。

従って上記の例は、

> 事前条件（preconditions）を、派生型で強めることはできない。派生型では同じか弱められる。

というリスコフの置換原則に反しているということになります。

## 事後条件について

そもそも事後条件とは何でしょうか。
Wikipediaには

> 事後条件 (postcondition) は、メソッド正常終了時に保証されるべき条件の表明である。これはメソッド単位で表明される。正常終了とは、例外スロー終了やエラー発生終了ではないことを指す。

と示されています。

例えば、`int Add(int x, int y)`というメソッドであれば「xとyを足した値を返す」というのは事後条件に当たります。
あるいは、`List<T>.Add(T)`メソッドであれば、「Listの要素数が1増えること」「Listの末尾に要素が追加されること」などが事後条件に当たります。
それでは

> 事後条件（postconditions）を、派生型で弱めることはできない。派生型では同じか強められる。

とはどういうことでしょうか。

下図は有名な正方形・長方形問題の図です。
![事後条件.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2529362/c7614325-ad6e-fcea-3438-32983a951904.png)



長方形には

- 4つの角がすべて等しい (すべて90度)
- 二組の対辺がそれぞれ等しい

などの特徴があります。
上記の特徴を満たし、かつ、すべての辺の長さが等しい四角形を正方形と定義できます。
つまり、正方形は長方形の一種であるため、
上記例では正方形が長方形を継承しています。

ここで長方形と正方形の`SetHeight()`についてみてみましょう。

```c#:Rectangle.cs
// 長方形のSetHeight
public class Rectangle
{
    // ...略
    public void SetHeight(int height)
    {
        Height = height;
    }
    // ...略
}
```

```c#:Square.cs
// 正方形のSetHeight
public class Square
{
    // ...略
    public void SetHeight(int height)
    {
        Height = height;
        Width = height;
    }
    // ...略
}
```

長方形のほうでは、高さのみを更新しているのに対して、
正方形のほうでは、高さと幅を更新しています。

ここで、長方形と正方形のSetHeightに関して、事後条件を考えてみましょう。
長方形のSetHeightの事後条件は、

- Heightが変わること
- Widthが変わらないこと

です。
一方、正方形のSetHeightの事後条件は、

- Heightが変わること
- Widthが変わること

です。
長方形のSetHeightの事後条件である「Widthが変わらないこと」が正方形の場合ではなくなっています。
言い換えると、正方形は長方形を継承し、事後条件を弱めてしまっています。

従って上記の例は、

> 事後条件（postconditions）を、派生型で弱めることはできない。派生型では同じか強められる。

というリスコフの置換原則に反しているということになります。

## 不変条件について

そもそも不変条件とは何でしょうか。
Wikipediaには

> クラス不変条件 (class invariant) は、クラスが持つ公開された各メソッドの開始時と正常終了時に共通して保証されるべき状態についての条件である。

と示されています。

例えば、自然数であれば「0より大きい整数」が不変条件に当たります。

それでは

> 不変条件（invaritants）は、派生型でも保護されねばならない。派生型でそのまま維持される。

とはどういうことでしょうか。

下図は未成年と乳幼児についての図です。
![不変条件.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2529362/e283b586-7c83-7c11-6015-f7e0f2a9f95d.png)



未成年は0歳以上18歳未満です (2022年4月から変わりますね！)。
乳幼児は0歳以上6歳未満です (正確には未就学児らしいです)。

未成年の不変条件は、そのまま「0歳以上18歳未満」であることです。
乳幼児の不変条件も、そのまま「0歳以上6歳未満」であることです。
上記の例の継承では、不変条件が狭まっています。
言い換えると、不変条件がそのまま維持されていません。

従って上記の例は、

> 不変条件（invaritants）は、派生型でも保護されねばならない。派生型でそのまま維持される。

というリスコフの置換原則に反しているということになります。



# まとめ

リスコフの置換原則とは「**あるクラスを継承するとき、継承元と継承先のクラスの振る舞いを同じにしよう**」ということでした。
これは[オープン・クローズドの原則](https://qiita.com/k2491p/items/db69dd2dc43a5a678b4f)にも通じるところがあります。

リスコフの置換原則を守るためには下記のような原則を守る必要があります。

> 1. 事前条件（preconditions）を、派生型で強めることはできない。派生型では同じか弱められる。
> 2. 事後条件（postconditions）を、派生型で弱めることはできない。派生型では同じか強められる。
> 3. 不変条件（invaritants）は、派生型でも保護されねばならない。派生型でそのまま維持される。
> 4. 基底型の例外（exception）から派生した例外を除いては、派生型で独自の例外を投げてはならない。



# 参考文献

- 本
  - [Clean Architecture 達人に学ぶソフトウェアの構造と設計](https://www.amazon.co.jp/Clean-Architecture-達人に学ぶソフトウェアの構造と設計-Robert-C-Martin/dp/4048930656)
  - [アジャイルソフトウェア開発の奥義](https://www.amazon.co.jp/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA%E3%81%AE%E5%A5%A5%E7%BE%A9-%E7%AC%AC2%E7%89%88-%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91%E9%96%8B%E7%99%BA%E3%81%AE%E7%A5%9E%E9%AB%84%E3%81%A8%E5%8C%A0%E3%81%AE%E6%8A%80-%E3%83%AD%E3%83%90%E3%83%BC%E3%83%88%E3%83%BBC%E3%83%BB%E3%83%9E%E3%83%BC%E3%83%81%E3%83%B3/dp/4797347783)
- サイト
  - [リスコフの置換原則](https://ja.wikipedia.org/wiki/%E3%83%AA%E3%82%B9%E3%82%B3%E3%83%95%E3%81%AE%E7%BD%AE%E6%8F%9B%E5%8E%9F%E5%89%87#CITEREFLiskov1988)
  - [契約プログラミング](https://ja.wikipedia.org/wiki/%E5%A5%91%E7%B4%84%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0)
  - [リスコフの置換原則（LSP）をしっかり理解する](https://qiita.com/yuki153/items/142d0d7a556cab787fad)
  - [リスコフの置換原則（LSP）と契約による設計（DbC）の関連について](https://qiita.com/hiko1129/items/9b3066feffabccf83c16)
  - [リスコフの置換原則(LSP: Liskov Substitution Principle)](https://qiita.com/decoy0318/items/7a3ff73df4087fdf0636)
  - [【SOLID原則】リスコフの置換原則 - LSP](https://zenn.dev/chida/articles/5373e135be11f0)
  - [よくわかるSOLID原則3: L（リスコフの置換原則）](https://note.com/erukiti/n/n88b8ed99f1e1)
  - [契約による設計](http://www.02.246.ne.jp/~torutk/cxx/design/designbycontract.html)
  - [『科学的モデリング』第6回〜継承⑥](http://hsc-i.com/pdf/TotalProcess_chap6.pdf)
- 動画
  - [オブジェクト指向の原則２：リスコフの置換原則と継承以外の解決方法](https://www.udemy.com/course/objectfive2/)