《こちらに移動中です》2008-11-30
C#.use(better, IronPython=”WPF”) 《記事一覧》
アプリケーションギャラリー
《著》小粒ちゃん《監修》小泉ひよ子とタマゴ倶楽部
一覧
ここで紹介するプログラムは、ちょうど20年前（1988年）に Smalltalk-80 で作成したものを、Swing/Jython 版を経て、今回は WPF/IronPython 版として再構成したものです。当時の Smalltalk はまだカラー対応しておらず、グレースケール（ビットマップ）で表現したものでした。やはり、カラーが使えると見栄えがいいですね。しかし、本質的な部分は、20年前と少しも変わりません。ということは、私も進歩していない…ということでしょうか。(^.^);《ひよ子》
| sample | note |
|---|---|
 |
● Brickles 「ブロック崩し」の愛称でも親しまれています。後に、その発展形である Arkanoid の登場によりブームが再燃しますが、私はお友達のプレーを呆気にとられながら隣で見ているだけでした。加えて「トリビアの泉」で、大山のぶ代さんが（Arkanoid に出会ったのも奇しくも同じ 1988年だったと言うことです）披露されたその腕前は、ドラえもんも吃驚の圧巻でしたね。(@o@) そんなこともあってか、ゲームは自分でプレーするよりも、自分で作るものだと悟りました。ですから、自分が作ったゲームをお友達にプレーしてもらうことはあっても、自分でプレーすることは（プログラミング中を除いて）ほとんどないのです。 |
 |
● Tetris/Тетрис オリジナルと比べて、テトリミノは10種類に増えています。オリジナルのT型は、p型（magenta）とb型（purple）とに分かれ、新たにC型（brown）とY型（gray）を追加しました。テトリミノの色は、http://www.nintendo.co.jp/ngc/software/gtrj/index.html で採用されたガイドラインに準拠しています。テトリミノの形が変化するとともに種類が増えたことで、オリジナルと比べて「さらに右脳を活性化する」効果が期待できます。余談ですが「テトリス」を直訳すると「４つの石」になります。『2001年宇宙の旅』に登場するモノリスは、英語式に直訳する「monolith=ひとつの岩」となり、相対論で著名なアインシュタイン博士の名前も、独語式に直訳すると「Einstein=ひとつの石」ですね。 |
| ☆ now or soon ☆ | ● Lifegame/amorphous 「ライフゲーム」の不定形版です。 第7章 ライフゲーム（amorphous/torus surface）1/15, IronPython - 続・ひよ子のきもち |
 |
● Othello/trinity 「オセロゲーム」の３人対戦版です。切っ掛けは、幼い頃に遊んだ「ダイヤモンドゲーム」でした。オセロゲームは２人が対峙するゲームなので、３人目は傍観するしかありません。そこで「３人でも遊べないか」という思いから、オセロゲーム（trinity）作りに着手したものです。そのルールは（３人で対戦することを除いて）オリジナルの「オセロゲーム」と同様です。３人目を何色にするかは（運動会などでお馴染みの）紅白の源平合戦に倣って「紅」を採用しました。 |
学習の指針
この課題では、ゲームを作成するのは「目的」ではなく、実際のアプリケーション開発を疑似体験するための「手段」です。この課題を達成しても、ゲーム作成のノウハウは習得できませんので、ここで得られたゲームはご褒美のひとつと考えてください。ゲームの「ルール」は、実際のアプリケーション開発における「要求仕様」に相当します。要求仕様（ルール）の変更に伴って、既存のリソースをどこまで再利用できるかが鍵となります。設計に際しては「プログラム」の効率を犠牲にしても「プログラミング」の効率を優先させることに主眼を置いています。
ゲームの規則を要求仕様に見立て、アプリケーション開発の問題点を指摘しながら、アジャイル開発への扉を開きます。要求仕様の変更に伴って、既存のリソースには手を加えず、コードを追加するだけで対処する（OCL: 開放閉鎖原則）のを理想とします。すでに、Swing/Jython 版のコードがあるので、このリソースを再利用します。今回は、WPF アプリケーションとして作成します。
すでに読者のみなさんが同様のゲームを作成してあるなら、今回の仕様変更に対しても「柔軟に対処できるかどうか」で再評価してみてください。些細な仕様変更にも柔軟に対処できない原因は何でしょうか。そのプログラミング言語に満足していますか。その開発環境に満足していますか。そうでなければ、新たなプログラミング言語/開発環境に乗り換える、今がその好機かもしれませんね。「プロダクト指向」から「プロセス指向」への扉を開く鍵は、こんな所にも落ちています。(^o^)
アジャイル開発に向けて
プログラムが完成したら、それは終わりではなく始まりの合図です。そのプログラムが有用で使い心地が良ければ、避けられないのが要求仕様の変更です。それは、利用者がそのプログラムをより快適に「使い続けたい」ということの証ですから、プログラマー冥利に尽きます。ですから、私は、要求仕様の変更があると「ワクワクして」心が弾みます。
しかし、要求仕様の変更があると憂鬱なプログラマーというのも珍しくありません。オブジェクト指向プログラミングの醍醐味のひとつは、要求仕様の変更にも「柔軟かつ迅速に対処できる」ことです。それには、アジャイル開発に適した、プログラミング言語や開発環境などの整備が不可欠になります。今使っているプログラミング言語や開発環境は、要求仕様の変更にもうまく対処できていますか。要求仕様の変更と作成済のプログラムとを照らし合わせてみてください。そこに、みなさんが求めている答えがきっとあるはずです。
今回の要求仕様の変更で、その脆弱さが露呈したなら、今使っているプログラミング言語（Java/C# など）や開発環境（Eclipse/VisualStudio など）を疑ってみてください。そして、プログラムの洗練された姿を絶えず追求してください。
