RealBasic University

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

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

OOP University:パート 1

先週、私はオブジェクト指向プログラミング(OOP)に焦点を当てたRBUコラムの新しい連載を計画したことを発表しました。このシリーズを"OOP University"と呼ぶことにしましょう。この決定について、既にいくつかの建設的なお便りを頂いています(今回のLetterセクションをご覧ください)。

この連載終了後に、このような人々がどのように感じるか分かるでしょう。もちろん、私はOOPのエキスパートだとは申しませんし、私の知らないOOPの側面を扱う"テキストブック"もありますが、少なくともOOPの基本概念を皆さんに紹介することはできると思います。その上、OOPの上級者向けの本は大量に存在しますので、あなたが一旦基礎を理解すれば、そのような概念は容易にREALbasicに適応できるでしょう。

それではOOP Universityを始めましょう!

イントロダクション

初めて"オブジェクト指向"のREALbasicを学んでいる経験あるプログラマーたちと話していると、興味深いことに気がつきました。現代のプログラミングには2つの鍵となる概念が存在します。それはオブジェクトイベント駆動アプリケーションです。これらは全く同じものではありませんが、ある程度は重複します。そして従来のプログラミング経験者達は、この2つをしばしば混同してしまいます。

現代のプログラミングを学習するには、この2つの概念の違いを理解することが必要不可欠です。どちらも、従来のプログラマーに馴染みの薄い問題を投げかけてきますし、その2つの違いを充分に認識していない場合は、これから直面する問題に対処する方法が分からないでしょう。

私がまず始めにしようとしていることは、これらの概念を詳細に説明することです。現代のプログラミングは、新たな思考様式をあなたに要求することでしょう。それは悪いことではありませんが、挑戦的で困難な事でもあるでしょう。

だから気分を楽にして取り組みましょう。直ぐに理解できないからといっても、心配しないでください。――いつか理解できると、私は約束します。

モーダル・プログラミング

80年代以前に見られる、シンプルな従来のプログラミングは、極めて直線的なものでした。すなわち、まず出発点があり、それから中間点、そしてはっきりした終点が存在します。ステップ1、ステップ2、ステップ3、ステップ4、終わり―というように、プログラムはそのアルゴリズムとまさに同じ順に書かれます。

このようなプログラムは、我々がモーダルと呼んでいるものです。つまりモーダルとは、プログラムには様々な"モード"があり、ユーザはそのモードに限定されることを意味します。いくつか例を挙げることにしましょう。

1982年に、あなたがワープロを書いているとしましょう。当時のワープロは、こんにちの巨大プログラムのような機能はほとんどなく、もっと簡素なものだったという事実はさて置き、プログラムを書く方法について見ていくことにしましょう。

まずオープニング・メニューから始めましょう。ここでは新しいファイルを作成(New File)、存在するファイルを開く(Open File)、ファイルの印刷(Print File)、終了(Quit)を選択できます。それがオープニング・メニュー・モードです。つまり4つのコマンドだけで、それ以外は受け付けません。

Opening Menu Mode:
   - New File
   - Open File
   - Print File
   - Quit

オープニング・メニュー・モード(Opening Menu Mode)のコードはとても簡単です。ユーザがファイルを開くときに、ユーザに尋ねてそのファイル名を入力してもらいます。ファイルが存在すれば、それを開き、編集モードにテキストを渡します。もし存在しなければ、エラーを返します。印刷(Print File)も同様で、編集モードへ行く代わりに、印刷モードに行くだけです。ファイルの新規作成コマンド(New File)は、ユーザに新たなファイル名を聞いて、そのファイルが存在しなければブランク・ドキュメントを開き、編集モードへ行きます。終了(Quit)は終了するだけです。(オープニング・メニュー・モードではドキュメントは開かれていないので、未保存の文書保存を確認する必要がないことに注意してください――以前はどれほど単純なプログラム環境だったか分かりましたか?)

印刷モードもそれほど難しくありません。いくつかの簡単な印刷オプションを画面に表示させ(ページ範囲の選択、ページ番号の有無、ヘッダーとフッターの有無、印刷品質の設定など)、それから文書を印刷します。印刷が終了したとき、オープニング・メニュー・モードに戻ります。

最も複雑なのは編集モードです。編集モードは、ユーザがテキスト入力をする場所です。しなければならない複雑なことがここでは沢山あります。テキスト・カーソルの移動の扱い(矢印キーでの移動です――当時はマウスはありませんでした)、キー入力の受付、バックスペース・キーの扱い(カーソルの左にある文字の削除)等です。

編集モード内では、ユーザ補助のための特別なコマンドがいくつかあります。単純化のため、我々はそれを次のものに制限しましょう:始点に移動、終点に移動、左寄せ、中央寄せ、均等割付、文字カウント、スペルチェック、保存、及び終了です。

これらのコマンドはすべて、特別なキーを押すことによって機能します。DOS全盛の古い時代では、この役割を担っていたのは大抵コントロールキーでした。技術的にいうと、コントロールキーが押されると、コントロールキー・モードと呼ばれる別のモードに移ります。コントロールキー・モードは、どのキーが押されるか、そして設定されたコマンドのキーと合致するかどうかを監視するだけです。例えば、コントロール+S(^S)は、保存コマンドになります。

コントロールキーが押されていないとき、編集モードはユーザに文書入力をさせます。そのモードで処理しなければならないことは、ユーザのキー入力だけです。コントロールキー・モードでは、ユーザが押したキーを調べて、プログラムの制御を適切なモジュールに渡さなければなりません。例えば、ユーザがスペルチェックを選択した場合は、スペルチェック・モードに移る必要があるでしょう。

スペルチェック・モードでは、それ以外のコマンドは受け付けません。別のモードにいる時は、それ以外のコマンドは無効にします。スペルチェック・モードでは、次のようなコマンドが利用できます。

Check Spelling Mode
  - Skip Word (spelled correctly)
  - Add Word to Dictionary
  - Select Replacement from Suggestion List
  - Type in Replacement
  - Exit

ここでも、ユーザの選択は極めて限定されています。プログラマからすれば、これは好ましい事です。なぜなら編集しているファイルの名前を変更したりと、ユーザが予想もしないことをする可能性を心配する必要がなかったからです。(1982年では、パソコンのOSは、プログラムのようにモーダル[一度に1つの作業しかできない]ことを覚えておいてください。)

様々なモードにもかかわらず、このワープロのコードは、通常は一つのとても長いファイルです。(いくつかの言語は、様々なファイルをひとつの大きなプログラムに結合し、個々のファイルに存在するルーチンを呼び出すことができますが、直線的な原理は依然変わりません。)

コードは通常、それぞれのモードに対するサブルーチンから構成されます。例えば、この簡単なルーチンは、オープニング・メニュー・モードに使用できるでしょう。

procedure open_menu;

var k: char;

begin {open_menu}

  repeat
    k = readKey;
    if k := "N" then
      new_file;
    end if;

    if k = "O" then
      open_file;
    end if;

    if k = "P" then
      print_file;
    end if;
  until k = "E";

end; {open_menu}

上記のコードはパスカル(Pascal)で記述されています(少なくとも私が一番よく覚えているものです;-)――括弧{}で囲まれた部分はコメントです。"readKey"は、キーボードのキーが押されたか確認する関数で、それを変数"k"に割り当てます。new_file、open_file、print_fileはこのような様々なモードを扱うための他のサブルーチンです。

ご覧のように、コーディングはとても単純で明白です。しかしそれはユーザに厳しい制限を課しているからです。コンピュータはいつも、少しのコマンドしか利用できない独自の"モード"にいます。それはプログラマの仕事を軽減しますが、ユーザにとってはストレスにつながります。Macintoshはそれを変革しました。

ご承知のとおり、Macintoshは"イベント駆動"です。

それは何でしょうか?次回のレッスンで明らかにしましょう。

次週

"OOP University"で引き続き、"イベント駆動"プログラミングの説明を行います。

Letters

ここに、新しいOOPシリーズの連載に興味のある人達から頂いた素敵なお便りがあります。まず始めに、Ray Doshさんからです。

Marcさんへ

どこかで、誰かがオブジェクト指向プログラミングのある学習書を推薦していたのを目にしました。私はそれを一冊購入し、まだ読み終わっていないのですが、本当に推薦できる本です。The Object-Oriented Thought Process (Matt Weisfeld著、Sams Publishing、2000年) はとても理解しやすいOOPの入門書で、プログラムの経験や知識を前提としないで書かれています。いくつかの例題はJavaで書かれていますが、Javaの知識は前提とされていません。またこの本は、あなたの読者にも役に立ちそうな統一モデル言語(Unified Modeling Language:UML)の入門書としても適しています(私はまだそれを試していませんが、直ぐに取り組みたいと思います)。

ありがとう、Rayさん!一読の価値がありそうですね。OOPをともに教え教えられる仲として、私はいまAmazonで注文しました。内容がふさわしい場合には、RBUにレビューを書こうと思います。

次に、Craig Brownさんからです。

はじめまして、Marcさん!これからのOOPの連載を楽しみにしています。私はBenさんと同じ立場にある者です。私が以前あなたにお伝えしたように、プログラム経験の殆どは、NCR大型コンピュータ独自の言語でした。それは実際に25年間使っていたので、かなり得意です。私はここ2、3年の間、RBを使いまわして、いくつか使えるプログラムも書いてみましたが、いざOOPとなるとまだ初心者のように感じています。

今週のRBUコラムに掲載されたBenさんからの2通目のお便りは、私をより彼に近い立場に置くことになりました。私には長年(余暇の時間に)取り組んでいるプログラムがあり、その目的はことばのパズルの制作補助です。私は、ブランクのパズルをキャンバスに描画することはできました!しかし、その印刷について調べたとき、壁に突き当たったように感じました。そしてまだ印刷はできません。この原因は、私がOOPを知らないことと関係があるかもしれないし、ないのかもしれませんが、これから明らかになるでしょう。

いずれにしても、従来のプログラマーが持つ、OOPの疑問点を明らかにしてくれることを楽しみにしています。

よい感謝祭をお過ごしください。

それでは!
Craig Brown

Craigさん、お返事ありがとう!連載が役立ったときは、忘れずに知らせてください。

次に、Joe Cabreraさんからです。

こんにちはMarcさん、

アーメン!これこそ私が本当に知りたかった事です。その場その場で格闘しながら、プログラムの例題によって学習するのが一番よいことだと私は思います。おぼろげながらもOOPの一般概念がありますが、はっきりと理解するにはまだ難航しています。あなたがその障壁を打ち崩してくれて、コーディングに飛び移ることができれば、私はいつまでも感謝するでしょう。

しかし本当は、もっと早くこれを書くべきでした。読者が意見を主張しなければ、あなたはどのように読者の最も必要としていることを知ることができるでしょうか?私自身、あなたの意図する読者にとって、これはあまりにも基本的なことではないかと考えていました。私がRBU Pyramidの事でかかりきりだったとき、私に必要なものは余りにも基本的すぎるのだと思っていました。

でも、あなたのお仕事に感謝します――私は毎週、RBUをチェックします。

それでは
joe cabrera

初心者と熟達プログラマーの両者に役立つように、RBUのバランスを保ち続けるのは大変です。RBUの観点は、紛れもなく、REALbasicを始めたばかりの人たちを対象としています。RBU Pyramidは巨大で複雑なプロジェクトで、私はそれをやって良かったと思っているのですが(プロジェクトが終了した現在では、ユニークな情報資源となって、沢山のテクニックが学べます)、これほど長いプロジェクトは、このRBUの体裁にはあまりに荷が重いと思いました。私は、ひとつか2つのテクニックを学ぶ短めのレッスンに重点を置こうとしています。願わくは、OOPの連載は医師の処方に沿ったものでありたいです。

医師といえば、次のお手紙はオーストラリアのドクター・Alexander G Bennettさんからです。

Marcさんへ

私は、つい最近に発行されたRBU #76を読みました―しばらく考えて―私はOOPに関する2つの基本問題と、なぜ私がこれほどRBが好きなのかを簡単に紹介しようと思いました。

しばらく前に私が、4DからRBとPostgreSQLに移植していた診療記録/支払いシステムのことについて手紙を書いたのを覚えているかもしれません。それは今、順調に進んでいます。

原理 #1:

構成: 入れ子のフォルダー・システム――実際は不細工ですが――を利用した位置の構造化やコードへのアクセスの能力は非常に複雑なアプリケーションを堅実に構築するために重大なものでした。

原理 #2:

クラス: これらは最も素晴らしいいくつかのアイデアです

RBは複雑です―おそらくプログラマーにとって時折不要なほどに―そしてそれを学ぶために覚悟が必要ですが、見返りはとても大きいです。他のプログラミング環境と同じように、たくさんの"ひとりよがり"と特有の言い回しがあります。そしてIDEはひどく不安定です。しかしそれでもRBは、私の使っていたいくつかのプログラム環境の中でも最も楽しいものです。

ちょうど購読を始めたばかりのマガジンとRBUのお仕事に感謝します。OOPについてのレクチャーにはとても興味があります。

それでは

Alexander

Alexanderさん、どうもありがとうございます。あなたの態度はすばらしいですね。プログラムのバックグラウンドが少しある人にとって、REALbasicは驚くべきものでしょう。しかしあなたが言うように、それは常に進化しています(そしてもちろんREAL Software社に感謝します)。

REALbasicで私が好きなことの1つは、OOPを使うように強要しないことです。つまりたくさんの新しい概念を学習しないでも、取り組むことができるわけです。もちろん、その背後にはたくさんのOOPが存在するし、OOPの基盤はありますので、その利点を利用したいならば、それは少しずつ取り組むことができます。私の書く新しいプログラムのすべてには、もっともっと多くのOOPテクニックを盛り込みます。結果的に、おそらく適切なOOPアプリケーションを手に入れることになるかもしれません!

皆さん、お手紙どうもありがとうございました。OOPシリーズから多くを学んでください。その過程で私もたくさんのことを学ぶつもりです!


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

INDEXに戻る