今回は、開放・閉鎖原則のお話です。
これも、リスコフの置換原則と同じかそれ以上に、ソフトウェア開発者の方には有名な原則ですね。
これも、開発の現場では、みんな知ってるにもかかわらずないがしろにされがちな原則です。
英語でopen・closed principleですので、OCPと略されたりもします。
ソフトウェア開発者でない方には、この原則の概念を理解していただきたいと思います。
この原則によって、あなたの生活からストレスが軽減される…かもしれません。
ソフトウェア開発者の方には、この原則の重要性を再認識していただきたいと思います。
コンテンツ
計画は、細かければ細かいほど失敗しやすい
すごく楽しみにしてた観光だとか、失敗できない仕事だとかそういうことです。
そんなとき、人はどうも熱くなりすぎて、事前に事細かなことまで計画を立てたりしてしまいます。
でも、実はあなたが計画を細かくすればするほど、その計画はうまくいかなくなる可能性が高くなります。
なぜなんでしょう？
開放・閉鎖原則に反するからです。
では、開放・閉鎖原則とはなんなんでしょうか？
要約すると、以下のようになります。
拡張に対しては開いていて、修正に対して閉じていなければならない。
意味わかりませんね。例を見てみましょう。
例: 旅行計画
あなたなら、どんな計画を立てるでしょう？
- 計画案1
- 出発(9:00)→2時間→観光地A 昼食もとる(～14:00)→1時間→観光地B(～18:00)→移動30分→ホテル到着(18:30)
- 計画案2
- 出発(9:00)→2時間→観光地A到着(11:00)→A'を観る(11:00～11:30)→A''で遊ぶ(11:30～12:00)→昼食(12:00～13:00)→A'''を散策(13:00～14:00)→1時間→観光地B到着(15:00)→…以下略
どっちが失敗しにくい計画でしょう？
といっても、もちろん計画する人や参加する人の性格、計画性や体力、実行力など、いろいろな状況によって左右されますので、実際にはなんとも言えませんよね。
でも、今回着目する側面から言うと、1の計画のほうがベターということになります。
なぜか？
はい、計画を拡張しても問題になりにくいからです。
この場合、観光地A、観光地Bでの観光がそれぞれオブジェクトだと捉えることができます。
それぞれの到着時間と出発時間がインターフェイスです。
(すでに契約をご存知の方は、事前条件と事後条件であると捉えていただいても結構です。そもそも、インターフェイス自体が、広い意味で契約の一部ですし）
計画案1では各観光地の到着時間は決めていません。
インターフェイスには出発時間しかありませんね。
(事前条件はなしということですね)
で、ポリモーフィズムを考えると、それぞれのオブジェクトは、インターフェイスに違反しない限り、勝手に振舞えるはずですよね。
でも、計画案2の場合はどうです？
参加者の誰かが、実は観光地Aでもうひとつやりたいことがあると強情に言い出したら、難しいことになります。
その余分な行動をカバーするのに、あなたには2つの選択肢があります。
- 以降の計画の時間を後ろだおすために、(頭の中でも紙の上でもいいですが)全て再計算する。
- 代わりにどれかの行動を取りやめる。
ただし、細かい計算ですから、観光地内での歩行時間まで考慮に入れて、どの行動をやめるべきか慎重に決定する必要があるかもしれませんね。
計画案1の場合は？
そもそも、観光地Aの中で何をするのかまでは決めていないんですから、そんなの変更でも何でもありませんね。
とにかく14:00に出発できさえすれば、なんの問題もありません。
では、もし渋滞にはまっちゃったらどうでしょう？
計画案2を採用された方は、前の車のテールランプを眺めながら、どれだけのストレスを抱えてらっしゃるのか。
その方の胃が心配です。
計画というのは、紙に書いたりして参加者に伝えた段階で、「守るべきもの」になってしまいます。
観光やプライベートなものであっても、軽々しくあれもこれもと細かいことを詰め込んだりしないことをオススメします。
ストレスにさらされるより、気楽に楽しみたいですからね。
まして、仕事や責任のあることなら、なおさらです。
がんばって細かいことを決めれば決めるほど、逆に失敗する可能性が高まるわけですから。
ただし、注意してください。
これは計画をイイカゲンにやれというわけでも、ましてや計画を立てるなということを言ってるわけではありませんよ。
計画は必要最小限にとどめようということです。
ソフトウェア開発者の方向けに言えば、「守るべきもの」とはプライベートでないメンバやオーバーライド可能なメンバのことです。
そういったメンバを作るときに注意深くすることで、失敗の可能性を減らせるケースは非常に多くあります。
オープンでクローズド
では、最初に戻って「拡張に対して開いている」とはどういうことでしょう？また、「修正に対して閉じている」とはどういうことでしょう？
「拡張に対して開いている」とは、オブジェクトの振る舞いを拡張できるということです。
今回の例で言えば、観光地AやBそれぞれの中での観光の仕方を、好きに変えたり増やしたりできるということですね。
「修正に対して閉じている」とは、それでも他のオブジェクトに影響を与えたりしないということです。
今回の例で言えば、たとえば観光地Aの中で何をするのかを変えても、観光地Bでの観光には影響を与えないということですね。
開放・閉鎖原則は、こんなふうにあなたの暮らしからストレスを減らしてくれます。
あれしよう、これしようと思って、いざやってみるとなかなかうまくいかずに、考えてることの半分もできなかった。
なんて経験がある方、ひょっとして、これを念頭においてやってみると意外とうまくいくかもしれませんよ。
この原則は、依存関係逆転の原則と関連があります。
依存性を逆転させることで、開放・閉鎖原則を遵守することができる場合がよくあるのです。
ソフトウェア開発者の方だと、依存関係逆転の原則については、DI(Dependency injection)やIoC(Inversion of Control)でよく取り上げられますので、ご存知の方は多いかと思います。
このブログでも、あらためて取り上げるつもりです。
オススメ
いろいろな説明を見ることで、理解を深めてください。
また、オブジェクト指向の原則に関してはアジャイルソフトウェア開発の奥義で詳しく解説されています。
設計やコードの例など、より具体的で実践的な説明がされています。
原則以外にも、デザインパターンのいくつかやアジャイル開発のプラクティスについても解説されています。
実際の開発の過程にのっとっての解説―ケーススタディも、実践的で非常に有益です。
0 件のコメント:
コメントを投稿