Categories |
CPUの創りかた |
Modern Compiler Implementation in ML |
NerdTV |
PDP-11シミュレータで古代のUNIXを動かしてみる |
The Yakumo Project |
やさぐれ読書録
最近のツッコミ:1.CheapestOnlineUSpharmacy(2008-05-17 14:27)
2.Kir(2008-05-08 15:52)
3.Hero(2008-05-06 16:49)
最近のトラックバック:1.濃縮還元オレンジニュース:プロ.. (2006-12-22 22:02)
「将棋の定跡」と「デザインパターン」の関係というと、いかにもありふれたお話に聞こえるかもしれない。「両者はよく似ている。以上。」と言ってしまえば、その時点で終わってしまいかねないトピックだ。
だがあまりにもストレートな題材であるせいか、意外と取り上げられていないこと、また、最近モニ(・@・)殿下こと斎藤くんの「プログラムは将棋でありジャズである」という文章を改めて読み返したことが、この文章を書くきっかけとなっている。
以下は将棋に関する僕の失敗談とそこから得られた教訓である。もしも将棋とプログラミングが類似しているならば、このようなお話も少しは役に立つかも知れない、と思う次第である。
■ 将棋の定跡を使おうとして失敗したお話
今を去るはるか昔のこと。当時小学生だった僕は、同年代の他の子供と同様、将棋に興味を持つようになった。父親に買ってもらった入門書には、ゲームの目的（自分の王将を取られないように守り、相手の王将を取ること）、最初の駒の配置（王将を一番下の列の中心に置き、その両隣に金、その両隣に銀を置く、など）、それぞれの駒の動かし方（飛車は上下左右に何マスでも動ける、王将は全ての方向に一マスだけ動ける、など）のルールが書かれており、僕はその一つ一つを少しずつ覚えて行った。
その入門書の最後の方には、「定跡」と呼ばれる章があり、「矢倉囲い」とか「美濃囲い」といった、王将を守るための陣形や、ゲームの序盤の典型的な駒の動かし方が説明されていた。僕はこれを使えばきっと勝てるのだ、と信じて、父を相手に、入門書を横目で見ながら、その定跡のいくつかを忠実に再現しようと試みた。しかしどうしてもうまく行かない。入門書に書かれていた「矢倉囲い」の形を完成させる前に、父の駒は僕の陣地に攻め入り、王将はあっけなく取られてしまった。また、序盤の典型的な駒の動かし方を再現しようとしても、父がそこに書かれていない駒を動かした途端、僕はどうすればよいのか途方に暮れることになった。
結局それ以降、友人と何度か将棋で遊ぶことはあったものの、定跡を使うことは二度となかった。僕の将棋の実力はその時点で止まったままである。
■ 教訓
さて、僕が定跡を使おうとして、なぜ失敗したのかを考えて見た結果を、具体的な教訓としてまとめてみることにする。それぞれの教訓は密接に結びついており、もしかしたら相互に若干の重複があるかも知れないが、まずは以下のようになるであろう。
■ プログラミングとデザインパターンの視点から
ここで視点をプログラミングとデザインパターンの方向に移してみることにしよう。IEEE SoftwareのMarch/April 2003の号に、Martin Fowlerの"Patterns"という記事があるので、そこから関係しそうな部分を引用する（ちなみにこの文章は、martinfowler.comからも参照可能）。
まずはパターンの多用について：
考えられる問題点の一つとしては、パターンは無条件に良いものであり、パターンを多く使うほど品質の高いプログラムが作られると考える人が登場してしまうことが挙げられる。"hello world"を表示するだけのアプリケーションに、decoratorパターンを三つ、strategyパターンを二つ、そして山ほどのsingletonパターンを使ったとかいう怪談も、そういったところから生まれるわけだ。
パターンそのものは良いものでも悪いものでもない―どちらかといえば状況に合っているか合っていないかという観点で見るのが適切であろう。確信が持てないときに、あるパターンを試しに使ってみることは悪くないと思うが、もし十分な効果がないときには、それを捨てることをためらってはならない。
（以上やさぐれ訳。かなりの意訳なので注意）
次にパターンとその変化形について：
…実際にパターンが使われた事例を一つ一つ見ると、それぞれ少しずつ異なっていることが分かる。私はよく、パターンというのは「生焼け」なのだという言い方を使う―つまり、自分のおかれた状況にパターンを適合させ、自分で仕上げなければならないということだ。
（以上同じくやさぐれ訳。かなりの意訳なので注意）
プログラミングの場合には「勝つ」ための条件は将棋よりもはるかに複雑であるため、デザインパターンを使ってみて失敗しても、その失敗したという事実に気がつきにくいこと、また将棋よりも幅広い変化が発生するため、それに対応できる力量が要求されること、などの課題があるものと思う。しかしその類似点は予想していたよりも多いように思われるが、いかがだろうか。
3/31追記：「教訓」の冒頭および最後の方の文章を変更した。また、「プログラミングとデザインパターンの視点から」の項を追加した。
提示された教訓は、「定跡」を「デザインパターン」を置き換えればそのまま使えそうですね。
特に、目的は重要と思われます。
デザインパターンは、直面する設計要求と、拡張性／再利用性を保つことの両者をバランスを保って満たすことを目的としますが、
その辺りの誤解があるようです。
デザインパターンの背後にあるオブジェクト指向設計原則（OCPなど）を理解することが重要ですね。
コメントありがとうございます。
目的と手段の逆転というのは、思ったよりも厄介なお話なのかも知れません。呼び名や姿が印象的であるほど、そこに目が行ってしまう。
上記の文章には書きませんでしたが、将棋の「穴熊囲い」
http://contest.thinkquest.jp/tqj1999/20062/nomal1024/anaguma.htm
などは名前も姿も絶妙なメタファーで、勝負を度外視しても試してみたくなったことを思い出しました。
デザインパターンにおいては、効果的な名前のつけ方や、(OMTあるいはUMLの記法を使った)構造の図解が不可欠であると思うのですが、一歩間違うとその部分にのみ引き寄せられる可能性があるのが悩ましいところかと思います。
設計原則の話もあわせ、この件については引き続き考えたいところです。
ちなみに、上記の「その辺りの誤解があるようです」の一文なのですが、
「一般的にはそのあたりの誤解が…」
「『将棋の定跡と…』にはそのあたりの誤解が…」
のどちらの意味を指しているか、文脈だけでは判断しきれませんでした（スミマセン）。もしよろしければ教えていただければ幸いであります。
それでは。
あ、記述が曖昧ですみません。
「その辺りの誤解が・・・」は、デザインパターンについて「一般的にはそのあたりの誤解が…」の意味でした。
将棋はルールを知っているという程度ですので :-)
ところで、「印象的であるほど、そこに目が行ってしまう」というご指摘はなるほどと思いました。
UMLによる図解があるとそこばかりに目がいってしまい、
肝心の理由／目的に関する記述の読解をおろそかにしてしまうのかもしれません。