やっと「そうめん」触ったよ(7) -実践篇 1.-
2008/11/01 11:16 - AS3.0
「そうめん」のスレッドの構造やオブジェクトの受け渡しについて、ザックリとではありますが確認を済ませたので、いよいよ実践に入りたいと思う。
wait() メソッドとか割り込みとかキャンセルとか、他にもいろいろ押さえとく必要ある項目があるような気もするけれど、今やってみたいことには出てこないっぽいので、ひとまずスルーしちゃうよ。
今回は、同じ挙動のプログラムを addEventListerner で実装した場合と、「そうめん」で実装した場合で、それぞれどのようなコードになるのか比較してみます。
プログラムの構成要素と挙動は以下のとおり。
まず構成要素。
- 外部テキストファイルを二つ用意（名前は 1.txt、2.txt）
- 外部画像ファイルを二つ用意（名前は 1.jpg、2.jpg）
- 1.txt には 1.jpg の url を、2.txt には 2.jpg の url を記述
FlashDevelop のプロジェクト構造はこのとおり。
そして挙動。
- 領域がクリックされるのを待つ、n=1
- n.txt を読み込む、n++、n>2 なら終了
- n.txt に記述された url のファイル（n.jpg）を読み込む
- n.jpg を表示する
- n++ で、1. に戻って繰り返し
以下はそれぞれのプロジェクトです。
プロジェクトからドキュメントクラスを抜き出して比較してみましょう。 話を簡単にするために、テキストロードとイメージロードでは COMPLETE イベントのみ扱っています。
「そうめん」を評して addEventLister を書かずに済んで楽になるというのを聞きます。 たしかに addEventLister を書くことはないんですが、event() メソッドというのは事実上 addEventLister。 そして event() メソッドを使用する局面はそれなりにあるんじゃないでしょうか。
ちなみに、そうめん実装の MainThread.as では step1() メソッドで以下のようなコードを書いています。
event(container.stage, MouseEvent.CLICK, step2);
event() メソッドを使用しない、もしくは隠蔽されているクラスを使うだけなら、その評価は適切だと思いますが、「addEventLister を書かずに済んで楽になる」というふうに addEventListener 側にスポットを当てるのは、ビミョーにズレているような気がしないでもない。
では「そうめん」は、端的に言って何が最も優れているのか？
私は「removeEventListener を一切書かずに済む」ことだと考えます。 つまり、後片付けを意識しないで済む、ってこと。 これは素晴らしい。
動いて欲しくないイベントの駆動も、イベントリスナー登録した swf が remove されたような場合に不要となったイベントリスナーだけがメモリに残り続けるということも、コーダーが意識することなくキッチリ殲滅できます。
もちろんそれらは removeEventListener をちゃんと書けば無問題なことですよ。
でも人間ってのは不完全な生き物なんです。 イベントリスナー使ったコードでは続きがあちこち飛ぶので、どこで removeEventListener 書けばいいのか立ち止まってしまうこともあるし、そもそも removeEventListener 自体を失念することだってある。
そういったヒューマンエラーに一切悩まされることなく、シーケンシャルな流れとしてプログラムを設計できる環境を提供しているからこそ「そうめん」サイコー！ ってことになるんではないでしょうか。
