RealBasic University

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

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

OOP University:パート 23

我々はここ2、3のレッスンを、オブジェクト指向プログラムの設計、特にオブジェクト指向データ構造の設計についての課題の検討に費やしてきました。これを行うにあたって、我々はRBlogという架空のウェブログ・プログラムを設計し、そのプログラムの理想的なデータ構造を考えてきました。しかし、プログラムがこれとは異なる場合にはどうしたらよいでしょうか?

多くの解決しなければならない問題があり、オブジェクト指向による解決策がたくさんあります。これから数回のレッスンに渡って、それらをいくつか検討し、その過程でオブジェクト指向の設計についてさらに学習していきます。

RBUの読者が提起してくれた2、3の現実の問題から始めていきます。始めに、プログラム設計についてのこのシリーズの引き金となった、Markus Winterさんが提起した問題です。

プログレス・ダイアログの追加

Markusさんが次のような手紙をレッスン096で書いてくれたのを憶えていますか。

REALBasicで、簡単なシングル・タスクのプログラムを書くことはとても簡単ですが、何か少し複雑なものを考えたとたんに、壁に突き当たってしまいます。例をあげると、現在、私が作成した簡単なプログラムを、ユーザのフィードバックに対応させるようにしようとしています。例えば、プログレスバーとキャンセル・ボタンを持つウィンドウをポップアップ表示させます。キャンセル・ボタンを機能させるためには、私はプログラムをスレッドで走らせなければならないことが分かりました。これは、プログラムすべてを最初から書き直す必要性があることを意味します。それは、プログラムの「デザイン」について私が考えるきっかけとなりました。私は他の可能性を見落としているでしょうか?それはマルチ・ウィンドウでしょうか?プリファレンスでしょうか?

この問題の中には、実は複数の問題が隠れています。そして、この問題を解決するただひとつの方法は、スレッドによる方法です。

進行状況表示ダイアログが行うことに目を向けましょう。それはモーダル・ウィンドウ(ユーザが閉じたり、他のウィンドウの後にもっていくことができないウィンドウ)で、そのウィンドウ内には進行中のタスクが何パーセント完了したかを図示するプログレス・バーと、現在行われている状況を表示するテキストがあります。

それは簡単なようですが、その中にはたくさんの問題が含まれています。たとえば、進行状態を示すグラフは、タスクが完了するまでの時間を表示するものでしょうか?それとも残りのタスクが何ステップあるかを記述するものでしょうか?これはまったく違ったものとなります。

次に、どのようにしてタスクの残り時間を推定したらよいでしょうか?コンピュータの速度はそれぞれのコンピュータで異なるので、あなたのコンピュータを基準とすることはできません。

中でもやっかいなのは、何を「タスク」と考えればよいのでしょうか?タスクは複数の部分から形成されるかもしれません。たとえば、「ケーキを焼く」は、計量して、材料を混ぜて、鍋にバターを入れて、それを熱くなったオーブンにある時間入れる、というすべてのステップが含まれるでしょう。しかし、それで十分なのでしょうか?お店で材料を購入するところから始まり、ケーキにきれいに飾りつけするまでを完成というのでしょうか?また、「焼く」は、熱くなったオーブンに適当な時間ケーキを入れることに限られるのではないでしょうか?

このように、進行状況表示ダイアログをもつタスクを定義するだけでもやっかいです。

マルチ・タスクについてのもうひとつの問題は、個々のタスクはかかる時間がそれぞれ異なるので、残り時間の目安をユーザに知らせるためには、残りのステップをただ表示するだけでは不十分です。

それから、ユーザによる中断という難題があります。進行状況表示ダイアログにキャンセルボタンがあれば、タスクを途中でキャンセルできなければいけません。簡単なようですが、実は難しいのです。プログラミングのタスクについて考えてみてください。ハードディスクにファイルを書き込んでいるとき、ユーザがそれをキャンセルしたら、ファイルの保存をただキャンセルするだけではなく、それまでに書き込まれたものを消去しなければなりません(途中まで書き込まれたファイルをディスクに残さないように)。ある時は、消去にかかる時間が、元のファイルをすべて書き込むよりも長くかかることがあります!

セットアップに時間のかかる複雑なタスクでは、ユーザが意図しないでキャンセルを押してしまうこともあるので、タスクを実際に停止させる前にユーザに確認をとるのが賢明でしょう。

再びRBlog

進行状況表示ダイアログが必要なプログラムの例として、RBlogをもう一度見てみましょう。RBlogは、内部データベースの記事からウェブログのページを作成します。アーカイブが増大するにつれて、それ以前の記事が公表されるので、数百のHTMLページになるかもしれません。追加された新規入力に応じて、投稿ボタンが押されるたびに多数のページが作成されます。また、更新されたページをウェブサイトに自動的にFTPでアップロードするためのオプションをRBlogに追加したいと思うでしょう。もちろん、これにはどれくらいの時間がかかるかをユーザに知らせるための進行状況表示ダイアログを表示するのがよい方法です。

そこがややこしくなるところです。RBlogの「ページを作成」は複数のステップからなります。たとえば、メインページ、アーカイブの索引ページ(アーカイブページへのリンク)、そして月ごと、サブジェクトごとによってアルファベット順にソートされたアーカイブページを作成します。これは「タスク」が複数の部分から構成されていることを意味しています。それらの部分のそれぞれは時とともに変わります。そして、それを完了するまでのステップ数も変わります。たとえば、現在の月の入力が変更されたならば、現在の月のアーカイブをアップデートするだけですが、いくつかの月が変更された場合は、複数の月にわたって新しいファイルを生成しなければなりません。

最初に決めなければならないことは、時間かステップで進行状況を表示するかどうかです。ユーザからすれば、たいていは時間がもっとも便利なオプションでしょう。要するにユーザは、二分待つのか、十五分待つのかを知りたいのです。ところが、完了予定時間を正確に予想することは難題です。ファイルをコピー中のファインダーの推定時間を見た人は、それが正確でないことに気づくと思います。たとえ初期推定時間を正確に予想する方法を思いついたとしても(普通は小さなタスクを事前に試して、今のマシンのスピードを測ります)、マルチタスクのOS(Mac OS XのようなOS)上では、ユーザはCPU時間を横取りして本来のタスクを遅くする他のタスクを同時に立ち上げるかもしれません。これは推定システムが動的でなければならないことを意味します。そしてその計算はタスクを長くします。

FTPのアップロードのようないくつかのタスクは、利用可能なバンド帯域や、別のマシンの状態のように常に変化している変数に依存します。よって、FTPのアップロード・プログラムでは、現在の接続状況によって時間が変化するので、推定時間はほとんど当てになりません。

あるタスクは不確定(完了までにどれくらい時間がかかるか知る術がない)であることを覚えておくことは大事です。たとえば、二台目のマシンが返答するのを待つプログラムは、そのマシンが返答するのにどれくらい時間がかかるのか予想することはできません。他の例では、タスクの二番目の部分が完了する時間を予想する前に、タスクの一番目の部分でデータが作成されなければなりません。RBlogはこのカテゴリーに分類されます。26,211文字をディスクに書き込む、あるいはファイル・サーバーにアップロードするまでにかかる時間を推定できますが、我々はファイルにちょうど26,211文字あることを知るために、データを作成する必要があります!データの作成箇所は「タスク」に集約されるので、データのサイズやアップロードにかかる時間を前もって正確に予想することはできません。

不確定か複雑なタスクの場合には、異なる種類のプログレス・バーを表示するのがよいかもしれません。残り時間を示す代わりに、なおかつ残りステップ数を示すことができます。ステップが比較的一定の長さである場合には、これは完了までの時間を示すのに非常に有効です。ところが、あるステップが他のものよりも格段に長い場合(たとえば、RBlogではページ生成のところは、FTPでアップロードするところよりもはるかに速いです)、次のような二段のプログレス・バーを考えてみるとよいでしょう。

二段プログレス・バーのダイアログには、二本のプログレス・バーがあります。上側のものは、全体のタスクの長さを示します。下側のものは、現在のサブ・タスクにかかる時間(たとえば、現在のファイルをFTPサイトにアップロードする時間)を示します。

進行状況表示ダイアログについて覚えておきたい大切なことは、それが二つの重要な機能を持つということです。一つ目は、タスクの残り時間の目安をユーザに示すことです。しかし、二つ目は、それと同じくらい重要なのにしばしば忘れられることです。それはプログラムが止まってしまったと勘違いされないように、ユーザにフィードバックを返すことです。

プログレス・バーのシステムを設計するときは、このことを心に留めておいてください。おそろしく時間のかかるサブタスク(秒単位ではなく分単位)がある場合は(ユーザがプログラムがクラッシュしてしまったと思わないように)、二段プログレス・バーのダイアログを使用するか、ユーザに進行具合を知らせる他の方法(テキストの数値で進行を示すなど)を使うといいでしょう。

次に、キャンセルボタンを導入するべきかどうかを決める必要があります。驚くかもしれませんが、ユーザに長いタスクをキャンセルする機会をつねに与えるべきだと考えてはいませんか?

ところが、タスクをキャンセルしない方がよい場合が数多くあります。たとえば、タスクが完了しないとコンピュータが不安定になる動作はキャンセルされることがあってはいけません。例としては、ドライブのフォーマット中(半分フォーマットされたドライブは、意味がありません)、OSのインストール中(途中で止めることは、致命的です)、ファイルの移動中(一部だけ移動しても意味がありません)、データベースの構築中などです。完了しないと物事を不安定にする致命的なことがよくあります。たとえば、古いファイルを新しいもので上書きしているときにキャンセルされれば、ユーザにはどちらのファイルもないという重大な状況になる可能性があります(特に、ウェブサイトでは不完全で存在しないHTMLファイルが残ることになります)。

他の場合には、ユーザにキャンセルのオプションを与えるということは、思っていたよりもすることが多いこともあるでしょう。たとえば、タスクが複雑なマルチ・パートの動作であれば、ユーザがキャンセルする前の状態に戻すためにそれをやり直すのは難しいことです。動作の特徴や長さによっては、キャンセルボタンを与えないこともひとつの方法です。たとえば、ほとんどのプログラムでは、ファイルの保存中にキャンセルさせることはありません。その理由はファイルの保存はすぐにできるからですが、取り消すのが難しいからでもあります。

しかし長いタスクでは、ほとんどの場合にキャンセルのオプションがあった方がいいでしょう。何かの理由で動作がキャンセルできず、完了までに時間がかかるかもしれないときは、動作を始める前にユーザに警告しておくのがよいでしょう。たとえば、「この動作は完了までにしばらく時間がかかり、キャンセルすることはできません。このまま続行してよろしいでしょうか?」というようなものです。

ユーザにキャンセル機能を与えた場合には、あなたはどのようにキャンセルを処理するか決めなければなりません。Markusさんによって指摘されたようなスレッドなど、異なる方法がいろいろ とあります。次回、我々はそれを検討していき、この問題に対する私の解決策を提供しましょう。

次週

再利用できる進行状況表示ダイアログボックスのプロジェクトを作成します。

ニュース

REALbasic Developer 1.6近日出荷

REALbasic Developerの次号は現在印刷中で、すごい記事がいくつか掲載されています。実は、とても盛りだくさんの内容でしたので、インタビューの記事は省かなければなりませんでした!(次号からは掲載しますので、心配しないでください。)

ここで2003年6/7月号に掲載予定のものを、こっそりご紹介致します。

まずは、Erick Tejkowski氏がすばらしいQuickTimeの記事を持って戻ってきました。彼はREALbasic中でどのようにQuickTime videoとaudioトラックを操作するのかを説明してくれます。マルチメディアに関心のあるすべての人は必読です。

次にCharles Yeomans氏は、REALbasicでいちばん知られていない秘訣のうちの一つであるコントロール・バインディングについて説明します。コントロール・バインディングは、あなたに代わってRBにプログラミングを行わせます。コントロール・バインディングによって、あなたは一行のコードも書かずに2つのコントロール(たとえば、listBoxからeditField)をリンクすることができます。あいにくコントロール・バインディングについてはあまり明文化はされていませんでしたが、このすばらしい記事でCharles氏がそれを補ってくれました。

最後にJoe Strout氏は、標準以上の性能を引き出す宣言(declare)を使用して3DライブラリーであるQuesaを最大限に利用することについて書いています。

この号の中で、私はワープロソフトであるZ-Writeを書き、そして販売することについて詳しく述べて、自分自身の事後分析を行いました。私は多くの過ちを犯しましたので、私の経験から学んでください!

もちろん、我々はレギュラーのコラムニスト、すぐれた製品のレビュー、そしてさらに多くを掲載しました。まだ定期購読されていないならば、いま購読しない手はありません。

特別提供版REALbasic for Windows

Mac版のREALbasicがあっても、Windows版のREALbasicもほしいですか?REAL Software社は、そんなあなたのために通常価格よりも最高で$240安いWindows版を、期間限定で特別に提供します。この特別提供版でお金を節約しましょう。この提供価格は、7月下旬[2003年]までです。遅れないようにしてください!

Letters

Jaysonさんから、REALbasic Professional版にアップグレードした方がよいかどうかについての質問をいただきました。彼は次のように書いています。

Zeedarさん

私は最近、REALbasic Universityを読み始めました。そこでひとつ質問があります。

今はREALbasic 5 Professional版をゆっくり待ってから$299.99でアップグレードする代わりに、$199.99でアップグレードできるチャンスです。

私はREALbasicを学習し始めたばかりで、standard版を持っていますが、今回のアップグレードについてしばらく考えていました。データベース機能(私はウェブデザイナーなので、今はMySQLを勉強しています)を使うかどうかまだはっきりわかりません。けれども、Windowsのプログラムが作成できることはとても魅力に感じています。

私のような初心者に何かアドバイスをいただけないでしょうか?今アップグレードしたほうがいいですか?それとも、更に$100下がるまで待ったほうがいいですか?現在の$200はちょっと高すぎます…

よろしくお願いします!

Jayson Ng

Jaysonさん、これは難しい質問です!けれど、いつかは必ずProfessional版に移行するつもりであれば、今手に入れてしまうのがいいかもしれません。しかし、一年などの長い期間、Professional版の機能が必要ないのであれば、それまで待つのもよいでしょう。今はアップグレードもお得ですが、新しいRBのバージョンが発売されるとき、「Srandard X版からProfessional X+1版」(Xは5などのバージョン番号)のアップグレードもお買い得です(これは「Standard XからStandart X+1」にアップグレードして、その後で「Srandard X+1からProfessional X+1」へアップグレードするよりも安価です)。

RBのいい点は、Standard版でもPro版の機能が試せることです。たとえば、50レコードしか動きませんが、データベース作成にこれを使用することもできます。5分後には終了しますがWindowsのアプリケーションを構築することもできます。これでは販売可能なアプリケーションの製作はできませんが、少なくともテストすることはできます。実際のアプリケーションを完成するには長い時間がかかるので(趣味やパートタイムでやっている場合はなおさら)、Pro版の機能を使ってアプリケーションを作ってみたくても、本当に機能制限のないPro版が必要になるのは一年後になるかもしれません。私は、一年間はアップグレードせずにStandard版を使っていました。

Pro版からPro版へのアップグレードは、Standard版からStandard版へのアップグレードよりもお金がかかります。だから、あなたが本当にその機能が必要になる一年や二年も前に購入すると、アップグレードに余計な費用がかかることを心に留めておいてください。


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

INDEXに戻る