RealBasic University

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

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

OOP University:パート 22

前回、我々は可能性のあるいくつかのRBlogのデータ構造を検討しました。今回は、どれが我々のニーズにもっとも適しているかを探るために、それらを評価していきます。

しかし最初に、データ構造#4の「ユニーク」なキーの問題を解決しましょう。

データ構造#4の完成

前回のレッスンで出題された「宿題」は、REALbasicのdictionaryクラスのキーがユニークであるという要求を、どのように実現するかを考えることでした。これは、キーとしてウェブログ入力の日付を使用すると、一日あたり一回の投稿に制限されてしまうことが問題でした。totalSecondsをキーとして使用すれば、二つの投稿が同日のまったく同じ時間になることはないのでユニークとなります。しかし、それでは投稿された正確な時間が分かる場合に検索できるだけで、特定のレコードを検索することは一般的に難しいでしょう。

必要としているものは、日付で入力を早く検出し、あとで時間によってもそれを分類することができる方法です。dictionaryはキーひとつにつき一項目しか保存できない(キーはユニークでなければいけません)ので、dictionaryのアプローチはあきらめなければならないでしょうか?

答えはノーです。知ってのとおり、dictionaryはどのような種類のデータ(型は様々です)も保存することができます。したがって、一つのdictionary要素の中に、ウェブログ入力の配列を保存してみましょう!

dayEntriesClassと呼ばれるオブジェクト・クラスを作成し、一日に投稿されたすべての入力を保存してください。次のようにします。

  
dim theTime, theTitle as string
dim i, numEntries as integer
dim aDay as dayEntriesClass

aDay = new dayEntriesClass
if findByDate.hasKey("5/20/2003") then
aDay = findByDate.value("5/20/2003")

// aDayオブジェクトは、特定の日付(この場合は"5/20/2003")
// の入力の配列を保存しています。
numEntries = aDay.count
for i = 1 to numEntries
// ここで、各レコードに対する
// 各領域の詳細を読み出します。
theTime = aDay.entries(i).time
theTitle = aDay.entries(i).title
...
etc.
next // i
end if

このコードが複雑な図を多く用いるよりも分かりやすいものであることを願います。基本的には、entryClassの配列entriesを持っているdayEntriesClassクラスを作成する必要があります。この方法なら、同じ日に各々はユニークな時間の入力を無制限に取り扱えます。

入力トピック(カテゴリー)がさらに重複しているので、我々は同じ方法でfindByTopic dictionaryオブジェクトを整理することができます。findByTopicの各項目は、entryClassオブジェクトの配列構造を示すtopicEntriesClassオブジェクトを示すでしょう。

複雑ですか?確かにそうかもしれませんが、便利なところに目を向けてください。メインのデータ格納庫として、中心となる辞書オブジェクトがひとつあります。しかし日付やサブジェクトによって、オブジェクトのリストをすぐに得ることができます。まさに一石二鳥です!

そして、オブジェクト内部でいくつかのソート機能を組めば、新しい順(findByDateリストの時間) とABC順(findByTopicリスト)で、それらのリストを簡単にソートしておくことができます。後ほど、データをHTMLページとして公表するとき、我々は各入力を取り込んだリストをただ巡回するだけで、それをHTMLに変換することができます。

これで完成?

これまでのところデータ構造#4は、いちばん複雑ではありますが、またいちばん多くの利点があるようです。しかし、我々はそれを充分に検討してきたでしょうか?構造をもっと効率的かつ柔軟にできないでしょうか?

答えはイエスです。それらを実装する前に、解決策を再評価することはいつでもいいことです。それができる限り完成度の高いものであることを確認してください。

データ構造#4では、効率的でないところが二つあります。

第一に、dictionaryクラスのユニーク・キーの要求は、新しい配列の追加で解決しますが、配列は順番に検索されなければならないので検索が遅くなります。しかし、一日分の投稿については問題ではありません。一日分では、ほとんど2、3くらいの投稿しかないからです。しかし、サブジェクト(カテゴリー)配列はまた別の問題です。何年間もの投稿が積み重なると、一つのトピックの投稿は数千にもなるでしょう。よって、我々はサブジェクトリストの開始点を早く見つけることはできても、それからそのサブジェクトの各入力を順番に検索しなければなりません!

この解決策は、いままでに行ってきたことを拡張していくことです。そのオブジェクト内の配列の代わりに、別のdictionaryを使用するのはどうでしょうか?ちょうどfindByDateオブジェクト内で使うように、各入力はそのユニーク・キーとしてその日付を使うでしょう。ここで高速検索に舞い戻ってきました。サブジェクトの検索はdictionaryなので早くできます。いちどサブジェクトを検索できれば、dictionaryオブジェクト内の特定の日付はすぐに検索できます。入力はそれぞれ一日に制限されるので、dictionaryオブジェクト内の入力はその日の投稿の配列構造を示しているでしょう。

もうひとつの問題点は、それを特定のオブジェクトのためにハードコードしてきたことです。それはfindByDatefindByTopicの類似点を見るとよくわかるでしょう。それらがほとんど同じものであるにもかかわらず、各オブジェクトのためにカスタム・オブジェクト・クラスを作成しなければなりません。それではめんどうだと思いませんか?

さらに、Author(作者)のような新しい検索パラメータを追加するとしたら、このAuthorの検索も日付とトピックの時と同じように早く検索したいでしょう。しかし、現時点において、それにはいくつかの新しいオブジェクト・クラスを作成するということになるでしょう。その代わりに、必要なものすべてについてカスタマイズできる一般的なクラスを導入するのはどうでしょうか?

もともと我々には、findByDate用のクラスとfindByTopic用のクラスがありました。我々に必要なものはfindByFieldのような一般的なクラスです。FindByFieldは特定のフィールドを念頭に置いて作成されません。実際のフィールド特性(データ型、サイズなど)とどのようにそのフィールドが構築されるか(配列、dictionaryなど)は、プログラムの実行中に動的に選定されます。

我々はまた内蔵のソート機能を追加して、配列を含むフィールドがどのようにそれ自身をソートして、その内容をソートされた状態に保つようにもできるでしょう。これによって新しい入力が追加されるときには、配列の適切な(ソートされた)位置にそれが挿入されます。Matt Neuburg氏がREALbasic Developer(2002年10月/11月号、32ページ)で説明するような、各データ型が独自の比較オペレータを持つために、異なるデータ型をソートできる一般的なソート機能を使うことができるでしょう。

これで日付の入力リストが時間(新しい順)によってソートできるようになり、それをすぐさまエキスポートすることが可能になります。

これまでで、この複雑なオブジェクトの構造は明らかです。次の図は、基本概念を示しています。

これは必要となる基本クラスと、中心的な役割のデータ構造を示します。たとえば、様々なフィールド(日付、トピック、作者など)の検索インデックスを作るためには、findByFieldClassの変化型を動的に作成します。

解決策の評価

それではプログラムデザインのステップ3に移り、プログラム構造を検討して最善のものを選択しましょう。はじめに、それぞれのアプローチの長所と短所をみていきましょう。

データ構造#1:文字列配列

長所:

短所:

データ構造#2:辞書(dictionary)

長所:

短所:

データ構造#3:データオブジェクトの方法

長所:

短所:

データ構造#4:多重リストのアイデア

長所:

短所:

結論

明らかに、このプロジェクトではデータ構造#4が理想的です。しかし、それにはデータ構造を作成する初期段階で多くの処理が必要です。たとえば、ウェブログにはめったに投稿しないユーザは、スピードや効率性は最優先課題ではないため、たとえ遅くても単純な方法をベストとするかもしれません。

しかし、これはブレインストーミングでありプロジェクトのための複数のデータ戦略を評価するいちばん大切な部分です。プログラムの必要性を満たし、将来に必要な自由度を提供してくれる、最高に適した構造を見つけることはあなたに任せられています。

次週

プログラムデザインについてさらに進めていきます。

ニュース

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を書き、そして販売することについて詳しく述べて自分自身の事後分析を行いました。私は多くの過ちを犯しましたので、私の経験から学んでください!

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

Letters

今回は、Richardさんが専門からはずれた質問を書いてくれました。

REALBasic UniversityのレッスンはPDFフォーマットで閲覧できる予定はありますか?これはプリントするよりも便利で、スクリーン上のサイトから読もうとするより、読みやすいと思います。

Richard E. Meyeroff

これを聞いてきたのは、あなたが初めてではありません。一つの方法は、Mac OS Xでは「Save as PDF」機能、またClassicではサードパーティのソフトを用いて、あなた自身でページをPDFにプリントアウトすることです。それは必ずしも読みやすさが向上するわけではありませんが、貴重なオフライン・アーカイブの記事を手に入れることができます。

私はPDFで提供することを考え、その可能性もあるのですが、次の問題があります。言うまでもなくApplelinksは広告収入に支えられているサイトですので、我々はあなたにページを読み、広告を見て、リンクをクリックしてもらう必要があります。そのようにしてサイトは存続しています。我々がPDFフォーマットでそれを提供すれば、広告収入が減ってしまう可能性があるでしょう。

さらに、100近くの記事をすべてPDFフォーマットに変換するのには、多くの労力が必要になるでしょう。経済的な支援がなければ、私の時間を割く価値がないかもしれません。

そうは言っても、2、3のアイデアを考えてみました。たとえば、読者はRBUのPDF版に快くお金を払うでしょうか?バックナンバーすべてに対するわずかな一括料金や、あるいは新しいコラムが自動的に送られる定期購読の料金に対して快く払えるでしょうか?もしそうであれば、快く払えるのはいくら位でしょうか?5ドル?10ドル?20ドル?

私が考えている別のアイデアは、すべてのRBUコラムを実際に本に印刷することです。それについて充分な興味があれば、私は古いコラムに立ち戻って改訂し、Mac OS X、ウィンドウズ、そしてREALbasic 5用に更新するつもりです。300ページのRBUの本に30ドル支払って頂けますか?あるいはもっとコンパクトで安い「RBUベスト集」の方がいいでしょうか?PDFフォーマットでの本がお好みでしょうか?

このようなアイデア(あるいはあなたの提案)についてあなたの考えていることをrbu@stonetablesoftware.comまでお知らせください。まずまずの利益があれば、このようなものが現実になるかもしれません!


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

INDEXに戻る