ドロー系お絵書きツールの簡易版です。 「図形」と「操作」がそれぞれ MJ の module で記述されており、 新たな図形、新たな操作を追加可能になっています。
下記のモジュールが選択可能です。
全モジュールを選択した場合。
base と select 以外の９個のモジュールは任意に選択可能で、
それに { base, select } という組み合せを加えると
全部で 2^9 + 1 通りのモジュールの組み合せ方があります。
このうち、下記の組み合せをアプレットでお試しください。
（Netscape では最初に実行したアプレットがキャッシュされてしまうようです。
その場合は Netscape を立ち上げ直してください。）
補完モジュールは、{dump, area} × {line, rect, elli, tri, oct} ＝ １０個定義されています。 dump, area はそれぞれ、全ての図形のスーパークラスである DrawObject に abstract method を追加しています。 補完モジュールは、個々の図形であるサブクラス側で、 この method の実装を行うモジュールです。
select, delete, move と各図形の間には、補完モジュールは不要です。 これらの機能はスーパークラス DrawObject に対する 操作だけで実装されており、サブクラス側でメソッドを実装する必要がないからです。
この例で面白いのは、 delete と area の組み合せです。 図形を delete すると面積の合計は減ると普通期待しますが、 この実装では変化せず、次に画面をクリックしたときに正しい値に更新されます。 モジュール area の実装が、 mouseReleased の直後にだけ 値を更新するようになっているからです。 モジュール area の仕様が「 mouseReleased の直後に値を更新する」であるならば、 この delete と area の組み合せは、全く正しい動作であることになります。
では、モジュール area の仕様を「図形に対する操作を行った直後に面積を更新する」 としたい場合はどう実装すればいいのでしょう？ この仕様を厳密に満たす実装を行うためには、 「図形に対するすべての操作」の直後に必ず呼ばれる hook が、 あらかじめフレームワーク側で用意されている必要があります。 このような hook がなければ、実装は不可能です。
iアプリおよびアプレットとして動作する、簡単なデモプログラムです。 上下左右のキーで、コーヒーカップが動きます。 iアプリ版は、 P503i, F503i, So503i で動作確認ずみです。
プログラムは、５つの module からなります。
multi, vapor, time を選択するかしないかで
2^3 = 8 通りの組み合わせが可能ですが、下記の組み合せがアプレットとして
用意されてます。
（Netscape では最初に実行したアプレットがキャッシュされてしまうようです。
その場合は Netscape を立ち上げ直してください。）
iアプリで試してみたい方は、こちらの URL でダウンロードしてください。
http://staff.aist.go.jp/y-ichisugi/mj/demo/i/index.html
MJ の用途として、メモリの制約が厳しい携帯情報端末上の開発言語が 適しているのではないかと思い、 iアプリを試してみましたが、 プログラムサイズ 10KB の制約は厳しすぎ、実用的アプリケーションの開発は 断念しました。
今の MJ の実装では、クラスを複数のモジュールに分割すると、 その分 jar ファイル中のクラスの数が増えます。 すると、主にクラスファイル中の constant pool のせいで、 jar ファイルが大きくなってしまいます。 コーヒーカップのような単純なプログラムでも、 module を５つ作るのがサイズ的に限界だったそうです。
極端にメモリ制約が厳しい実行環境で MJ を使うためには、 HP の ChaiFreezeDry のような、 クラスファイル圧縮技術が必須なようです。
|
Last updated:
May 14 19:07:35 2003
[MJ Top page]
[Site map]
|