hm1gv2d26QeqWrgl.qrunch.io読者になる3リスコフの置換原則とその違反を実例を踏まえて解説SOLIDオブジェクト指向プログラミングC#投稿日:2018-10-18最終更新:2018-10-24クロス元の投稿をみる(https://qiita.com/yuu...)SOLID原則の一つ、リスコフの置換原則について説明します。リスコフの置換原則とは名前からなんだか難しそうだけど、実例を踏まえて見てみるとそんなことはないです。リスコフの置換原則は要するに基本型Base、Baseの派生型Derivedがあるとする。Baseとして扱ってるものはBaseでもその派生型であるDerivedであっても扱えるようにすべき。将来的にSpecificDerivedが作られても扱えるようにすべきDerivedの派生クラスDerivedDerivedが作られても扱えるようにすべきたったこれだけです。実例を踏まえて解説してみます。sample1.Hogehoge();}サンプルではISampleInterfaceというインターフェイスを引数としています。実装者はISampleInterfaceのメンバではなく、それを実装したConcreteSample1クラスが持つHogehogeを使いたかったので、一度ConcreteSample1に変換をしてから、Hogehogeを使いましたとさ。何がいけないのか?Funcを使う人の視点に立ってみるとわかります。instance.Func(test);このFuncはConcreteSample1インスタンスありきのメソッドのため、使用者はConcleteSample1の存在を知りつつFuncを使わないといけません。コメントででも書かれてないと別のインスタンスを入れると別の挙動をすることが使用者にはわからないです。※コメントに書くのもやめましょう。静的にコンパイラによって判断してもらえることが最強のエラー対策です。開発者全員がFuncのことに想いを馳せつつ開発するのはよくないです。Funcに機能が不足していると、今現在の実装から違反例その2のようなことをしがちです。sample1.Hogehoge();//Hogehoge実行するだけならFuncいらねーじゃんっていう野暮な突っ込みは期待してない。現実にはもっと複雑なケースがあるのだ。}sample1がConcreteSample1に対して決め打ちしているのなら引数はConcreteSample1にすべきです。使用者もConcreteSample1を渡すことがわかっていれば最初から渡します。sample3.Hogehoge3();}このような実装に至るのは私が考えるに2パターンぐらいあってもうすでに違反しているんだから仕方ないし付け足しとけクラスはわかりやすく分類するためだけに存在するという認識で、実際に処理が分岐しているのはFuncなのでそこで分岐させることを思いついた2つ目のパターンですが例としてデスクトップ上にあるオブジェクトを想像してみてください。file.LaunchApplication();}現実のプロジェクトは後から要件を追加されることもあります。いうことでフォルダに対して仕様を追加してみます。file.LaunchApplication();}さて、また新しく要件が追加されました。ダブルクリックの動作はそのオブジェクトの挙動と同じ挙動を取ります。//やべーどうすんだ!}こうなってくるとDoubleClickというメソッドはとてつもなく長い処理になります(いわゆる神メソッドというやつです)。その中で行っているのはおおかた条件分岐であり、ほぼほぼ関係のない処理の割合が増えることになってます。テストすることを考えてみましょう。DoubleClickというメソッドをテストする際に一体テスターはどれだけの準備が必要になるだろうかと。改善してみる今回の場合は引数を変更する場合は使えません。いう時はそもそもそFunc内部での条件分岐はそこでする必要があったのか?を考えてみると解決するかもしれないです。実際の挙動が確定するのはもっと前の段階で、それはインスタンスが生成されるときなのです。NullSample.Instance;//何にも該当しない場合もNullを返すとややこしくなるのでNullObjectパターンを作っておくと優しい。factory.GetInstance();instance.Func(sample);こうすることでDoubleClickの例で言うと、一つ一つのテストが1クラスにまとまってやりやすくなったと思います。最後にと、ここまで熱弁したものの必ず改善しなければいけないというわけではないです。これを改善するために例えば修正が多岐にわたるようであるとかならば、課題にして後回しにするという判断も時には有効です。この実装を続けるとプログラムはガタガタになっていきます。モチベーションも下がる一方で、開発生産性も非常に悪くなっていきます(先の例で言うとショートカットが仕様として追加された時点で、変更をしなければいけない箇所を特定するのに時間がかかります)。ならないために、開発者は日々いいコードと悪いコードを探求する心が大事ですよね。Qrunch.netサーバー提供フィードバックを送信する。