連載 .NETで始めるデザインパターン 第2回 うまくデザインパターンを使うための心得 太陽システム株式会社　中西 庸文 2005/02/02

Page1 Page2

Back Issue

1 .NET開発におけるデザインパターンの有用性 2 うまくデザインパターンを使うための心得 3 リファクタリングにより導き出すStrategyパターン 4 リファクタリングにより導き出すTemplate Methodパターン 5 Compositeパターンを導き出すための準備 6 リファクタリングにより導き出すCompositeパターン 7 デザインパターンの落とし穴

　前回では、.NET開発におけるデザインパターンの有効性を述べるために、問題を含む設計に対してデザインパターンを適用するとそれがどのように解決されるのかを例示した。その冒頭では「デザインパターンとは、オブジェクト指向設計に深くかかわってきた先人たちによりすでに文書化され、まとめられている問題解決の知恵」と説明したが、デザインパターンは単なる「問題解決策のカタログ」というだけではない。では、デザインパターンとは一体何なのか。

デザインパターンとは何か

●パターンの概念とデザインパターンが生まれた背景

　「パターン」という概念をひと言で表現すれば、次のようになるだろう。

ある特定の「コンテキスト」で発生する「問題」と「解決策」の組に名前を付けたもの

　このようなパターンの概念は、建築家クリストファー・アレグザンダー氏の思想に端を発する。彼の思想がソフトウェアの世界にも応用できることに気付いたのが、XP（エクストリーム・プログラミング）の提唱者であるケント・ベック氏だ。その後、ケント・ベック氏は、ワード・カニンガム氏の協力を得て『Using Pattern Languages for Object-Oriented Programs』という論文を完成させた。このGUIプログラミングに関するパターンについて記された論文は、1987年にOOPSLA（Object-Oriented Programming, Systems, Languages, and Applications）というオブジェクト指向の学会で発表された。

　その後、1994年にエリック・ガンマ氏、リチャード・ヘルム氏、ラルフ・ジョンソン氏、ジョン・ブリシデス氏らGang of Four（通称GoF）による書籍『オブジェクト指向における再利用のためのデザインパターン』（以降、書籍『デザインパターン』）が出版され、これはオブジェクト指向技術者にとってのベストセラーとなった。この書籍によってデザインパターンは広く世に知られるようになったのである。

　建築の世界からソフトウェアの世界に持ち込まれたパターンの背景について知ってもらったところで、その概念についてもう少し掘り下げておこう。

●パターンの正しい理解

　パターンを正しく理解するためには、「問題」が何であり、それがどのような「コンテキスト」で発生するかを知ることが重要となってくる。しかし、パターンの汎用性を高めるために、「問題」はかなり抽象的に表現されている場合がある。そこで、問題に対する理解を深めるために、問題が発生する状況となる「コンテキスト」にも注目する必要が出てくるのである。例えば、書籍『デザインパターン』では、問題の多くは「目的」として記述されており、コンテキストは「動機」として具体的なシナリオを用いて記述されている。

　またパターンの正しい理解のためには、問題とコンテキストの関係を把握し、パターンの名前とひも付けて、1つのイメージとしてパターンをとらえることも大事だ。よいパターンにはその意図が明確になるようなシンプルで分かりやすい名前が付けられているものだ。

　さらに、多くのパターンを知ることで自分なりの「パターン・マップ」を構築し、必要な場所で適切なパターンを引き出せるようにしておく必要もある。加えて、パターン・マップ上で各パターン間の関連性や非関連性を把握しておくことも重要になってくるだろう。このような場合でも、分かりやすいパターン名はよい「しおり」となる。

　逆の視点から考えると、オブジェクト指向開発の初心者がパターンを知ることで、開発者として何を問題としてとらえる必要があり、そのような問題はどのような状況で発生するのかを学ぶことができるのである。問題が発生してしまうことよりも、その問題に気付かないことや見過ごしてしまうことの方がより大きな「問題」だ。パターンはあるコンテキストにおいて過去に繰り返し発生した問題を扱ったものである。過去に問題とされた事項をパターンから学ぶことで、未来の問題にも対処できる力も付くのである。

●ソフトウェアにおけるパターンの抽象化レベル

　書籍『Microsoft .NET によるエンタープライズ ソリューション パターン』では、ソフトウェアにおけるパターンはその抽象化レベルによって、以下のように分類されている。

分類	説明
アーキテクチャ・パターン	アーキテクチャ・パターンは、ソフトウェア・システムの基本となる構造を表現するスキーマである。このパターンでは、事前定義された一連のサブシステムを提供してそれらの責務を指定し、それらの関係を整理するためのルールやガイドラインが記述されている
設計パターン	設計パターンは、ソフトウェア・システムのサブシステムまたはコンポーネント、あるいはそれらの関係を洗練するための基本構想である。特定のコンテキストにおける一般的な設計上の問題を解決するために使用する相互に影響し合うコンポーネントで繰り返し発生する共通の構造が記述されている
実装パターン	実装パターンは、特定のプラットフォームに固有の抽象化レベルの低いパターンである。実装パターンでは、所与のプラットフォームの機能を使用してコンポーネントの特定の部分またはそれらの関係を実装する方法を記述する
ソフトウェアにおけるパターンの抽象化レベルによる分類

　このように、ソフトウェアのパターンは抽象化レベルの高い順に、アーキテクチャ・パターン、設計パターン、実装パターンに分類される。これらの分類は、「POSA」という略称でよく知られている書籍『ソフトウェア アーキテクチャ――ソフトウェア開発のためのパターン体系』の中で、アーキテクチャ・パターン、デザインパターン、イディオムとして定義されていた分類を、それぞれ再定義したものだ。この書籍は、出版されてからかなり年月がたっているのにもかかわらず、いまだに新鮮さを失わない良書である。機会があればぜひ一度手に取っていただきたい一冊だ。

　また、このほかにもさまざまな分野にわたるソフトウェアのパターンが存在する。例えば、書籍『リファクタリング』の著者であるマーチン・ファウラー氏によるドメイン分析パターンとしての「アナリシスパターン」や、反面教師的なパターンとしての「アンチパターン」などが有名である。

●デザインパターンの概念

　ここまでにパターンの意味やソフトウェアにおけるパターンの分類について説明してきた。デザインパターンは、現在最も広く知られているソフトウェアのパターンである。このデザインパターンの概念をひと言で表現すれば、次のようになるだろう。

ソフトウェア開発において、ある特定の「コンテキスト」で「繰り返し発生」する、一般的な設計上の「問題」と「解決策」の組に「分かりやすい名前」を付けたもの

　これは、GoFの1人であるジョン・ブリシデス氏による書籍『パターンハッチング――実践デザインパターン』に記述されているパターンの再定義ともほぼ一致する。

●原点に立ち戻ろう

　ここまでで、デザインパターンとはどのようなものかを説明したが、筆者が本当に伝えたいことは、実は少し別のところにある。

「デザインパターンが先人たちのリファクタリングの結果ならば、そこに立ち戻ろう」

　過去に繰り返し発生した問題を解決する際に、先人たちは問題を含むコードに対してリファクタリングを重ねてデザインパターンを導き出したのだろう。その結果がデザインパターンのカタログとして記録されたことにはとても意味がある。

　デザインパターンがリファクタリングの結果として生まれたものであるとすると、それを最初からシステムに適用するのは容易ではない。それができるようになるには、それなりの経験やスキルが必要となる。そのため、デザインパターンを念頭に置いての設計しか考えないというのもお勧めできるものではない。知っているデザインパターンをシステムに当てはめるだけでは、ただの「ワンパターン」になってしまう。

　やみくもにデザインパターンを使用せず、リファクタリングからデザインパターンを導こう。その結果として、必要な場所に必要なだけのデザインパターンが使われるはずだ。これがうまくデザインパターンを使いこなすための1つの解となるのではないだろうか。

　以上が、デザインパターンとはどのようなものかという問いに対する筆者なりの答えである。

　以降では、リファクタリングからデザインパターンを導く方法について解説していく。まずは、それに当たって必要になってくるオブジェクト指向設計の基本について説明しよう。

INDEX
	.NETで始めるデザインパターン
	第2回 うまくデザインパターンを使うための心得
	1．デザインパターンとは何か
	2．デザインパターン習得に必要なオブジェクト指向設計の基本

　

「.NETで始めるデザインパターン」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）