この二日ばかりMVC構造を用いてプログラム全体を作り変えることを考えていた。まあ、いままでMVC構造を度外視して、ここまでプログラムを組み上げていたというのも、むちゃな話だが。
とりあえず、アプレットと普通のアプリケーションは、簡単に組み分けられるような構造にしなければならない。
アプリケーション版の描画部分にはswingを使う。アプレット版は、なるべく色々なブラウザで動作できたほうがいい。ゆえにswingは使わない予定である。そのためには描画機構と実体とをわけなければならない。そして、なおかつ実体部分のクラスには手を加えることなく、描画機構のクラスなどをとり変えるだけで簡単に二種類のプログラムをコンパイルできる構成でなければならない。
そのためには、一種類のイベントクラスと、二種類のリスナを用意することになるだろうか。
二種類のリスナとは、もちろんアプリケーション用のリスナとアプレット用のリスナである。ただ描画機構に密接に関与しないリスナのなかには、一種類だけの物もあるだろう。
たとえば軍隊や兵士などのクリエイチャーユニットである。
彼らのデータに変化があったら登録されているリスナにイベントを送る。
このリスナには二種類ある。二種類といっても、それは前述のようなアプレット用リスナ・アプリケーションリスナという区分けではない。そのひとつはBoard上に配置された全クリエイチャーのイベントを処理するリスナインスタンス。おそらくこのリスナインスタンスはBoardクラスにリスナインターフェイスを実装させたものになるのではないかと思う。
ふたつめは、クリエイチャー単体と一対一でむすびついたリスナインスタンス。たとえば軍隊の詳細情報を表示するコンポーネントが、このリスナインターフェイスを実装することになるだろう。
なお、ひとつめのリスナインスタンスは、クリエイチャーからイベントを受け取ると、さらにもういちど別のインスタンスにイベントを送る。
おそらく、そのイベントを受け取るリスナインターフェイスは、行軍マップを表示するコンポーネントが実装することになるだろう。
なぜ、このような二段階のイベント発送をおこなうかといえば、それは行軍マップが動的に生成されたり廃棄されたりするインスタンスだからである。
もし二段階発送の仕組みをとらなければ、どうなるであろうか。行軍マップは複数のクリエイチャーユニットからのイベントを直接うけとらなければならなくなるだろう。そのためには、それらすべてのクリエイチャーユニットに、自身をイベントの発送先として登録しておかなければならない。そしてこの行軍マップが新たに生成されたときにも、またもういちど、その新たな行軍マップを、すべてのクリエイチャーにイベントの発送先として登録しなければならない。また行軍マップを廃棄するときには、すべてのクリエイチャーユニットのイベント発送先リストから、その登録されていた行軍マップを削除しなければならない。これは大変な手間である。
ゆえにクリエイチャーと行軍マップのあいだに静的なひとつのリスナインスタンスを置くことで、この問題を解決しようというわけである。
Java スタンダードエディションの1.4が正式にリリースされたので、さっそくDLしてみました。1.3の時とくらべてswingなどが高速化されているように感じました。具体的にはJTable内の列の並べ替えなど。まあ実際に比較してみたわけじゃないですけれど。
Java[tm] 2 Platform, Standard Edition v 1.4(日本語)
Java[tm] 2 Platform, Standard Edition v 1.4(英語)
きょうは、とりあえずUnitEventなるクラスを書いてみました。このクラスはユニットに変化があったことをUnitListenerに通知するためのクラスです。
きょうはUnitListenerクラスをつくってみました。だいたいの設計は固まったので、この2,3日中には描画機構をMVC的なものに作り変えたいものです。