Visual Basic 業務アプリ構築法 第3回

オブジェクトとプロパティ、メソッド
長谷川裕行
1998/06/06

長谷川 裕行 (はせがわ ひろゆき)
有限会社 手國堂 代表取締役
http://www.hirop.com/
テクニカルライターとして活躍。プログラミングに関する著書多数、DB Magazineなどにも多くの記事を提供している。

VBは難しくない

VBによるアプリケーション開発は、大きく外観のデザインと内部処理の定義の2つの段階に分かれます。すべて統合環境の中で行われ、別々の工程として捉える必要はありません。見た目と内部の動作を同時に定めていける点が、VBの特徴であり利点です。


- 最後はやはり「文字」 -

VBはGUI、つまりグラフィックスを中心とした操作環境によって、アプリケーションを開発できるツールだと捉えられています。そのためVBによる開発手順は、従来の文字中心のアプローチとは大きく異なっているように感じられます。

VBが登場して随分経ちますから、今では「初めて触ったOSがWindowsだった」、「初めて手にした開発ツールがVBだった」という開発者も多くなっています。そういう人たちにとっては、「従来の文字中心のアプローチ」なんていう表現はピンとこないと思います。
しかし、いくらGUIが発達したとはいえ、まだ「プログラミングのすべての工程から文字を排する」ことはできません。マウスのドラッグで構築できるのは、実のところプログラムのごく一部です。
GUI環境とはいうものの、グラフィックスの要素がこれまで以上に入り込んでいるだけのことであって、最終的にはコード、つまり文字による制御がプログラムの根底にあることは変わりません。



- ウィンドウとコードの関係 -

VBでは、以下のような手順でプログラムを作っていきます。

(1)ウィンドウをデザインする
(2)ソースコードを入力する

つまり、最初にウィンドウにコマンドボタンやテキストボックスなどのコントロールを配し、ユーザーインターフェースを構築してから、それに対応した処理をコードとして記述していくのです。
ユーザーインターフェースをコードではなくGUIによって作成できることが、VBの大きな特徴であり、利点です。しかし、ソースコードの入力に関する基本的な捉え方は、従来の手法と大きき変わるものではありません。
結局、GUIによってデザインされたウィンドウとプログラムの本質部分であるソースコードとの「関係」だけが、これまでの作法と大きく異なる部分なのです。



- VBとブラックボックス -

例えばDOSのプログラミングでは、プロンプトや入力枠などの視覚的な要素も、すべてソースコードによって画面に表示し、制御していました。とは言え業務用アプリケーションの場合は、画面入力や帳票出力などに専用のライブラリを使っていたはずなので、実際に入力枠を表示するためのコードを記述した人は少ないはずです。
かつて筆者は、DOS用C言語のテキストウィンドウライブラリをアセンブラで作成したことがありますが、画面上ではカラフルなウィンドウがオープンしていても、その元になるのは

MOV BX, _ColorCode
XCHG AX, BX
ADD AX, __ClrImd
     :
なんていう記号の羅列でしかありません。
これらアセンブリ言語のコードが何をしているのか、ライブラリを使って画面設計をしていく段階では一切気にかける必要はありません。ライブラリに用意された機能はブラックボックスであり、その働きと使い方さえ知っていれば利用できます



- 既存の機能を組み合わせる -

Windowsも、巨大なブラックボックスです。それはアプリケーションを実行するための環境であると同時に、アプリケーションを開発するための基礎環境でもあります。Windowsで各種コントロールを貼り付けて画面を作り、アプリケーション独自の機能をソースコードで記述していく――というアプローチ自体は、実のところ出来合いのライブラリを使って旧来のプログラミングを行う場合と、ほとんど大差ないものです。
VBでは画面のデザインやソースコードの入力が統合環境化されているため、テキストエディタでシコシコとソースコードを入力するというイメージはあまりありませんが、最も重要なことが「既存の機能をうまく組み合わせていく」ことである点は、従来の手法と何ら変わることがないのです。
既存のライブラリを使って入力画面を作り、そこから得たデータをプログラムの本質部分に渡す――という形と、GUIによってデザインしたウィンドウにコードによるプログラムの本質部分を関連付けていく――という形に、大きな相違はありません。つまりVBの作法は、見た目ほど革新的なものではないのです。



フォームとコード

VBでは、作成するアプリケーションをプロジェクト単位で管理します。プロジェクトの中には、フォームオブジェクトとコードオブジェクトが存在します。この2つが、VBで作成するアプリケーションの基盤となります。


- フォーム -

Windowsアプリケーションでは、アプリケーションは必ず1つ以上のウィンドウを持ちます。VBでウィンドウをデザインし管理するオブジェクトが、フォームオブジェクトです。

フォームにはコマンドボタンを始めとする様々なコントロール類を貼り付けることができ、それによってアプリケーションはユーザーとやり取りを行います。フォームは、ユーザーインターフェースの基盤です。


- コード -

文字によって記述するソースコードを管理します。
Windowsアプリケーションは、実際には以下のような過程を経て初期化されます。
(1)アプリケーションのウィンドウが生成される
(2)ウィンドウ内のコントロールが生成される
この2段階を経て初めてインターフェースか確立され、それ以降ウィンドウ内のコントロールとコードとが有機的な連携をとることになります。当然この2段階は、コードによって記述される部分です。
しかしVBでは、このアプリケーションの初期化過程はすべてVBの側で行われるため、プログラマーは「既に生成されたフォーム上のコントロールをどのように扱うか」だけをコードにすればよいことになります。



- 3つのウィンドウ -

VB統合環境のインターフェースは、大きく3つに分かれます。フォームウィンドウ、コードウィンドウ、プロパティウィンドウです。


フォームウィンドウ

フォームをデザインするためのウィンドウです。ツールボックスからコントロールをドラッグして貼り付け、位置やサイズ、名前などを決めてユーザーインターフェースの外観を作ります。
コントロールもオブジェクトであり、フォームはコントロールを集めて配置したオブジェクトということになります。



コードウィンドウ

フォームやコントロールの制御を行うためのプログラムを記述します。コマンドボタンがクリックされたら、内部でどのような処理をするか――といった具合に、コントロールの受け取ったイベント単位での記述となります。


プロパティウィンドウ

プロパティ(property)は「属性」などと訳されます。要するに「オブジェクトの持つ性質」のことです。
コマンドボタンの例で言えば、名前、サイズ、表示位置などです。オブジェクトごとに様々なプロパティがあり、それらに対して値を設定することでオブジェクトを定義していきます。



- コードフォームの微妙な関係 -

VBでは、フォームやコントロールなどのGUIパーツは、コードと直結している訳ではありません。
先述したようにウィンドウとコントロールの生成過程はプログラマーの手を経ることなく処理されるため、コードウィンドウで記述されるコードは「それらが生成されたあとの処理」となります。
コントロールが生成されたあとに必要な処理とは、簡単に言えば「コントロールがユーザーによって何らかの操作を受けたときの処理」です。ユーザーがテキストボックスに値を入力したり、コマンドボタンをクリックしたりすると、コントロールはイベントを発生します。そのイベントはWindowsを経てVBに渡され、さらにVBで作成したアプリケーションへと伝わってきます。
Windowsアプリケーションはユーザーの操作などによって発生するイベントを元に、それに対応する処理を記述することで出来上がっていく――と説明しました。この構造をGUIによる開発環境にそのまま持ち込んだのが、VBの統合環境です。



- プロシージャ -

フォームウィンドウで貼り付けたコマンドボタンをダブルクリックすると、コードウィンドウがオープンします。そこには「Sub Command1_Click()」などというソースコードが、予め記述されています。これは「"Command1"という名前のコントロール(コマンドボタン)がクリックされたときに実行される処理」を示しています。
このように、VBで用いるソースコードは、オブジェクトの受け取るイベント単位に分かれています。このイベント単位の小さな処理を「プロシージャ」と呼びます。プロシージャはイベント単位であるとは限りません。下請け処理のための小さなプログラムもプロシージャです。VBによるプログラムはプロシージャの集まりとなります。

この点が、長いソースコードを見慣れたプログラマーにとって戸惑う要因となっているようです。プロシージャの概念はC言語の関数と同じですが、COBOLなどに慣れた身から見れば、「全体の流れが見渡せない」ということになります。



- 出発点はフォーム -

VBでは、プログラムの出発点はフォームにあるのだと捉えておきましょう。フォーム上のコントロール(の発生するイベント)から、小さなプログラムが枝のように生えているのです。従って、当然幹の部分は、コントロールの存在するフォームということになります。
このようにVBのコードウィンドウでは、コントロールの受け取るイベントごとにソースコードを記述していく形となります。そのため、アイコンがクリックされたときとダブルクリックされたとき、テキストボックスがクリックされたときと値が入力されたときなど、1つのコントロールに対して受け取るイベントごとに異なる処理を記述できます。



Windowsとオブジェクト指向

「オブジェクト」という言葉が何度も登場しました。オブジェクトとは何でしょう? VBは「オブジェクト指向言語ではない」とも言われます。その点も考えてみましょう。


- オブジェクトとは? -

オブジェクト(object)は「対象物」などと訳され、コンピュータでは操作の対象となる「物」のことを示す言葉です。コンピュータのディスプレイにはアイコンやウィンドウ、ボタンなどが表示されますが、これらは実際に存在する窓やボタンではありません。すべてメモリ上の電子的な情報です。
プログラムで扱うファイルにしても、現実の紙を綴じたファイルではなく、単にディスクに記録されたデジタルデータの集合を、現物のファイルのように扱っているだけです。  ディスプレイ上に表示された窓やボタン、ウィンドウの中に表示されたファイルの中身などは、実際には現物の窓やボタン、紙のファイルのような性質を持っている訳ではありません。が、ユーザーは窓を開いたり、ボタンを押したり、ファイルを開いたり中を書き換えたりできます。
電子的な情報である窓やボタンやファイルに、現物の窓やボタンやファイルの持っているものと同じ「性質」を与えてあるために、それら仮想的な「電子の情報」をあたかも現実に存在する「物」のように扱えるのです。



- 電子の情報と現実の「物」 -

コンピュータでいう「オブジェクト」とは、このように電子的な情報を人間が把握し扱いやすいように、それに現実に存在する「物」としての性質を与えたものです。
ファイルを削除する場合、ファイルのアイコンを「ゴミ箱」にドラッグします。しかし実際には、メモリ上のファイルの情報がメモリ上のゴミ箱を表す情報の中に送り込まれる訳ではありません。OSを介してハードウェアが制御され、ディスク上のファイル管理情報に削除の印を付ける――といった処理が行なわれています。
しかしこういった機械の内部を意識した操作は、一般ユーザーにはなかなかなじめるものではありません。そこでコンピュータで扱う種々の情報を、ファイルのアイコンやゴミ箱という日常見慣れた「物」に置き換えているのです。これを「メタファ」と言います。
Windowsは、本来ならメモリ上の複雑な仕組みの中で電子的に存在する情報群を、様々な現実に存在する「物」のメタファに置き換えることで、操作とプログラミングを容易にしています。



- メタファとオブジェクト -

このメタファとして置き換えられた「物」がオブジェクトです。オブジェクトには性質があります。コンピュータのあらゆる資源をオブジェクトとして扱うプログラミング手法――いわゆるオブジェクト指向プログラミングでは、オブジェクトに与えられた性質を操作することで、様々な処理を進めていきます。
ダイアログボックスをオープンしてユーザーに設定を委ねる処理では、本来的にはメモリ上に画像や受け取るべきデータの保存領域などを用意し、ディスプレイに画像を表示したり、受け取ったデータを保存領域に転送したりする必要があります。
が、ダイアログボックスというオブジェクトをを用意すれば、こういった過程を「ダイアログボックスを開く」「オプションボタンの選択結果を取得する」といったわかりやすい行為に置き換えて考えることができます。これが、オブジェクト指向のメリットです。



- VBはオブジェクト指向?! -

オブジェクト指向プログラミング言語は、コンピュータの資源をオブジェクトとして扱えるだけではなく、プログラマーが新たなオブジェクトを作成できることが必要です。また、プログラム構築の本質部分が、作成したオブジェクトを組み合わせていくことで成り立っていることも、重要な特徴です。
その点においてVBは、完全なオブジェクト指向言語とは言えません。VBは確かにユーザー定義コントロールやActiveXコントロールを作れますが、それらはあくまで補足的な機能であって、プログラマーがオブジェクトを設計しなければアプリケーションが作れない――という構造ではないからです。
ただ、オブジェクト指向をマスターする上で不可欠な、オブジェクトの本質的な部分を理解するには最適です。オブジェクトの本質的な部分は、各オブジェクトの性質の「違い」であり、性質の異なるオブジェクト同士の関連付けにあります。
オブジェクト指向プログラミングは、詳しく解説していくと膨大な情報量となってしまいます。実のところ、VBを理解する上でオブジェクト指向はさほど重要な概念ではありません。あまり深く考えず、次に取り上げるオブジェクトの性質――プロパティとメソッドに関して簡単に理解しておけばよいと思います。



プロパティとメソッド

メタファとして扱われるオブジェクトは、単に「名前の置き換え」だけを示しているのではありません。「ゴミ箱」のメタファは、「そこにアイコンを入れると削除される」という「動的な性質」を暗に示しています。ダイアログボックスにはサイズや位置などの性的な性質の他に、「開く」という動的な性質も持っています。
「物」には静的な性質と動的な性質があります。前者をプロパティ、後者をメソッドと呼びます。



- プロパティ -

プロパティは、オブジェクトの静的な性質の総称です。ここで言う「静的」とは「恒常的な」(static)という意味ではありません。「形態の変化を伴わない」(passive)という意味です。プロパティという性質があるのではなく、オブジェクトには「横幅というプロパティ」や「名前というプロパティ」が用意されているのです。
プロパティを変更すると、それに対応した静的性質が変更されます。ウィンドウの「高さ」のプロパティを50から100にすれば、ウィンドウの高さは画面上で50ピクセルから100ピクセルに変化します。
また、プロパティは値を取得することもできます。あるテキストボックスに設定された名前を知りたければ、「名前」プロパティを参照すればいいのです。
名前はどんなオブジェクトに共通するプロパティですが、高さや幅は画面上に表示されるウィンドウ、ボタンなどにしか存在しないプロパティです。また「入力可能な文字数」というプロパティは、文字を入力するテキストボックスなどには存在しますが、コマンドボタンには存在しません。
このように、オブジェクトによってプロパティの種類は異なります。



- メソッド -

メソッドは、オブジェクトの動的な性質、機能の総称です。ここで言う「動的」とは「流動的な」(dynamic)という意味ではなく、「活動を伴う」(active)という意味です。
オブジェクトには「開く」「隠す」「一時的な作業領域を設ける」といった動作を示すメソッドが用意されています。
メソッドは設定するのではなく実行するものです。その意味で、命令の一種と捉えられます。が、プログラミング言語固有の処理命令ではなく、オブジェクト自身が持つ動作を示す命令である点が、一般的なプログラムでいう命令とは異なります。
プログラムに対して(つまりコンピュータに対して)「ウィンドウを開け」と命令するのではなく、既に存在するウィンドウというオブジェクトに対して「"開く"という動作を行う」命令を与えるのです。
メソッドもプロパティと同じように、オブジェクトによってそれぞれ異なっています。ウィンドウには「開く」「閉じる」というメソッドがありますが、これはコマンドボタンにはありません。
また、メソッドを実行するとプロパティの値が変化します。メソッドとプロパティは無関係ではありません。アイコンを「右に200ピクセル移動する」というメソッドを実行すれば、そのアイコンの水平位置を示すプロパティが200増加します。



- プロパティとメソッドがVBのツボ! -

プロパティとメソッドは、Windowsプログラミングをマスターする上で必ず習得しなければならない概念です。と言うより、「Windowsプログラミングの本質部分はプロパティとメソッドの操作に集約される」と言っても構わないでしょう。
従来のプログラミング手法に慣れていると、プロパティとメソッドによってオブジェクトを操作する――ということのイメージをつかみにくく、意味がよく分からないままにプログラムしてしまうことがあります。この点には十分に注意し、具体的なメカニズムではなく「イメージ」として把握しておいてください。
プロパティは人間で言えば「氏名」「身長」「体重」「性別」「住所」などの個人データに相当します。一方メソッドは「立つ」「座る」「歩く」「眠る」「食べる」などの所作に相当するものです。
ある人物の「氏名」プロパティが「矢沢」であるとしましょう。矢沢さんの「働く」メソッドを実行すると、「体重」プロパティが減少します。そこで「食べる」メソッドを実行して食事させれば「体重」プロパティは復活します。「歩く」メソッドを実行すれば「現在位置」プロパティが変更されます。 プログラムの便利なところは、「現在位置」プロパティを変更すれば「歩く」メソッドを実行しなくても、超能力者のように一気に別の場所に移動できることです。矢沢さんの「性別」プロパティを「男」から「女」に変更すれば、オカマになるかもしれません(現実はどうだか知りませんが…)。
Copyright © GrapeCity inc. All rights reserved.