矢沢久雄の早わかりGoFデザインパターン(1)

図1●(1)オブジェクト間の関連がゴチャゴチャしている。(2)Medliator（調停者）となるオブジェクトを置けば関連をスッキリ整理できる

[画像のクリックで拡大表示]

　デザインパターンとは、様々なプログラムで再利用できる汎用的な設計パターンのことです。プログラマの世界では、様々なデザインパターンが知られていますが、その中でも特に有名なのが「GoFデザインパターン」です。GoF（ゴフ）とは”The Gang Of Four（4人の奴等）”の略であり、エリック・ガンマ、リチャード・ヘルム、ラルフ・ジョンソン、ジョン・ブリシディースの4人を指しています。

　彼らは、オブジェクト指向プログラミングに役立つデザインパターンを持ち寄り、それらを”Design Patterns : Elements of Reusable Object Oriented Software”というタイトルの本にまとめました（1995年発刊）。この本は、通称「GoF本」と呼ばれ、日本語にも翻訳されています。邦題は「オブジェクト指向における再利用のためのデザインパターン（ソフトバンクパブリッシング刊）」です。この中に示された23種類のデザインパターンが、GoFデザインパターンと呼ばれます。

　GoFデザインパターンを学びたいなら、GoF本を読むべきでしょう。考案者たちが自ら書いた本なのですから、これほど確かなものはありません。いわゆる、バイブル的な本です。しかし、いきなり数百ページの本を読むのは面倒でしょう。プログラマの薀蓄の一つとして、とりあえず概要だけを知りたいという人もいるはずです。自分に大いに役立つものだと判断できたなら、あらためて本格的に勉強すればいいのです。

　この連載は、短時間でGoFデザインパターンの概要を伝えることを目的としています。バイブルの前に読む、いわばお寺のパンフレットのようなものです。気軽な語り口調で書きますので、どうぞ皆さんも気軽にお読みください。

●GoFデザインパターンを知って目が覚めました

　まず、GoFデザインパターンを知る重要性を語らせていただきます。私は、今から十数年前にリリースされたVisual C++ 1.0で、はじめてオブジェクト指向プログラミングという考え方に触れました。オブジェクト指向プログラミングに興味があったわけではありません。仕事で使っていたC言語コンパイラであるMSC（Microsoft C Compiler）が、バージョンアップして勝手にC++になってしまったのです。

　C言語では、変数（データ）と関数（処理）の集合体としてプログラムを構築します。それに対して、C++では、新たにクラスという概念が加わりました。「クラスって何だ？」なかなか理解できませんでした。それでもガンバッテ勉強して、どうにかC++を使いこなせるようになりました。その後、C++をベースとしたJavaやC#もマスターしました。

　オブジェクト指向プログラミングに関して、自分なりに確固たる考え方を持っていました。オブジェクトとは、データと処理を一緒にまとめた単位（モジュール）です。プログラムをオブジェクトの集合体として構築することが、オブジェクト指向プログラミングです。オブジェクトは、コンポーネント（部品）であると言えます。既存のコンポーネントを再利用することで、開発効率を高められます。

　ところが、数年前に衝撃的な事件がありました。GoFデザインパターンとの出会いです。特定の役割を持たせたオブジェクトの組み合わせパターン（つまりデザインパターン）を再利用できることに気付かされたのです。何と嬉しいことに、すでに便利なパターンが数多く考案されています。実際に、いくつかのパターンを見て、目が覚めるような思いがしました。プログラミングの勉強を始めたばかりの頃に、バブルソートや二分探索などのアルゴリズムを知ったときと同じぐらいワクワクしました。

　皆さんも、バブルソートや二分探索といったいわゆる「定番アルゴリズム」をご存知でしょう。定番アルゴリズムを知ったことで、プログラミングに目覚めたでしょう。「なるほど！ アルゴリズムとは、こうやって工夫して考えるものなんだ」と気付いたはずです。それと同様の感動が、GoFデザインパターンにもあります。オブジェクト指向プログラミングは、アルゴリズムを考えるより視点が高いものです。いくつかのオブジェクトを、どのように組み合わせれば目的のプログラムを構築できるかと考えるのです。そのお手本となる「定番パターン」がGoFデザインパターンです。GoFデザインパターンを知れば、「なるほど！ オブジェクト指向プログラミングとは、こうやって工夫して考えるものなんだ！」と目覚めます。

【お役立ち度】★★★★★
●オブジェクトの関連を整理するMediatorパターン

　GoFデザインパターンには、ぞれぞれ内容を表す名前が付けられています。23種類のパターンは、オブジェクトの「生成」に関するパターン、プログラムの「構造」に関するパターン、オブジェクトの「振る舞い」に関するパターンの3つに分類されています。パターン名を直訳すれば、何かしら特定の役割を持ったオブジェクトが登場するんだな、と想像が膨らむでしょう。

表1 GoFデザインパターンは全部で23種類ある

　今回は、パターンを1つだけ紹介します。「Mediatorパターン」です。GoF本では、それぞれのパターンの「目的]「背景」「効果」などが明示されています。私も、ちょっと真似をしてみましょう。複数のオブジェクトを組み合わせてプログラムの機能を実現するという目的において、オブジェクト間の関連がゴチャゴチャになってしまうという背景（問題）があり、Mediatorパターンの採用によって関連をキレイに整理できるという効果があります。説明だけでは、何のことだかわからないと思いますので、具体例をお見せしましょう。

　図1[拡大表示](1)をご覧ください。これは、UML（Unified Modeling Language、ユーエムエル）と呼ばれる表記法で記述されたプログラムの設計図です。UMLでは、四角形の中に下線付きで名前を書いてオブジェクトを表し、関連のあるオブジェクトを矢印で結んで示します。ここで関連があるとは、他のオブジェクトの持つメソッドを呼び出しているという意味です。

　見ての通り4つのオブジェクトA～Cが、それぞれ他の3つのオブジェクトと関連を持っています。このまま無事に動作しているなら問題ないでしょう。しかし、もしも1つのオブジェクトの内容を改造したらどうなるでしょうか？ 他のすべてのオブジェクトに影響を及ぼしてしまいます。新たなオブジェクトを追加する場合も、それと関連する複数のオブジェクトに何らかの改造が必要になるはずです。プログラムを改造したら、テストしなければなりません。たった1つのオブジェクトを改造や追加したことで、プログラムの多くの部分をテストし直さなければならないのです。これは、あまりにも面倒なことでしょう。

　問題の原因は、オブジェクト間の関連が複雑過ぎることです。そこで、他のオブジェクトの調停者となるオブジェクトMを追加してみましょう（図1[拡大表示](2)）。オブジェクトA～Ｄは、オブジェクトMを仲介して他のオブジェクトと関連付けられることになります。もしも、オブジェクトAを改造したとしても、影響を及ぼすのはオブジェクトMだけで済みます。オブジェクトMの中で、オブジェクトAの改造を吸収してしまえば、オブジェクトB～Dの改造は不要です。これがMediatorパターンです。

　オブジェクト指向プログラミングの成功の秘訣として「できるだけオブジェクト間の関連を少なくする」ということがあります。Mediatorパターンを採用することで、オブジェクト間の関連の数を少なくできます。図1[拡大表示](1)では、6本の線がありましたが、図1[拡大表示](2)では4本になっています。新たなオブジェクトを追加する場合も、線が1本増えるだけで済みます。

　私は、Mediatorパターンを知って大いに感動しました。ただし、パターン自体に感動したわけではありません。GoFデザインパターンの中に、オブジェクト指向プログラミングを効果的に実践するヒントがあることに気付いて感動したのです。いずれは自分自身でオリジナルのパターンを考えるべきですが、その前に、お手本となるGoFデザインパターンを知っておきましょう。23種類のすべてのパターンがすぐに役立つとは限りませんが、その中のいくつかは、きっと皆さんのツボにはまって「ピピッ！」と感じさせてくれるはずです。

　この連載では、誠に僭越ながら私の独断で、GoFデザインパターンの評価をさせていただきます。★五つが満点です。わかりやすくて実用的なMediatorパターンは、もちろん★★★★★です。皆さんは、どう思われますか？

　次回は、AdapterパターンとIteratorパターンを紹介します。

矢沢久雄 グレープシティ株式会社(http://www.grapecity.com)アドバイザリースタッフ