リスコフの置換原則（LSP）をしっかり理解する

17845 ワード

アーキテクチャオブジェクト指向プログラミング SOLID 設計オブジェクト指向テキストリンク

SOLID 原則の１つ「リスコフの置換原則」についての記事になります。
この原則に関する幾つかの記事を眺めてみても、どうも他４つの原則と比べて腹落ちしない部分があったので理解の為しっかり調べてみました。

S が T の派生型であれば、プログラム内で T 型のオブジェクトが使われている箇所は全て S 型のオブジェクトで置換可能
([1] wikipedia より引用）

リスコフの置換原則は上記のようにシンプルに説明されている事が多いですが、基底型と置換可能な派生型となるには幾つか遵守すべきルールがあります。この原則は Barbara Liskov 氏が『A Behavioral Notion of Subtyping』([9]) という論文で提唱した内容であり、後に「リスコフの置換原則」として認知されるようになりました。元々の論文名から分かるように、その本質は「サブタイプ（派生型）の振る舞いの概念」について説明しています。つまり「サブタイプの振る舞いはこうあるべきだ」という１つの指針がリスコフの置換原則と言えます。

リスコフの置換原則が提唱するサブタイプの振る舞い

リスコフの置換原則が提唱するサブタイプにおける振る舞いの規範は、下記大きく分けて２項目の各ルールを守る事で達成する事ができます。（参考 [10], [11], [12], [13])

1. スーパータイプメソッドの振る舞い保持

シグネチャ（インターフェイス）ルール

引数はスーパータイプと同一の数です。引数の型はスーパータイプと同一か、それより制限の少ない型（反変性）を受け取る必要があります。
返り値の型はスーパータイプと同一か、それよりも制限が強い型（共変性）を返す必要があります。
スーパータイプと同一型の例外、もしくはその例外のサブタイプのみを返す必要があります。

反変性、共変性については [14], [15] ,[16] が参考になります。

事前条件と事後条件のルール

事前条件はスーパータイプと同一か、それよりも弱める事ができます。反対に条件を強める事はできません。
事後条件はスーパータイプと同一か、それよりも強める事ができます。反対に条件を弱める事はできません。

事前条件と事後条件は Bertrand Meyer 氏の「契約による設計（DbC）」でも使用されており、Barbara Liskov 氏も [9] の論文の中で同一のルールであると述べています。事前条件と事後条件の詳細に関しては [2], [8] でわかりやすく説明されています。

2. スーパータイプのプロパティーの保持

不変条件のルール

スーパータイプで常に満たされていたプロパティーの不変条件は保持する必要があります。たとえば、スーパータイプでプロパティー A の値は B の値を超えないという条件があった場合に、サブタイプもこれを保持する必要があります。

履歴（制約）のルール

スーパータイプから新規追加またはオーバーライドされたメソッドは、スーパータイプで許可されていない方法でプロパティー値を変更してはならない。たとえば、スーパータイプで常に固定値であると確約されているプロパティー A に対して、サブタイプでこれを変更する事はできません。

サブタイプになり得るのは継承によるサブクラスだけでは無い

構造型のオブジェクト指向言語では、型 A のオブジェクトが型 B のオブジェクトの処理できるメッセージすべてを処理できるなら（言い換えると、同じメソッドを実装していれば）、継承関係に関係なく、A は B の派生型となる。
([19] wikipedia より引用)

OCamlは、クラスや継承・インタフェースなどを宣言しなくてもオブジェクトやメソッドの型を自動で推論する。部分型関係（いわゆるis-a関係の一種）も、実際のオブジェクトの型にしたがいあらかじめ宣言をしなくても成立する。これを構造的部分型（structural subtyping）という
([20] xtechの記事より引用)

上記は構造型(structural subtyping)オブジェクト指向言語の場合には継承を用いなくても、スーパータイプと同一のシグネチャを持ち、置換可能なオブジェクトはサブタイプである事を説明しています。つまり、is-a 関係はクラス継承以外でも成り立ちます。is-a 関係がクラス継承の概念として説明されるのは [21] でも述べられている通り、大抵都合が良いからです。

また、サブタイプの定義ではあくまで型同士のみが is-a の関係であることを示唆しており、実装は関係ないためスーパータイプに期待される振る舞いとシグネチャを引き継いでいれば、それはサブタイプと言えます。従って、実装継承（extends）ではなくインターフェイス実装（implements）の間でもサブタイプは成り立つと言えます。「振る舞い = 契約（事前条件や事後条件、不変条件）」であり、インターフェイスで予めそれらを取り決めて（設計して）おき、後はそれを遵守して実装するという考え方になります。

リスコフの置換原則は何を示してくれるのか

正しい is-a 関係を示す為の原則であり、それは継承すべきかどうかの判断指針になります。この原則に照らし合わせて is-a 関係が成り立たない場合、他のアプローチを模索してより良い設計に導く事ができます。たとえば、下記のような選択肢も取ることができます。([22], [23] 参考)

両者の関係性を見直し、共通している部分をインターフェイス又は抽象クラス化して、より適切なスーパータイプとサブタイプの関係性を築く。
is-a 関係を解消し、has-a 関係であるコンポジション（委譲）に切り替える。

リスコフの置換原則に違反してはいけない理由

この原則に違反することは、SOLID 原則の１つ「オープン・クロースドの原則（OCP）」の違反にも繋がってしまうためです。下記に一例としてリスコフ置換の原則（LSP）違反のコードを記載してみました。スーパータイプ（Player）に対して、サブタイプ（HlsPlayer, DashPlayer）は LSP に違反しています。

LSP違反の例

// スーパータイプ
class Player {
    constructor() { /*...*/ }
    /**
     * プレイヤーの停止処理
     */
    function pause() {
        /*...*/
    }
};

// Player のサブタイプ
class HlsPlayer extends player {
    constructor() { /*...*/ }
    /**
     * pause 実行前に必要（スーパータイプには無いメソッド）
     */
    function reservePause() {
        /*...*/
    }
};

// Player のサブタイプ
class DashPlayer extends player { 
    /* hlsPlayer と同じく reservePause を実装している */
};

const playerFactory = (option) => {
    switch (option.mediaName) {
        case 'hls':
            return new HlsPlayer(option);
        case 'dash':
            return new DashPlayer(opiton);
        default:
            return new Player(option);
    }
};

class Controller {
    constructor(player) {
        this.player = player;
    }
    function start() { /*...*/ }
    function end() {
        const mediaName = this.player.media;
        // playerFactory で受け取る Player を出し分けているのにスーパータイプとサブタイプで振る舞いが
// 違うため受け取り先（Controller内）でも出し分け処理が必要になってしまっている。
        // また新しいサブタイプの Player が作られた時に、下記 if 文に追加する必要が出てきそう。
        // 追加に対して修正が受け取り先に及んでおり、 OCP に違反している
        if (mediaName === 'hls' && mediaName === 'dash') {
            this.player.reservePause();
        }
        // Controller が受け取った Player がサブタイプの場合、スーパータイプと比べて pause を
// 実行するための事前条件が強くなってしまっている。（pause の前に reservePause が実行されている必要がある）
        // LSP に違反している
        this.player.pause();
    }
};

const player = playerFactory(option);
const controller = new Controller(player);
controller.start();
controller.end();

LSP に違反しないよう、特に継承する際は心がけましょう。

参考資料

Author And Source

この問題について(リスコフの置換原則（LSP）をしっかり理解する), 我々は、より多くの情報をここで見つけました https://qiita.com/yuki153/items/142d0d7a556cab787fad

著者帰属：元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。

Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .

C++プログラミングレポート(17-1)

C++入力文字列の問題