これまで2回続けてデザイン・パターンについて学んできました。今回は,重要なソフトウエア開発原理として知られるオープン・クローズ原則(OCP)の観点からデザイン・パターンを眺めてみましょう。単なる流用可能なソフトウエア・パターン以上の価値がデザイン・パターンに隠れていることが発見できるでしょう。

 昔々,技術者たちは計算機などの機械を「金物」という意味でハードウエアと呼びました。さらに実体のないプログラムのことをソフトウエアと呼ぶようになりました。今ではハードウエアもソフトウエアもすっかりコンピュータ関連用語として定着してしまいましたが,元々は技術者間の俗語のようなものだったのです。

 ソフトウエアと呼ぶからには「柔らかい」かというと,実際には柔軟性に乏しいものが多いです。規模の小さなものであれば,変更は簡単で柔らかい感じがありますが,ビジネスに用いられるような大規模ソフトウエアでは各部分の依存関係が大きく,こちらを直そうとすると別の場所に影響が出るなど,なかなか思うままに変更できないものです。

ソフトウエア開発の悲劇

 ソフトウエア開発において,さまざまな問題の原因となるのは「複雑さ」と「変化」です。

 ソフトウエアの規模が大きくなればなるほど,各部分は複雑に絡み合い,次第に変更が難しくなります。ソフトウエアを単純で小規模なものに限定すれば変更しやすくなりますが,コンピュータの能力が向上するにつれ,コンピュータにやらせたい仕事はますます増大しています。ほとんどのソフトウエアはユーザーの要求に応じて拡張されていき,複雑化の一途をたどっています。

 ソフトウエアの機能が増加するだけならそれほど問題はないでしょう。しかし,ソフトウエア開発においては,仕様変更がほぼ確実に発生します。紙の上でソフトウエアの振る舞いを打ち合わせたときには納得しても,いざプログラムを見ると「やっぱり違う,直してほしい」と言い出すユーザーは多いものです。私自身も,長らく職業プログラマとしてユーザーの「気まぐれ」に,愚痴をこぼす経験はたびたびありました。

 それにもかかわらず,先日,同僚が作成したプログラムに対して,実際に動作するものを見てから注文を出してしまいました。今までさんざん愚痴をこぼしてきたユーザーと全く同じように振る舞ってしまった自分を思うと,ああ,人間とはいかに自分勝手なものかと嘆かざるを得ません。

 それはともかく,ソフトウエアが複雑化し続けるため,変更に対するコストが確実に増加しているにもかかわらず,ユーザーの要求は多様化し,ソフトウエアに対する変更要求の頻度も増大しています。このままではソフトウエア開発はどこかで破綻してしまいそうです。

オープン・クローズ原則

 このような事態に向き合う際に役立ちそうな原則が「オープン・クローズ原則(open-closed principle)」です。オープン・クローズ原則は,Eiffel言語の設計者でもあるBertrand Meyer氏が,著書『Object-Oriented SoftwareConstruction』(『オブジェクト指向入門』,アスキー)で紹介した原則です。定義は,次の通り単純です。

●モジュールは拡張に対して開いて(Open)おり,修正に対して閉じて(Closed)いなければならない。

 「拡張に対して開いている」とは,モジュールの拡張が可能ということです。例えば,データ構造にフィールドを追加できる場合や新しい機能を追加できる場合は,モジュールが開いているといえるでしょう。あるモジュールがどのように使われるか,すべてを予想することは不可能です。将来のニーズに対応するためには,拡張に対してオープンである必要があります。

 「修正に対して閉じている」とは,あるモジュールが別のモジュールから参照されている場合の要求です。参照している側のモジュールを変更しなくても問題が発生しないように作られている必要があります。

 つまり,あるモジュールの内部構造を修正したとしても,モジュールのインタフェースは安定しているべきです。インタフェースが安定していなければ,モジュールを安心して利用できません。安定していないモジュールを利用することで,他のモジュールをたびたび変更しなければいけないようでは,ソフトウエアの複雑度と保守のコストは増大する一方です。

 オープン・クローズ原則は「開放・閉鎖原則」と訳されることもありますが,ちょっと硬いですね。いずれにしても,毎回毎回,オープン・クローズ原則と繰り返すにはちょっと長いので,以下ではOCPと略すことにします。