RealBasic University

このコラムはStone Table Softwareのオーナーであり、またREALbasic Developerの編集者でもあるMarc Zeedar氏により書かれたものを、著者の許可を得て翻訳したものです。この翻訳はHREM Researchにより提供されています。この日本語版へのご意見はRBU-Jまでご連絡下さい。

URL: http://www.applelinks.com/rbu/078/
INDEXに戻る

OOP University:パート 2

前回のレッスンで、我々は"モーダル"プログラミングについて学びました。今回は、その反対であるイベント駆動プログラミングについて学習しましょう。

イベント駆動プログラミング

イベント駆動プログラミングは、ユーザ駆動プログラミングとしても知られています。大抵のイベント(すべてではありませんが)は、ユーザによって引き起こされるので、それはもっともな用語です。マウスを動かしたり、マウスのボタンをクリックしたり、CDを挿入したり、ケーブルを引き抜いたりといったことをユーザは行います。特にMacintoshは、発表当時は"ユーザのためのコンピュータ"として知られました。それは、常にユーザに主導権があるからです。他のOSのユーザをいらいらさせる評判の悪い"モード"は、Macintoshでは(通常)排除されました。

技術的には、Macintosh(特に初期のMac)はモードを排除しませんでしたが、より多くの可能性を含めるため、それを拡張しました。

詳細

このモード排除の進化は、現在のMac OS Xでも続いています。例えば、Mac OS Xはシートを導入しました。――それは文書ウィンドウに付随するダイアログです。シートの導入により、"保存しますか?"のダイアログをそのまま残しておきながら、ユーザは他の文書(あるいはプログラム)に切り替えて、作業を続けることができます。昔のMac OSでは、ダイアログを片付けてしまうまでは、他の作業に移れませんでした。すなわち、モードだったのです。

例えば、前回のレッスンであったDOSワープロのオープニング・メニュー・モードを覚えているでしょうか?Macでは、文書を直接開くためにFinder内のドキュメント・ファイルをユーザがダブルクリックすることができました。その方法は、このオープニング・メニュー・モードの形式には合っていませんね。

Macでは、ユーザはアプリを直接立ち上げたり、ディスクトップから印刷、あるいは文書を開いたり、プログラムのアイコンにファイルをドロップしたり、複数のファイルのアイコンを選択して一度に開くこもできます!

すると、この小さなオープニング・メニュー・モードはとても限定されたものしか見ていません。同時に、そのルーチンのコードは、我々はすべての可能性について目を見張っていなければならないので、突然、巨大なものになってしまいます。ファイルは1つなのか、あるいは複数なのか?ユーザはファイルを開くのか、あるいはそれを印刷するのか?

編集モードになると、問題はさらに難しくなります。DOSでは、編集モードではただキー入力(キーボード入力)を扱い、コントロール・キーのコマンドを監視しなければならないだけでした。ここで、Macのプログラムで起こり得るいくつかの可能性について見て見ましょう:

Mac "編集モード"イベント:
  - マウスの移動
    - カーソルはメニュー/ウィンドウ上とテキスト上で変化する必要あり
    - カーソルは修飾(オプション等)キーが押されたとき、変化する必要があるでしょう
  - マウスクリック
    - ウィンドウ上をクリックしたか(タイトルバー、クローズ・ボックス、拡大ボックス等)?
    - 別のウィンドウをクリックしたか?
    - メニューバーをクリックしたか?
    - デスクトップをクリックしたか?
    - 別のアプリケーションのウィンドウをクリックしたか?
    - テキスト編集領域をクリックしたか?
      - 選択されたテキストをクリックしたか?
        - それはテキスト・ドラッグの始まりか?
      - それは多重クリックで、現在の単語あるいはパラグラフの選択が必要か?
      - テキスト選択を拡張するためにShiftキーが押されているか?
    - 他のボタン/コントロールがクリックされたか?(ラジオボタン、
	チェックボックス、リストボックス、プッシュボタン、文字入力欄等)
  - コマンドキー・ダウン
    - メニューバーのコマンドと入力されたキーが一致するか?
  - コントロールキー入力
    - コンテキストメニューを表示する必要があるか?ある場合は、どれを?
  - 入力キー
    - 入力の扱い(テキストの選択があれば削除する)
    - 矢印キー移動の扱い
    - Shiftキーによるテキストの選択拡張の扱い

ふうっ!ご覧のとおり、Macのユーザ駆動環境は、単純な線形プログラミング法よりも扱いがさらに複雑です。上記のものは、標準的なMacの動作リストの一部です。あなたが独自の機能を追加したい場合(例えば略語での入力補助をする用語集機能)は、監視しなければならない状態がさらに増えることになります。

しかし、さらに多くのことが生じる可能性もあるにせよ、上記の動作のほとんどは標準的なものです。例えば、プログラムAでユーザがプッシュボタンをクリックしたとすると、押されたボタンの処理過程は、プログラムBやC、あるいはDでプッシュボタンが押されたのと同じです。実際にボタンが押された後に起こる処理は、もちろんプログラムによって変わってきます。しかし、ボタンそれ自身の振る舞い――その外見と、ユーザにフィードバックを返すため、押されたことを視覚的に訴える方法――はすべてのプログラムに共通します。

さて、すべてのプログラマーが彼らの書くすべてのプログラムに、共通のボタンクリック・コードを書かなければならないとしたら、人生はこの上なくむなしいものになってしまうでしょう。すべてのプログラムの8割は、以前に何十回も書いたものの書き換えになってしまいます!

さらに悪いことには、何人かの変わり者が、公開されている標準仕様に従わない(怠け、やり過ぎ、またはただの能力不足から)で、彼らのプログラムのボタンは標準と違うかもしれません。例えばAppleは、プッシュボタンは丸い角を持つように決めました。ある人は角を過度に丸くするかも知れないし、またある人は四角を使うかも知れません。また他の誰かは、丸形のボタンを作るかもしれません!この結果、ユーザにとってどれが標準のプッシュボタンかはっきりと分からなくなります。

私が述べていることは、1980年代初頭の状況です。MS-DOSはプログラマーにわずかなツールしか与えなかったので、総てのプログラマーは標準のユーザ・インターフェースのために自分自身のルーチンを作成しなければなりませんでした。もちろん、当時の"インターフェース"は、そのほとんどがコントロール・コマンドとファンクション・キーから構成されていました。しかし、10種のワープロを見ると、それはそれぞれ独自のコマンド設定を使用していました。WordPerfectでどのように文書を保存するかを学んでも、XYWriteではどう保存すればよいか判りませんでした。(これを現在と比較してみましょう:Macのワープロはそれぞれ独自の機能や特徴があるにもかかわらず、共通した方法で印刷や文書の保存が可能です。)

Appleは、プログラマーが独自性を打ち出し、あらゆるプログラムが独自の基準を持つことを目の当たりにしてきました。Macintoshで(技術的には、これはXerox PARCとApple Lisaから始まりました)、Appleはグラフィカル・オペレーティング・システムを持たせようとしました。このようなOSでは、使用環境の視覚的な標準規格は非常に重要です。 それに一貫性を持たせないと、ユーザが混乱してしまうでしょう。それはまた、プログラマーにとっては導入が簡単であり、導入に際して誰も戸惑うことがあってはなりません。

プッシュボタンのようなグラフィックを作成することは、プログラマーにとってさらに複雑になります。プログラマーは基本の形を描き、テキストを加え、マウスがクリックされたボタンが押される複雑な変化を扱わなければなりません。それからボタンはすぐに元に戻らなければなりません!

モードでの動作環境に慣れている従来のプログラマーのように考えると、これはどのように記述すれば良いでしょうか?

それは、おそらく次のようなものになるでしょう。ユーザはマウスボタンをクリックします。我々はそれを察知します。だから我々にはマウスがクリックされた状態を扱うルーチンが必要でしょう。それは次のようなルーチンです:

procedure mouse_clicked;

var k: char;

begin {mouse_clicked}

  {マウスカーソルはボタンの内側か?}
  if mouseX >= button_left and mouseX <= button_right then
    if mouseY >= button_top and mouseY <= button_bot then
       {ユーザがプッシュボタンをクリックしました!}
       do_button_animate;
    end if;
  end if;

  {ここで、他のマウス・クリックを扱います}

end; {mouse_clicked}

もちろん、これはただひとつのプッシュボタンを扱うだけです!実際には、大抵のプログラムにはたくさんのボタンがあります――これはループとして書き直し、クリックされたボタンが見つかるか、あるいはユーザがどこをクリックしたかを認知するまで、すべてのボタンについてマウスの座標をチェックする必要があるでしょう。

なんて複雑なんでしょう。しかも我々はまだ描画(アニメーション)の部分を終えていません。これらすべてを、標準の統一的な方法で扱えるようにできたら、どれほど素晴らしいことでしょうか?

そうです。それがAppleの行ったことです。Macintoshは、このようなものを扱うために、前もって記述されたあらゆる種類のルーチンを備えていました。それがOSの所以です。つまりウィンドウやプッシュボタンを描画したりする何千というOSコールが含まれているのです。Macでプログラムを組むためには、これらの既に組み込まれたルーチンの名前や機能を学習する必要があるだけで、後はあなたのプログラムからそれを呼び出せばよいだけです。

詳細

オリジナルのMacでは、これらが書き込まれた64KのROMチップを搭載していたということは驚くに値しないでしょう。400Kフロッピーディスクの時代では、ディスクにそれを保存しておく余裕はありませんでした!一枚のディスクには、ブート起動のMac OS、1つか2つのアプリケーション(MacWriteとMacPaint)、そしてさらにユーザが文書を保存できる余裕が少しだけあったことを覚えておきましょう!

PCでは、MS-DOSはほとんどスペースを取っていません。そしてほとんど何もしませんでした。

我々が述べていることについて、少し例えを見てみることにしましょう。これは基本事項であることは承知の上ですが、あなたがこの歴史の明確な理解を得るために重要で、それによって今回のレッスンの要点が明らかになるでしょう。

コンピュータの初期の頃は、OSはほとんど存在しませんでした。プログラムを組むことを家を建てることに例えるならば、当時は、木の釘を彫り、ハンマーとして石を使うようなものです。あらかじめ出来ているものは何もありませんでした。

1980年代初期では、釘やハンマーのような基本的なものは手に入れられるようになりましたが、依然、木材を加工したり、セメントを流し込んだりしなければなりませんでした。

AppleがMacintoshを発表したとき(あるいはLisaまで遡ってもよいですが)、突然、建築家には様々な選択肢が与えられました。つまり、あらゆる長さや希望の形状にカットされている板材、釘、ドリル、ハンマーがあり、そして家の基礎は既にできているのです!

その一方、こんにちのプログラミングは既に加工された家を組み立てるようなものです。つまりそれはLegoブロックのように部品を貼り合わせるだけで、壁は、電線やコンセントが組み込まれているだけでなく、既に模様も入っています!照明やシーリングファンが必要ですか?それは最も適した位置にただ置くだけです。どんな部品やアクセサリーもREALbasicのコントロール・パレットを利用できます!あなたの仕事は、家をデザインして独自の機能性を持たせるようにするだけです。

しかしこれまで、我々は処理を行うための既に記述されたルーチンについて述べてきただけでした。これらはオブジェクトとは違うのでしょうか?

次週

オブジェクトを理解します。

REALbasic Developer ニュース

新刊のREALbasic Developerマガジンについては、昨夏に発行されてからたびたび耳にしていると思います。今までのところ、それを読む手段は定期購読だけでした。

ここで素晴らしいニュースがあります。REALbasic Developerのお試しバージョンが、フリー・ダウンロードで利用できるようになりました!

このお試しバージョンは創刊号のPDFで、ほとんどすべての内容を含んでいます。また少なくともすべての記事の一部分が含まれるので、計画された内容のバランスをうかがい知る事が出来るでしょう。多くの記事は全部が掲載されています。しかしながら、サンプルから出版物の質がはっきり見て取れるので、それをチェックするようあなたにお勧めいたします。

PDFのサンプルはここから入手できます。

あなたが12月に購読を開始したときは、定期購読は現在の号(1.3、2002年の12月/1月号)から始まることに注意して下さい!

Letters

今週はお便りはありません。


RBU-Jの通知サービス!コラムが発表されるたびに日本語版REALbasic Universityのお知らせの emailがあなたに届きます。登録・削除は ここ から。

INDEXに戻る