hiko1129.qrunch.io読者になる1開放閉鎖原則についてのまとめSOLID投稿日:2019-10-17最終更新:2019-10-17クロス元の投稿をみる(https://blog.hiko1129...)はじめに対象読者は初心者です。C.Martinの著書「アジャイルソフトウェア開発の奥義」では、ソフトウェアの構成要素(クラス、モジュール、関数など)は拡張に対して開いていて、修正に対して閉じていなければならないと説明されています。「拡張に対して開いている」とは、雑に言い換えると「機能追加がしやすい」です。「修正に対して閉じている」とは、雑に言い換えると「変更が他の場所に影響を及ぼさない」です。具体例として、自分が考えたものは、くじ引きです。一般くじとプレミアムくじというものがあり、それぞれが違う抽選ロジックを持っているとします。開放閉鎖原則に従って実装したくじ引きのコードは、下記のようになります(インターフェース(publicなメソッド)部分が重要なので細かい部分は除いています)。プレミアムくじを引くなぜ、上記のコードが開放閉鎖原則に従っていると言えるのでしょうか?要件の追加やバグの修正の例を用いて説明します。新たに要件が追加され、スーパープレミアムくじを追加することになりました。異なっているのは抽選ロジックの部分のみのため、新たにSuperPremiumLotteryLogicクラスを実装しました。スーパープレミアムくじを引くこのとき、既存のコードには一切変更を加えずに、新機能を追加できました。これが、「拡張に対して開いている」ということです。機能実装後、スーパープレミアムくじのテストを行っている際に、バグが発見されたため、SuperPremiumLotteryLogicを修正しました。このとき、既存の他のコードに一切影響を及ぼさずに修正を行うことができました。GeneralLotteryLogicでもPremiumLotteryLogicでも同様に問題が発生して修正することになっても(execの引数と戻り値が変わらない限り)他に影響を及ぼしません。これが、「修正に対して閉じている」ということです。開放閉鎖原則を守るべきなのか当たり前のことなのですが、そもそも要求が変わるからです。すべてのプログラムが人の要求を満たすために作られています。人の要求は変わります。要求が変わったときには、機能の追加や変更が必要になります。そのとき、いかに容易に安全にできるかがこの原則を守っているかどうかで変わってきます。すれば開放閉鎖原則を満たすように作れるのか自分は、下記3つを押さえることが大事だと考えてます。変更されやすい部分を見抜く変更発生時に追加する原則を知る変更されやすい部分を見抜く作るものにもよると思いますが、似たようなビジネスを他が行っていたり、抽象化して捉えたときに同じようなものが存在しているときには、変更されやすい部分がわかります。上記で例として上げたくじ引きはわかりやすいと思います。ソシャゲなどで見られるガチャやくじといったものにはパターンが存在しているので、そういったものから考えて変更されやすそうだという当たりをつけることができます。ただの勘ではなく、分析した結果として適用する必要があります。Martinは「アジャイルソフトウェア開発の奥義」の中で、「OCPの適用は起こる可能性の高い変更に限定すべきなのは明らかだ。」と述べています(詳しくは著書をお読みください)。変更発生時に追加する全ての「変更されやすい箇所を見抜く」ことは困難なので、変更が発生されてから抽象を追加して、開放閉鎖原則に従うようにするというのもありだと思います。テストコードが書かれていたり、強い静的型付けに頼れる状態であったりしないと厳しいと思います。従っている例として上げたコードは、デザインパターンで言うところのストラテジーパターンに該当します。いったデザインパターンについて知っておいたり、抽象(インターフェース)に依存するように作るということを知っておくと開放閉鎖原則に従ったコードが書けるようになると思います。Principle)である開放閉鎖原則についてまとめてみました。Architecture」もおすすめなので、ぜひ読んでみてください。(自分の書いたコード含めて)人を不幸にしないコードが普及することを願う。Qrunch.netサーバー提供フィードバックを送信する。