「うーん。ということは，Visual Basicが門戸を開いたってことになるんですかね」
「あれ。不満かな」
「だって，なんちゃってはなんちゃってで，オブジェクト指向じゃないんじゃないですか」
「それはまあそうとも言えるけど，コンポーネントによるソフトの再利用を現実のものにした，っていうのはとても重要なことなんだよ」
Visual Basicは広義に解釈すれば，オブジェクト指向言語の一つと言える。だが一般にオブジェクト指向言語と呼ぶのは，次の三つの条件を満たしているものだ。(1)外部からのアクセス制御が可能な（カプセル化可能な）クラス，(2)継承によるクラス定義の拡張，(3)同一メッセージに対して，オブジェクトによって振る舞いを変える多義性（polymorphism），である。最初のバージョンでは，Visual Basicは現在のVisual Basic Scriptと同じで，既存のオブジェクト（コントロール）を操作することしかできなかった。日本で最初に登場した2.0版は，オブジェクト指向化の第一歩でもあった。Object型を導入したのである。この型の変数は，実行時に実際のオブジェクトを関連づける。したがって多義的な振る舞いが実現できるのである。
そしてコンポーネント開発機能を備えたバージョン5.0で，「クラス」の概念を導入した。ただしVBにおけるクラスは，継承機能のないクラスである。元々ActiveXコントロールを開発するために導入されたもので，完全なオブジェクト指向を目指したわけではないからだ注5）。
Visual Basicの存在感は大きい
ただVisual Basicのソフトウェア開発への貢献は，決して小さくない。その第一が，コンポーネントに基づくソフトウェア開発を推進したことである。
 |
| 図5●ビジュアル開発ツールにおける開発手順 |
改めてVisual Basicの開発スタイルを見てみよう（図5[拡大表示]）。まずは基本のユーザー・インタフェースを提供するフォームに，適宜利用するオブジェクトを配置する。次に表示などを整えて，イベント・ハンドラを記述すれば完了というステップである。このときポイントとなるのが，ユーザー・インタフェースに関連しないコンポーネントも置けること。これは最初のバージョンからで，例えばタイマー制御用のコンポーネントなどが利用できた。実はこのことが，それまであったいわゆるGUI構築ツールと一線を画しているのである。単にGUIを作るだけではなく，まともにロジックを記述していくには，それなりのサービス・ルーチンを提供していなければならない。その一例がタイマー・コンポーネントである。タイマーなどは，ユーザーがBasic言語を使って別途作成できるものではない注6）。だから専用の制御文などの形で使えるようにするというのが，それまでは一般的だった。これをコンポーネントの形で，拡張可能にしたわけだ。
コンポーネントとして独立した部品にまとめることによって，再利用性は飛躍的に向上した。コンポーネントにまとめることによって，複雑なクラスの関連やオブジェクト間の参照関係などが，すべてコンポーネントに隠蔽されるようになった。後はその外部インタフェースの規約さえ明確になれば，利用できるのである。
「なんちゃって」ゆえにシンプル
では，「なんちゃって」であるメリットはあったのだろうか。Visual Basicの場合，同じことを実施したときのコード量が少なくて済む点だ（リスト）。オブジェクト指向言語としてではなく，独自の機能を盛り込んだ結果，余計なコードを隠蔽できたと言える。例えば同じアプローチのツールであるDelphiと比べると，余計なクラス定義などがないぶん見通しはよい。実際のコード量はほとんど変わらないため，大した意味はないと思われるかもしれない。ただ慣れていないユーザーにとっては，わけのわからないコードが出てくるよりは安心だろう。
オブジェクト指向らしさという点ではVisual Basicには不満がある。だが，一度作ったシステムを，その後別のプロジェクトで再利用するならばクラスを定義するべきだが，そうでないのならばスクラッチ・アンド・ビルドに徹する，というのがVisual Basicの発想である。そのやり方はあながち間違いだとは言い切れないのである。
「再利用って，ボーナスだったんじゃないんですか」
「クラスの単位で再利用しようとするととても難しくなる。だから，それぞれ独立した一つのモジュールとなるように設計すれば，再利用もしやすくなるということだね」
「でもそれって，簡単じゃないのでは」
「その通り。ある程度同じものを作って，どこが共通部分か認識できないとダメという話もある。つまり経験が必要ってこと」
「あーあ。道は遠いなぁ（はぁ）」
