第1回 ソフトウエアパターンとは何か

ソフトウエアパターンとは

　これから3回ほどで、ソフトウエアパターンについて紹介したいと思います。今回は、ソフトウエアパターンとは何で、どのようなものがあるのか、全体像をつかんでもらいます。

　ソフトウエア開発の現場でパターンというと、まずはGoF（Gang of Fourの4人組）のデザインパターンのことが想起されるでしょう。オブジェクトを実装クラスと切り離して生成できるようにするFactoryパターンだとか、再帰的な木構造で汎用的なコンポーネントを作り出すためのCompositeパターンだとか、オブジェクト間の通知の仕組みをほかのオブジェクトと独立に登録管理できるObserverパターンといったものが代表例です。

　皆さんも、アプリケーションを設計したり・改良したりする際にお世話になったことがあるのではないでしょうか。デザインパターンとは、よく出くわす典型的な設計課題に対する一般的な設計解法をペアにしてカタログ化したものですから、具体的な設計上の問題にぶつかったときに参照してヒントにできるわけですね。

　世の中一般には、「ワンパターン」と言ってパターンは創造性がない、融通がきかない、固定的なもののあり方を示す言葉です。しかしながら、ソフトウエアパターンといった場合には、それはソフトウエアに関する情報共有のために構造化されたフォーマットのことを指すのです。創造性・独創性よりも標準化され共通のスタイルで整理されていることに意味があります。どのパターンも共通のフォーマットで5W1Hが意識されて記述されているため、それを適用したいと思うユーザーは適切なパターンを見つけやすくなっているわけです。

ソフトウエアパターンの構成

　ソフトウエアパターンは図1-1のようなテンプレートに従って記述されています。例えば、GoFのCompositeパターンであれば、

名前：Composite（複合オブジェクトの意）
状況：階層的ファイルシステムの開発
問題：ディレクトリ（ファイルやディレクトリを入れ子に含む）とファイルを区別なく取り扱いたい
解決：抽象クラスコンポーネントを用意し、そのサブクラスとしてLeafObject（ファイル）とComposite（ディレクトリ）を定義するとともに、Compositeをコンポーネントの集約とせよ
結果：LeafObjectもCompositeも同じインターフェースで区別なく利用できるようになる
理由：ディレクトリとファイルの論理的な階層構造と利用時の認知的な入れ子構造の実現が、共通のインターフェースをもつ抽象クラスコンポーネントの導入と適合する

という具合です。

　このようにパターンというのは、ある分野のノウハウ・知識をできるだけ的確にパッケージ化・カプセル化した1つの単位だということがわかります。「名前、状況、問題、解決、結果、理由」という項目のセットで構造化された知識モジュールになっています。つまりパターンはナレッジマネジメントを構成する基本要素だと言えます。

　ですから、これを利用して問題を解決したいパターンユーザーは、自分の置かれている状況を「前提」として把握し、その前提に含まれる制約条件（考慮点・特性）を「フォース」として解きほぐしていくことによって、その問題にもっともフィットした「解決の仕組み」が見つかるというわけです。こうなって初めて、複数のフォース（力）のバランスのとれた解決策（構造）のパターンをうまく選び出せ、ユーザーの抱える問題が与えられた前提のもとで解消されることになります。