連載:熱血VBプログラマ応援団 |
|
Page1
Page2
|
− 今回のご相談 − |
||
|
デザイン・パターンはJava専用ではない
まず誤解を訂正しておきましょう。デザイン・パターンは、Javaのために生まれた技術ではありません。デザイン・パターンのバイブルともいうべき『オブジェクト指向における再利用のためのデザイン・パターン』という書籍がありますが、これに掲載されているサンプル・コードはJavaではなくC++で書かれています。そもそも、この書籍の最初の版は、1995年に出版されています。一方、Javaの最初の開発キットとなるJDKは1996年に公開されていますから、デザイン・パターンの歴史はJavaより古いといえます。またこの書籍では、SmalltalkやEiffelといったC++以外のプログラム言語への言及も見られ、決して特定プログラム言語専用の技術ではないことが分かります。
次に、デザイン・パターンは定石ではないのか、という疑問については、半分は正しいと思います。デザイン・パターンも、定石と同じくよく使われるプログラミングのパターンを意味します。デザイン・パターンは定石の一種である、という理解は(個人的には)間違っていないと思います。
しかし、デザイン・パターンと定石はイコールではありません。デザイン・パターンに含まれる定石には名前が付けられ、それらはカタログ化されています。厳密には正しくありませんが、このカタログこそがデザイン・パターンと呼ばれるものだと思っていて不都合はないでしょう。
つまり、同じ定石であっても、「私がいつも使っている定石」はデザイン・パターンではなく、「カタログに載っているパターン」がデザイン・パターンであるといえるわけです。
名前が付けられカタログ化された定石
では、どのような定石がカタログ化されているのでしょうか。誰も使ったことがないような新しい画期的な定石がズラリと並んでいる、というわけではありません。実際には、それまで何回も使用されてきて、有用性が実証済みのパターンが集められてカタログ化されています。そういう意味では、手あかの付いたよくあるパターンばかりが集められたものだといえます。
さて、手あかの付いたよくあるパターンばかり、ということは、カタログに載っているパターンをすでにそれと気付かないまま使っていたということもあり得ます。では、たまたま「私がいつも使っている定石」と同じパターンがカタログに載っていた場合、デザイン・パターンを使用していると胸を張っていえるでしょうか。答はノーです。
デザイン・パターンの重要な長所は、パターンに名前が付いているということです。名前が付いているということは、詳しく説明をしなくても、名前を告げるだけでどんなパターンを使おうとしているか、相手に伝達できるということです。例えば、「Factory Methodパターン」と名付けられたパターンを使う場合には、「ここはFactory Methodで行きましょう」と一言告げるだけで、詳細な設計意図を説明することなく話が通じるわけです。
では、自分たちの使っている定石に名前を付けてカタログ化すれば、それがデザイン・パターンであるといえるのでしょうか。それも少し違います。
現在、デザイン・パターンと呼ばれているものは、主に『オブジェクト指向における再利用のためのデザインパターン』に掲載されたカタログを意味します(これは、著者の4人がGang of Four、略して「GoF」と呼ばれていることから、「GoFのデザイン・パターン」とも呼ばれます)。つまり、デザイン・パターンは単なるカタログではなく、全世界のプログラマが共有しているたった1つのカタログなのです。そのため、見ず知らずのプログラマと仕事を行う場合、それがアメリカのプログラマだろうと、アジアのプログラマだろうと、ヨーロッパのプログラマだろうと、パターンの名前を告げるだけで即座に意図を伝えることができるわけです。
それゆえに、たまたま同じパターンを、名前を知らずに使っていたとしても、このような長所を甘受することはできず、デザイン・パターンを使っているとはいえないと思います。
さらに、デザイン・パターンは、整理、分類、分析などが行われていることにも注目する価値があります。どのパターンをどのような状況で使えばよいか、パターンとパターンとはどのように連携するのか、といったノウハウも蓄積されています。
実例を通して見るデザイン・パターン
理屈はさておき、具体的にどのようなものがデザイン・パターンであるか、実例を1つ見てみましょう。すでに名前が出たFactory Methodパターンを取り上げてみたいと思います。これは、「オブジェクトを生成するときのインターフェイスだけを規定して、実際にどのクラスをインスタンス化するかはサブクラスが決めるようにする」というものです。
まず、こんなプログラムを作成してみましょう。プログラムが起動された日によって、異なるフォームを表示するプログラムです。例えば、平日と休日では、提供するメニューの内容が異なるようなシステムを想定しています。そして、元旦などの特別な日には、その日だけの特別なフォームを表示したいという要求もあるとします。特別な日は、後から追加が行われる予定があり、何種類のフォームが使われるかは事前に予測できないとします。
取りあえず、いまは、以下の3種類のフォームがすでにあるものとします。フォームの内容は、サンプルですので、意味のある内容ではありません。「こんなプログラムはあり得ない!」と突っ込みながら気楽に見てください。
平日用フォーム(FormNormal) |
休日用フォーム(FormHoliday) |
元旦用フォーム(FormShogatsu) |
まずは、ごく普通にFactory Methodパターンを使用せずに、こんな風に書いてみました。
|
|
今日の日付によって異なるフォームを表示するShowFormメソッド |
今日の日付を基に、作成するフォームを場合分けしています。月(today.Month)が1で、日(today.Day)も1ならば正月用のフォームをNewによって作成します。曜日(today.DayOfWeek)が日曜日(DayOfWeek.Sunday)なら、休日用のフォームを作成します。そのほかの場合には、平日用のフォームを作成します。実に単純明快です。
さて、単純明快であることは悪いことではありませんが、このプログラムには問題もあります。フォームの種類が増えると、このプログラムを書き換える必要が発生するわけです。それは当たり前のことのように思われますが、これが巨大な業務用システムの一部だとすると、フォームの種類が増えるごとにシステム全体をビルドし直すような行為はできれば避けたいものです。現在稼働しているものには、できるだけ手を触れたくはありません。
では、このShowFormメソッドだけを独立したクラス・ライブラリとして作成しておき、フォームが増えた場合は、それだけを再ビルドして差し替える方法はどうでしょうか。それも、現実的には好ましい方法ではありません。このメソッドには、フォームを作成する以外の機能も含まれているからです。このサンプル・コードでは、form1.ShowDialog(Me)がそれに当たる部分ですが、実用プログラムなら、何十行もそれに当たるコードが存在することになるでしょう。それらが、頻繁に書き換えられる部分と同居していると、誤って書き換えられてしまう可能性があります。
このような問題に対処する方法はいくつか考えられますが、Factory Methodパターンは、その1つとなります。続いては、このプログラムにFactory Methodパターンを適用してみましょう。
INDEX | ||
[連載]熱血VBプログラマ応援団 | ||
第12回 はやりのデザイン・パターンをVBで | ||
1.デザイン・パターンって何? | ||
2.デザイン・パターンを実際に使ってみよう | ||
「熱血VBプログラマ応援団」 |
- 第2回 簡潔なコーディングのために (2017/7/26)
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために (2017/7/19)
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator (2017/7/18)
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
|
|
- - PR -