.NET Framework プログラミングの特徴

2000年度 研究発表会 《おまけ》

2001/02/24 山本
updated: 2001/03/14

「.NET」 という言葉

.NET
単に 「.NET」 と言うときは、 「.NET 戦略」 を指す。 すなわち、 Microsoft の戦略を表す言葉で、 一言で表すと 「アプリケーションから Web サービスへ」 となる。
.NET Framework
.NET 戦略にふさわしい、 次世代 OS を意味する。 最初は、 Windows の上に .NET Framework という 「皮」 を被せて実現する。

.NET Framework は 新しい OS

.NET Framework は、 Windows の上に被せる単なる「フレームワーク」ではない。 Microsoft の狙いは、 次世代 OS への移行にある。

MS の OS 進化の概要MS の OS 進化の概要

1980年代は MS-DOS の時代であった。 1990年代は、 大雑把にくくれば Windows の時代と言えるが、 いきなり MS-DOS が無くなったわけではなかった。 MS-DOS の上に Windows を載せて、 進化させてきたのである。 まずは 16bit の Windows 3.x を載せ、 それを 32bit の Windows 9X に進化させつつ、 完全な Windows である Windows NT を開発した。

ようやく MS-DOS から Windows への以降が完成しようとしている現在、 Microsoft は、 すでに次の OS への移行を始めた。 それが .NET Framework である。

なお、 .NET Framework の最初のバージョンは、 Windows XP の出荷と同時期 ( MS 曰く 2001年末まで) に利用できるようになる。 開発のためには、 .NET Framework の β2 ( MS 曰く 2001年前半 ) が利用できるとされている。

OS が変わる = プログラミングが変わる

.NET Framework は、 次世代の新しい OS なので、 そのプログラミング手法も、 まったく新しいものに変わる。

x86 から MSIL へ
コンパイルされたプログラムは、 MS-DOS 時代から続いてきた Intel の x86 CPU のためのマシン語ではなく、 CPU に依存しない MSIL になる。 ( MSIL は、 実行時に CPU 固有のマシン語に JIT コンパイルされる。 なお、 このジャスト・イン・コンパイラのことを JITer [ジッター] とも呼ぶ。 )
Windows API から CLR
16bit 〜 32bit と進化してきた Windows API だが、 あまりにも複雑怪奇になってしまった。 .NET Framework では、 まったく新しく設計されなおした CLR (Common Language Runtime) を呼び出すことによって、 プログラミングしていく。 言い換えれば、 .NET Framework のプログラミングを極めるということは、 CLR を極めることだといえる。
COM コンポーネント から BCL
OS に含まれるさまざまなコンポーネントが、 COM コンポーネントから、 CLR 上に構築された BCL (基本クラスライブラリ) に変わる。 この BCL は、 MSIL バイナリだけで (ソースコード無しでも) 継承できる、 という特徴を持つ。 例えば、 Windows 上でフォームを開くプログラムは、 BCL の Windows Forms (System.WinForms.Form) を継承してコーディングする。
オブジェクト指向が必須
必ず BCL を継承してプログラミングしなければならない。 コンソールに 「Hello, World!」 と表示するだけのプログラムさえも、 System.Object を継承して書かねばならない。 すなわち、 オブジェクト指向設計・コーディングを身につけておく必要がある。
言語間の垣根が低くなる
.NET Framework のプログラミング言語は、 CLS という規格を満たしていなければならない。 そのため、 言語間の垣根が低くなる。 言語によって出来ること・出来ないことがあるのは確かだが、 例えば、 C# で書いてあるクラスを VB.NET で継承し、 できた新しいクラスを Perl.NET から呼び出す、 といったことが自由に出来る。
再利用性の向上
オブジェクト指向の強制と、 バイナリレベルの継承、 そして CLS 準拠の 3点により、 オブジェクトの再利用がしやすくなった。
レジストリ から .cfg ファイルへ
.NET Framework には、 レジストリは存在しない(すくなくとも、 プログラマから簡単にアクセスできる範囲には。) いままでレジストリに保存していたような情報は、 プログラム本体に直接埋め込む (アセンブリのマニフェスト) か、 .cfg ファイルというテキストファイルに記述する。 これにより、 配布パッケージとインストーラの作成が、 格段に簡単になる。
アセンブリのバージョン管理
共有アセンブリは、 複数のバージョンのものを同時にシステムに保持できる。 また、 共有アセンブリを利用するプログラム側では、 必要とする共有アセンブリのバージョンを実行時に必ず指定するようになっている。 このため、 DLL のバージョンのアンマッチによってアプリケーションが動かないといった、 いわゆる 「DLL 地獄」 は解消される。
インターネット標準のサポート
.NET Framework は、 インターネット接続だけでなく、 XML や SOAP といったインターネット標準もサポートしており、 例えば SOAP を使ったプログラムを簡単に作成できる。

新言語: C#

Microsoft は .NET Framework 用に「C# (シーシャープ)」 という新しいプログラミング言語を投入してきた。

.NET では どの言語でも同じ

.NET Framework ではどの言語を使っても、 できることは (だいたい) 同じである。 それは CLS にのっとっているからである。

※ CLS にのっとっていないコードを記述することも、 言語によっては可能。 その部分は、 x86 ネイティブなマシン語に変換される。 なお、 CLS にのっとっているコードを Managed Code (管理コード) と呼び、 そうでないコードを Unmanaged Code (非管理コード) と呼ぶ。

Windows と比べてみると、 次のようなイメージになる。

Windows と .NET Framework でのプログラミングWindows と .NET Framework でのプログラミング

Windows では、 開発言語が違えば、 出来上がったプログラムも違い、 プログラムが OS にアクセスするアプローチも異なっていた。 例えば、 VB で開発すると、 VB ランタイムの利用が基本となり、 VC++ では、 MFC ランタイムが基本となってしまう。 さらに、 直接 API を呼び出したり、 COM コンポーネントを利用したりすることもできるが、 これらすべては利用方法が異なり、 プログラミングは煩雑なものになってしまった。

これが .NET Framework では、 すっきりしたものに変わる。 言語が C# だろうと Managed C++ だろうと、 あるいは VB.NET や Perl.NET や COBOL.NET であろうと、 出来上がったプログラムは、 CLS にのっとった MSIL になる。 OS にアクセスするアプローチは、 CLR と BCL (基本クラスライブラリ) であるが、 どちらも利用方法は同じである。 すなわち、 どの言語であろうと、 文法は違うものの、 プログラミングの内容は同じになる。

VB.NET か C# か

現在、 C++ が得意な人は、 .NET Framework では C# に進むのが得策であろう。 文法は C++ に似ている上にやさしいし、 Managed C++ で書くより C# で書いたほうがはるかに効率がよい。

では、 現在 VB が得意な人はどうすべきか。 やはり、 C# に進むほうがよい。

VB.NET は VB ではない
.NET Framework 用の VB は、 VB.NET (あるいは、VB7) と呼ばれる。 文法は確かに VB を拡張したものではあるが、 実体は C# であるといって過言ではない。 C# を使える人は VB.NET のソースを理解できるが、 VB の知識では VB.NET のソースを理解できない。 なぜなら、 .NET Framework でプログラミングするということは、 CLR (および BCL) の使い方を覚えることだからである。 すなわち、 VB.NET を覚えるのも C# を覚えるのも、 その労力にほとんど差は無い。
VB.NET には出来ないことがある
C# では、 いざというときには Windows API を直接呼び出すことができる。 VB.NET は (少なくとも β1 では) 出来ない。
C++ も VB.NET も Java も分かるようになる
VB のスキルの上に C# を覚えれば、 VB.NET での文法拡張を覚える (しかも、 字面を見ればだいたい見当がつく) だけで VB.NET も使える。 また、 ポインタを理解すれば、 コーディングは難しいとしても、 世にあふれる C/C++ の解説書は読めるようになる。 もちろん、 Java にも、 すぐに手が届く。
※ 設計手法やアルゴリズムなどに関する書籍がたくさん出版されているが、 多くは C/C++ で解説されている。 このごろはある程度 Java も増えてきた。