2007-05-12 なぜnavigateToURL(new URLRequest())は煩雑か
■AS3は簡単なことでも複雑な組み合わせを要求されて面倒だ問題について

AS3 は FLASHer には使いにくい? - てっく煮ブログ によると「AS3めんどい」という話があるらしい。いちばん気になったのはこれだ。
getURL( "移動先URL" ) が navigateToURL( new URLRequest( "移動先URL" ) ) になったように、1 つのことをする為に 2 以上のクラスを組み合わせる必要があったりしてめんどい。
http://blog.nium.jp/flash/actionscript3/_flasher_as30.php
これが「めんどう」だという感覚はオイラには無いものだけど、どうやらFlash畑の人たちにはこの感覚は普通に受け入れられているようだ。せっかく違う立場にいるのでこっちの立場からなぜめんどいのか考えてみたい。
まず最初に問題領域を狭めておくと、この「getURL() 対 navigateToURL(new URLRequest())問題」は、プログラミング言語ActionScript3の話ではなく、ライブラリ(コアAPI) の話だってことだ。
APIの設計をするときどういう考え方に基づいて設計するかというと、最小インターフェースとヒューメイン・インターフェースというのがある。
クライアントが必要な機能をすべて提供できるようAPIを設計するが、仕事を成し遂げるための必要最小限のメソッドしか提供しないというものである
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?MinimalInterface
ヒューメイン・インタフェースの肝は、みんなが何をやりたいかを見つけ出し、何度も起きることを簡単に行えるためのインタフェースを設計することだ。
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?HumaneInterface
これに件のAPIを当てはめてみると、getURL()はヒューメイン・インターフェースで、 navigateToURL(new URLRequest())は最小インターフェースだ。最小のほうが複雑なのは普通の感覚と違うかもしれないけど、APIの粒度が小さいので、一つのことでも複数の組み合わせでやっているわけ。一つの問題をより小さい複数の問題に分割して解決しているわけだ。いわゆる分割統治というやつだ。
この二種類のAPI設計は、どっちがよいとか悪いとかいう話ではなく、単に考え方が異なる、というだけだ。ヒューメイン・インターフェースの考えかたにもとづくと、getURL()が良くて、最小インターフェースの考え方にもとづくと、navigateURL(new URLRequest())が良い。
さてFlash畑の人たちがなぜ最小インターフェースにネガティブな反応を示すのかというと、ここからは推測だけど、彼らはインターフェースは(APIも含めて)ヒューメイン・インターフェースであるべきだと考えているのではないか。そうならば、既に持っているメンタルモデルと異なる考え方を示されたときになんでこんなめんどうなことを!と思うのはなんとなく納得できる。
思うに、Flashの人たちはエンドユーザ相手に仕事をしてきている。ユーザーインターフェースの層では「みんなが何をやりたいかを見つけ出し、何度も起きることを簡単に行えるためのインタフェースを設計する」のでこれはまさにヒューメイン・インターフェースなわけだ。だからそれがそのままAPIの層に降りてきているのは自然なことだと思う。
振り返って自分のことを考えてみると、オイラはJava畑の人なので最小インターフェースに慣れていて、しかも単体テストに毒されているので小さい粒度でクラスを設計しがちだ。もし自分がAS3のコアAPIを設計してたら、へたすると
navigateToURL(new URLRequest(new URL("移動先URL")));
くらいは平気でしてたかもしれない。これに対する嫌悪というのが少なからず有るというのを知ることができたのはよかった。
あと「いちいちimport宣言しなくちゃいけない」や「いちいち変数の型を宣言しなきゃいけない」なんてのはAPIの話ではなく言語の話だと思うので、これについてもまた後日考えてみたい。






navigateURLに変えてもユーザーやクライアント的にはなんの意味もないので、
その分の労力を可能なかぎりアウトプット部分につぎ込みたいという感じなんじゃないかと。
ただ時間がたっぷりある理想的な状況で何をするかを考えると、時間が無いときにどうするかのヒントになるかもしれません。
上の fladdict の人の科白にある、“ユーザーやクライアント的にはなんの意味もない” ってのはコーディングの質を気にしない、ってことで、そこは Designer なのか Artist なのかの違いがはっきり別れる所だし、自分が Artist ならそれでいいと思うけど、まぁそっちで生きて行くのは僕は無理だって思う。Processing のポジションを見ればそういう要求があるのはわかるけど、Adobe/Macromedia の描く将来像には、もっと産業化されたインタラクティヴ製作環境があるってことじゃないかな。
政治的にはここで Flash からこぼれそうな人達を、Microsoft が拾おうとしてるのが非常に興味深いですが。
おそらく、AS2とAS3の間にあるのはターゲットの変更なのではないでしょうか?
例えば今までのFlash(AS2)はどちらかと言うと、プログラマーよりと言うより、デザイナー向けの設計がなされていたような気がします。
ヒューマンインターフェイスは直感的には機能が分かりやすいですし、OSの基本操作(GUI)にも良く似ています。
一方でActionScript3はFlex2にも代表されるように開発者向け(主にプログラマー)になって、CUI寄りの機能に感じがしました。
よって、デザイナーよりの人たちの多いFlashでは、より直感的の方が好まれるのではと思います。
まあ、個人的には、最小インターフェイスの方が好みです。
ヒューマンインターフェイス系のプログラミング言語は、どうもプロパティやメソッド、関数が覚え難くい印象があります。