[#29] 改めてビューについて考えてみる - これまでのビューとCocoaのビュー

初出: MacPower 2002年 12月号

今回は、Mac OS X v10.2（以下、Jaguar）で導入された「HIView」について語ることにしよう。HIView はOS内部にも影響する大々的な改造で、開発者も待ちわびていた機能だ。しかし、ユーザーが目にする効果としては比較的地味なために、注目を浴びることが少ないようだ。しかしこのHIViewの登場で、Carbonの開発環境は大きく変わることになる。ひいてはJaguar環境の操作性の統一感にも影響する。HIViewは、それだけ大事な機能なのだ。そのHIViewについて考えるにあたって、まずはビューというものについて腰を据えて考えてみよう。

そもそもビューという用語は一般的なんだろうか？われわれ開発者にとっては当たり前の機能だが、普通のユーザーは直接意識する必要がないものなので、なかなか正しく理解するのは難しいようである。

簡単にいえば、ビューとは画面の設計図だ。画面とはこの場合ウィンドウと思ってもらって構わない。｢このボタンはここ。それはあそこ。あ、そのチェックボックスは真ん中ね」みたいな感じで、ウィンドウの中にバーツをどのように配置したらいいかを記述したものがビューだ。Mac OS Xの標準開発ツールに含まれる「Interface Builder」を見たことがある人なら、このイメージはすぐ伝わると思う。懐かしの「ResEdit」でダイアログのリソースを見たことがある人も多いだろう。あれもビューの一種だ。開発環境の「REALbasic」やWindowsの「Visual Basic」なんかも、同じような感じでウィンドウを作る。これらの例からわかるとおり、近年のプログラム開発環境には、必ずといっていいほどビジュアルな画面設計ツールが付属しているのだ。その中核をなす設計図がビューなのである。

さて、一般に理解できるビューはこんな感じだと思うが、これはビューの一面にすぎない。アプリケーションの実行時にはシステムがこのビューから実際のウィンドウ（画面）を作るわけだが、このままでは張り子の虎だ。仏作って魂入れず。ボタンをクリックしても、何か機能するわけではない。何かをさせるためには、何をしたらいいかを教えてあげなければいけない。例えば、ユーザーがボタンをクリックしたらビープ音を鳴らすという簡単な処理でも、ビュー設計ツールではそこまでの面倒は見てくれない。

何をさせるかを記述するのはプログラムの役目だ。ようやくわれわれプログラマーの出番。ここで、設計図に書かれたパーツとプログラムの間の橋渡しをするのも、ビュ一の大事な役割だ。プログラム側から見たときに区別できるよう、ボタンにわかりやすい名前を付けたり、ボタンが押されたときの合図を決めたりする。ビューはまた、設計図に対する細かな指示書のようなものなのだ。それに基づいて、「このボタンが押されたらSysBeep()というAPIを呼べ」という記述を、CやC++ BASIC, AppleScriptなどといったプログラミング言語で記述していく。

余談だが、ビジュアルなプログラミング環境のうわさを耳にしてトライしてみたはいいが、最初のウィンドウを出したあと何をしていいかわからなくなった、という話をよく聞く。それは残念ながら、「ビジュアルな環境でいろいろできます！」という甘いセールストークを信じた結果だ。そりゃいろいろなことが可能だけど、用意されたことしかできないのである。コードは必ず書かないといけない。これから始められる方は、それだけは覚悟しておいてほしい[*1]。

さて、設計図と指示書という2つの役割がビューの本質だが、Cocoaのような最近のビュー [*2] にはそれ以外にもオブジェクト指向における重要な機能が追加されている。「誰に何を伝えるか？」ということである。

昔ながらのビューでは、「ボタンが押されたら何をしたらいいか？」や「誰が反応したらいいのか？」を決めるには、すべてプログラマーがプログラミングしてあげなければいけなかった。ボタンからすれば「僕、3番のボタン。いまクリックされたよ。クリックされたんだよー」と大声で叫ぶだけで、「あとは知らん、誰かが何とかしてくれるだろう」という感じだったのだ。ウィンドウが処理するのかアプリケーションが処理するのか、別の何かが処理するのか。それは、プログラムを見てみないとまったくわからないことだった。ここに、ビュー設計ツールとプログラミング環境の断絶があったわけだ。

しかし、Cocoaのビュー設計ツールであるInterface Builderでは、誰に何を伝えるかを指定できるようになっているのである。しかも、マウスでパーツを結んでやるという非常に直感的な操作で指示が行える。例えばボタンからウィンドウに線を引く。そしてその線に「閉じる」という意味を付けてあげる。それだけで実行時には、ボタンが押されたらウィンドウに対して閉じるという動作が行われるのである。オブジェクト指向の大事な側面である「メッセージの伝達」を、これほど鮮やかに表現して見せた例はInterface Builderが初めてだと思う。

もちろんこうした指示も、そのパーツがもともと用意している機能にしか使えないのなら、あまり意味がない。しかしInterfaceBuilderでは、簡単に指示を増やすことができる。例えば標準のウィンドウが持っていない機能を実行させたいときは、その機能を持った指示をプログラムで書いて、InterfaceBuilderに伝えればいい。するとウィンドウは、その新しい指示を受け付けるようになる。ビューの設計とプログラミングを双方向で拡張していけるのである。これなら、ソフトの開発が進んだ段階でも、ビューを見るだけで機能がある程度わかる。オブジェクトの詳細を隠すというオブジェクト指向の別の側面「機能の隠蔽」が正しく働いているのだ。

前振りが長くなり、HIViewの説明にたどり着けなかった。来月はこうしたビューの現状を踏まえて、HIViewの機能とCarbonの将来について勝手に考えてみたいと思う。

バスケ（basuke@mac.com）
先月はお休みしてしまってすみませんでした。実は自転車で転んで鼻の骨を折っちゃって、結構大変な目に遭っていたのです。ケガは気力もなえさせます。とりあえず、ケガは完治しました。またバリバリ頑張りましょう。おー。

[*1] それだけは覚悟しておいてほしい - そうじゃなきゃ面白くないだろうとも思う（笑）。
[*2] Cocoaのような最近のビュー - Cocoaは10年以上前に生まれたNEXTSTEPとほぼ同じものなので、最近というのも変な話だ。それだけNEXTSTEPが時代の先を行っていたということだろう。

編集･三村晋一