私は最近，地方の大学の公開講座でVisual Basic（VB）の講師を引き受けた。前任者が使っていたカリキュラムを手に入れて，私はすぐに2つの問題に気がついた。1つは，内容が時代遅れでVisual Studio 2005にそぐわないこと。もう1つの，より重要な問題は，VB 6.0からVB .NETへの移行に取り組む代わりに，VB 6.0とVB .NETを比較して相違点を検討するのに大幅な時間を費やしていることだ。私の意見では，こうした比較ばかりしているためにVB .NETの採用が遅れたのである。またこのことが原因で，VB開発者が.NETの開発をする際にVisual C#へ移行した例もある。

　VB開発者のコミュニティは概して，VBがどこに向かっているかよりも，これまでどこにいたかにとらわれ過ぎる傾向があった。例えば約1年前に，多くのVB 6.0開発者が.NETの採用とVB 6.0のサポートの段階的廃止について反乱を企てた。この反乱に加わった人たちの中には，かつてVB .NETの開発中に下されたいくつかの決定に影響を与えた人々もいた。いくつかのケース，特にオブジェクト指向関連のキーワードについて，この影響はVB .NETの言語仕様に害をもたらした。

　.NETの基本的なコンセプトの一つは，それがオブジェクト指向環境であることだ。VB，Visual C#，Visual C++，Visual J#はいずれもオブジェクト指向のパラダイムに従う。Visual C#/C++/J#の開発者のほとんどは，抽象クラス/メソッド，コンストラクタ，オーバーライド，オーバーロード，スタティック・メンバー---といったオブジェクト指向プログラミングの用語に親しんでいる。

　しかし，VBだけを学んだ.NET開発者は，これらの鍵となる用語のうちオーバーライドとオーバーロードの2つしか使わない。その結果，VB開発者はほかの言語の開発者が日常，仲間内での議論，就職時の面接，一般的なプログラミングの授業，あるいはそのほかの場で使っているいくつかの鍵となる用語を知らないままでいる。

　用語の違いなどささいな問題に過ぎない，というのは誤りだ。不幸な結果も生じ得る。例えば，私は米国のシステム・インテグレータ企業であるInterKnowlogyで採用面接を担当しており，実際に何人ものVB開発者が抽象クラスの目的のようなことを尋ねたときに誘導が必要であるのを見てきた。私はそれを気にしないが，私とともに面接をした筋金入りのVisual C#開発者たちは，応募者の技術的能力をいつも気にかけていたようである---不公平な判断だが，実際に起きていることだ。

　そこで，私の基本に立ち返る記事の一環としてオブジェクト指向のキーワードについて述べたい。まずは「abstract」というキーワードから始めよう。このキーワードはほとんどのオブジェクト指向言語で共通である。読者は米MicrosoftのWebサイトにあるVisual C#向けのドキュメントに優れた定義を見出すことができる。

　この定義は，最初の1文で必要なことをすべて述べているので，ここに引用する——「abstractキーワードを使えば，継承することだけを目的としたクラスやクラスのメンバーを定義できる」。オブジェクト指向開発の経験者ならご存知のように，これは抽象クラス（abstract class）のインスタンスを作れないことを意味する。抽象クラスの限られた実装を利用するためには，抽象クラスを継承した独自のクラスを定義しなければならない。

　では，MicrosoftのVBチームはabstractというオブジェクト指向言語で共通のキーワードの代わりにどのようなキーワードを選んだのか。彼らは“MustInherit”を選んだのである。一見，MustInheritは極めて明快なキーワードのように見える。ただし，それもVBの言語リファレンスを見るまでのことだ。

　言語リファレンスの「Remarks」節の最初には次の文がある——「基本クラス (抽象クラスともいう) の目的は，それから派生したすべてのクラスに共通する機能を定義することである」（読者が私にメールする前に断っておくが，私はこの文が技術的な誤りを含むことは分かっている。これだとすべての基本クラスが抽象クラスであるように読めるからである）。

　第1の問題は，VBのMustInheritの定義がVisual C#のabstractの定義と一致しないことである。この問題は，Visual C#ではabstractというキーワードをクラスとメソッドの両方のレベルで使うのに対し，VBの場合メソッド・レベルではMustOverrideという別個のキーワードを使うという事実のために，さらに厄介になっている。

　第2の問題は，VBのドキュメントがMustInheritキーワードの使い方を説明しようとする際に伝統的なabstractキーワードと結びつけていることである。だとすれば，そもそもなぜキーワードを変える必要があるのか。

　理想的には，すべての.NET開発者が“共通語”を話せるのが望ましい。しかし実際には，.NET開発者は双方のオブジェクト指向言語のキーワード---VBのキーワードとほかのほとんどのオブジェクト指向言語のキーワード---の集まりを，どちらが専門であるかにかかわらず学ぶ必要がある。VB開発者をオブジェクト指向開発に移行させることへの関心は大いにあったが，後知恵で言えば，MicrosoftのVBチームはオブジェクト指向言語で共通に使われるキーワードをそのまま使うべきであった。そのほうがVB開発者のためになったはずだ。

　では，すべての.NET開発者が共通語を話せるようにするために，これから何ができるのか。私は，VBチームは今後のVBのリリースで，たとえVB開発ではオプションに過ぎないとしても，ほかのオブジェクト指向言語で共通のキーワードも併せて利用できるようにすべきだと思う。そうすることで，VB開発者は共通の用語を使用し，移行し始めることができるようになる。

　残念ながら，キーワードを両方使えるようにすることは常にうまくいくとは限らない。例えば，C#ではコンストラクタをクラスと同名のメソッドとして定義するが，VBではNewという名前で定義する。その一方で，C#では基本クラスのメンバーを派生クラスで隠すのにnew修飾子（new演算子とは別）を使うのに対し，VBではShadowsを使う。とはいえ，オブジェクト指向開発においてShadows/new修飾子を使うことはほとんどない。もしVBでほかのキーワードをすべて併用できるようになれば，オブジェクト指向の概念を.NETの中で横断的に議論する際にはるかに混乱が少なくなるだろう。

後編へ