このコラムはStone Table Softwareのオーナーであり、またREALbasic Developerの編集者でもあるMarc Zeedar氏により書かれたものを、著者の許可を得て翻訳したものです。この翻訳はHREM Researchにより提供されています。この日本語版へのご意見はRBU-Jまでご連絡下さい。
URL: http://www.applelinks.com/rbu/096/先週、我々はいくつかの重要なオブジェクト指向の概念を復習しました。これから行っていくことは、それらが実際の応用でどのように利用されるかに注目して、オブジェクト指向のアイデアをさらに追求していきます。これについては今後のいくつかのレッスンに渡って行っていきますので、異なるアプローチがあなたの理解の手助けになれば幸いです。
このRBUのコラムは、ニュージーランドのMarkus Winterさんの一通のEメールによって刺激を受け、喚起されました。彼は次のように書いています。
こんにちは、Marcさん
私は、遅かれ早かれたいていの初心者が遭遇する、もう一つの「問題」につまづいてしまいました。それはプログラムをはじめることをとても困難にするもので、私は何が間違っているのか分かりません。
はい、その通りなんです。
私はプログラムとはどういうもので、どうあるべきかというアイデアをぼんやりと持っていますが、私は見落としているのがどの部分であるか見当がつきません。
REALBasicで、簡単なシングル・タスクのプログラムを書くことはとても簡単ですが、何か少し複雑なものを考えたとたんに、壁に突き当たってしまいます。例をあげると、現在、私は作成した簡単なプログラムにユーザにフィードバックに対応するようにしようとしています。例えば、プログレスバーとキャンセル・ボタンを持つウィンドウをポップアップ表示させます。キャンセル・ボタンを機能させるためには、私はプログラムをスレッドで走らせなければならないことが分かりました。それは、プログラムすべてを最初から書き直す必要性があることを意味します。それは、プログラムの「デザイン」について私が考えるきっかけとなりました。私が見落としている他のデザインは何でしょうか？それはマルチ・ウィンドウでしょうか？プリファレンスでしょうか？
そう言うわけで、OOPの一部として、プログラム・デザインについてのレクチャーを含める、あるいはこのようなややこしいすべての問題に対応できるアプリケーション・フレームを作成するというアイデアはいかがでしょう……。
どうぞよろしくお願いします
Markus
P.S. あなたのレクチャーは楽しみにしています―残念ながら、申し込んだ「お知らせメール」が機能しません…
Markusさんはとても重要なポイントを突いています。簡単なプログラムでは、タスクは順次に実行されるので、初心者が解決策を見出すのは比較的簡単です。しかし、各部分がお互いにやり取りをするようになり、プログラムが複雑になるやいなや、初心者は途方に暮れてしまいます。
このような種類のプログラムの作成を難しくしている別の問題は、プログラムが未完成の時はテストを行うのが難しいことです。初心者は手順の検討に多大なエネルギーを浪費し、最後にデザインが間違っていることを発見します。しかし、始めからやり直してまで面倒な修正に時間を掛けようとはしません。その結果、プログラムの保守やバグの修正が困難になり、プログラマーはそのプログラムが嫌になります。
この問題に対して真の解決策があるか、私は確かではありません――デザインすることなくプログラムを始める誘惑はとても強く、そして経験のみが、あなたにそれに屈してはいけないと教えてくれます。しかし、要は「実行する前に、よく吟味せよ」が長い目で見ると常に助けとなることです。
しかし、初心者のプログラマーがプログラムをデザインする時間を「浪費」と思って嫌う理由は、彼らがプログラミングのデザイン面を理解していないからです。コード面は、もっとリニアで、ここで始まり、ここで終わりというように理解しやすいものです。デザインは選択のオプションがたくさんあり、終わりがありません。メソッドA、メソッドB、あるいはメソッドCを選ぶことができます。
オブジェクト指向プログラミングを、クラスやインタラクティブなオブジェクトをデザインする必要のある混沌に投げ入れれば、プログラミングはうまく動き始めるでしょう！
本当は、デザインはプログラミングのもっとも楽しい部分の一つでもあります。これを制限はまったくないというように考えてみましょう。デザインを行っている間、あなたは何でも行うことができます。だから、調べて、ブレインストーミングし、発明し、クリエイティブになり、考察し、計画を練り、予想してください。
プログラムのデザインには、基本的な３つのステップがあります。
この中の一つ一つは、見た目よりもっと複雑です。それぞれが、多くのサブステップを持っているでしょう。
最初の、「問題の定義」は簡単に聞こえます。しかし我々はコンピュータと対話していることを忘れないでください。あなたはコンピュータが理解できる方法で、問題を記述しなければなりません。あなたが本当にしたいことについて非常に多くを学ぶのは多くの場合このステップの間です。あなたがしたいと思ったことと違った結果になることがよくあります。
これを架空の例題プロジェクトを用いて検討してみましょう。あなたがブログ形式のウェブログ・プログラムを書いているとします。このプログラムは、日付と時間によって区別されるユーザ入力のデータベースを保持します。ユーザが「パブリッシュ」ボタンを押すと、プログラムはアーカイブされたリンクを含むウェブサイトを作成し、すべてのHTMLファイルとグラフィクスをユーザのウェブサイトへアップロードします。我々はこれに少し時間がかかることを想定し、Markusさんの場合のように、キャンセルボタンを持つアップロード状況の表示が必要となるでしょう。
それでは、我々の問題は何でしょうか？この例題では、たくさんあるでしょう。しかし、要するに我々に必要なものは次のようなものでしょう（順不同）。
ご覧のように、アップロード状況表示を扱う「問題」はここに示されていません。我々は問題のリストを充分に列挙していないからです。しかし、ゆくゆくはそれを取り上げる予定です。
あなたが問題を把握したならば、いくつか解決策を考えなければなりません。はじめの直感は頼りにしないでください。それは正しいかもしれませんが、そうでないかもしれません。問題について熟考し、それを解決する代替案が他にないか考え出す時間を２、３分はとってください。
あらゆるプログラムのもっとも重要な点は、データ構造の選択です。プログラムが行うことすべてに対して、これは重大な影響を持ちます。あなたが書いているプログラムの必要性にフィットするデータ構造を取り上げる必要があります。
例えば、emailプログラムは基本的に短いテキストからなるデータベースです。しかし、ユーザがemailプログラムを操作する方法（一度にたくさんのemailを開く、いくつかをフォルダーに保存する、電話番号を全アーカイブから検索するなど）は、あなたのデータベースが早いほどよいことを意味します。つまりは、いつまで経ってもフォルダーの内容を表示できないemailプログラムを希望する人はいません。
別の例として、三次元のマルチユーザ・インターネットゲームを書いているとしましょう。ゲームは一般的に、操作する動的なデータ（マップ、位置、悪役、武器のリスト、健康パラメータ、スコアなど）は多くありませんので、ゲームのデータ構造を最初に考えることはそれほど重要ではありません。しかし、これはネットワークにつながったゲーム（ネットワークにデータパケットを送受信して、すべてのゲーマーが同期状態にあること）を意味します。それはデータ構造を注意深く設計する必要があることを意味します。つまりあなたがそれをコンパクトにすれば、データの移動は少なくなりますし、プログラムがそれをデコードしてデータを用いる速度も速くなります。
スケールについて考えてみましょう。200個のデータを扱うプログラムと、数百万のデータを扱うプログラムでは、必要なものがかなり違います（個人会計プログラムと、大企業500社の会計プログラムの違いです）。
ユーザの習慣・癖について考えましょう。彼らはどのようにプログラムを使用するでしょうか？例えば、プログラムがXMLフォーマットでデータを保存すればすばらしいだろうと、決めたとします。しかし、XMLは重いテキスト・フォーマットで、多くのデータをXMLに保存するには時間がかかるでしょう。ユーザが定期的に作業を保存するような人たちであれば、たとえ保存する時間に数秒余計にかかるだけでも、ユーザにいらだちを感じさせるかもしれません。
あなたのプログラムが、データを用いて行うために必要なことについて考えて下さい。データは定期的に変更されますか？それは頻繁に読み出され、検討されますか？データは保存される必要がありますか？もしそうであれば、それはどれくらいの頻度で、分類はどれくらい複雑ですか？プログラムは、データを検索する必要がありますか？それはどのような検索で、どれくらいの頻度でしょうか？
我々の例題プロジェクトであるRBlogで、これらの問題を見ていきましょう。ウェブログは通常、個別のかたまり（投稿）の情報（主テキスト）を扱います。それぞれの情報は、いつか書き込まれたかを示す日付と時間があります。emailのように、入力はタイトル、分類などのような基本的な部分があるでしょう。テキストは、HTMLフォーマットやインライン画像を含むかもしれません。
通常、ウェブログのサイトは多数の領域を持ちます。それには現在の投稿が時間の逆順（新しい投稿から古い投稿順）に並べられたメインページ、月ごとと年ごとによってアーカイブされた投稿へのリンクがあるアーカイブページ、特定の月のすべての投稿を含むページがあります。あるサイトは、アーカイブされた投稿が、件名によって五十音順に並べられていることもあります。ブログのプログラムは、このようなページをすべて自動的に生成する必要があります。そして、それらのページを新しい投稿が追加されるごとに更新します。
ほとんどのブログは、週に何度か、あるいは一日に何度か定期的に更新されます。通常は一日に２、３回の投稿があるだけです。数年間に渡って続けられてきたブログは、投稿は数千にも上るでしょう。
結論は何でしょうか。我々のデータ構造は、日付、時間、タイトル、件名ですばやく検索できる必要があるということです。我々は膨大な数の入力は扱わないでしょう（一日に三件の投稿が十年間続いても、たった11,000項目しかありません）、このためソート・検索システムはそれほど複雑である必要はありません。我々はスピードよりも、機能と使いやすさを重視します。
しかし、プログラムが件名と日付で整理されて保存されている投稿を生成する時、入力が追加される毎にアーカイブの一部が更新される必要があるので、我々は効率的な検索システムが必要となります。
最後に、11,000項目（多く見積もって）はソートにとっては多くないかもしれませんが、読み書きするデータは莫大な量になるでしょう（それぞれの投稿が1Kのデータとすると、11MBになります）。我々はシステムがデータファイルの保存のために、時間があまり長く掛からないようにしなければなりません。データファイルの形式は、テキストデータに加えて画像も保存することができなければなりません。
お分かりのように、我々はデータ構造のいくつかの重要な要請を確認しました。次回は、そのデータ構造を実現するいくつかのアイデアを理解しなければなりません。オブジェクトはその構造にどのように適合できるのでしょうか？
今回の宿題は、RBlogについての完全に異なるデータ構造を最低三つ考えることです。あなたがどれくらい革新的になれるかを試して欲しいので、私は「完全に異なる」という点を強調します。私のアプローチを次回に公開し、これらを細かく見てどのアプローチが一番よいか決定する、第３のステップ３に進みましょう。
オブジェクト指向プログラムのデザインをどのように行うかについての学習を続けていきます。
皆さんは依然グローバル変数の概念に手を焼いているようです。今週はCorey Crossmanさんからこれに関する件をいただきました。彼は次のように書いています。
グローバル変数はどのように手に入れられるのでしょうか？私はグローバルに関するあなたのレッスン（レッスン19だったと思います）に従ったのですが、うまくいきません！
それでは、私のしようとしていることを示します。最初に呼ばれるwindow1に文字入力欄（editfield3)を置きます。window2の文字入力欄(editfield1)にそのテキストを渡したいと思います。これにはどのようにすればよいのでしょうか？また、この変数を後ほど再度呼び出したいと思っています。
できるだけ早くお答えいただけると助かります！私は手助けが必要です！頭が痛みます…。
Cert
Coreyさん、次の簡単なステップが答えです。
あなたの場合には、文字入力欄の内容を記憶しておきたいので、文字列変数（例えばgTheText as string)が必要でしょう。一度グローバルとして宣言されれば（モジュール内にあるので）、あなたはプログラムのどこからでもこの変数にアクセスすることができます。よってWindow1で次のようにすれば、後々どこからでも使用できるようテキストを保存できます。
gTheText = editField3.text
また、次のようにして、そのテキストを他のウィンドウ(window2)に移動することができるでしょう。
window2.editField1.text = gTheText
ところで、私はあなたの参照しているレッスンがどれなのかはっきりしませんが、私はRBUの16と53で、グローバル変数についての質問に答えています。RBUの他で述べられた事柄を探すには、こちらのGoogle検索を利用できます。
RBU-Jの通知サービス！コラムが発表されるたびに日本語版REALbasic Universityのお知らせの emailがあなたに届きます。登録・削除は ここ から。
INDEXに戻る