マイクロソフトの開発ツールVisual Studio .NETが出荷されてから約半年が経過した。本サイトをご覧の方々の中には，すでに開発に使用している方もいらっしゃるだろう。記者が担当する日経ソフトウエアの記事でも取り上げる機会が増えている。
触ってみて感じるのは，対抗馬であるJavaのクラス・ライブラリ[用語解説] との設計思想の違いである。Javaのクラス・ライブラリが素直にオブジェクト指向にのっとって設計されているのに対し，.NET Frameworkのクラス・ライブラリは，オブジェクト指向的な自然さ，美しさよりも，初心者にとっての覚えやすさ（習得しやすさ）を重視したように見える。
ストリーム系のクラスの構成を例にとると，Javaはバッファリングの有無やランダム・アクセスが可能かどうか，などで細かくクラスを分けており，その数は抽象クラスも含めて60以上にのぼる。一方，.NET FrameworkのSystem.IO名前空間が用意するストリーム系のクラスは12個しかない。
ストリーム系のクラスを使ってファイルやネットワークなどと入出力を行う場合，Javaならランダム・アクセスを行うかどうかで利用するクラスが異なるが，.NET FrameworkならFileStreamクラスで両方に対応するようにしている。バッファリングなどを行う場合も，いくつものクラスを組み合わせて使う必要はない。
覚えやすさと，オブジェクト指向本来の自然さ，美しさは，どちらが優先されるべきなのだろうか。もちろん，これが両立できればいうことはないが，現実のクラス・ライブラリは，両者のバランスを考えて設計していかざるを得ない。では，.NET Frameworkは，最適なバランスを実現しているだろうか――。記者は今，この点について頭を悩ませている。
クラス・ライブラリの習得は，言語の習得よりはるかに時間がかかる
オブジェクト指向開発の経験が長い人にとっては，美しさと覚えやすさはほぼイコールである。なぜそのようなクラス構成になっているのか，どんなときに使うのか，といったことがすぐに推測できるからだ。そのライブラリに精通していなくても，きっとこんなクラスにこんなメソッドがあるはずだ，などと思いながらリファレンスを調べると，その通りになっている，なんてことも多い。
しかし，そうした推測が働かない初心者にとっては，すべてを一から覚えなければならない。よく使うものだけ覚えればいいとは言っても，なぜそうなっているのかを理解せずに覚えるのは大変だし，リファレンスを探すにも時間がかかる。こうした開発者にとって，クラスを細かく分けるより，一つのクラスに数多くのメソッドを詰め込んだほうが早く使えるようになるかもしれない。
不特定多数の開発者が利用するクラス・ライブラリでは，短期間で使えるようになることは重要である。特に，プラットフォームの土台となるような巨大なライブラリについてはその差は非常に大きい。こうしたライブラリを使いこなせるようになるまでには，プログラミング言語や開発ツールの使い方を学ぶよりもはるかに時間がかかることが多いからだ。
これは，C/C++言語を知っていても，WindowsやX Window Systemのアプリケーションを開発できる人がいかに少ないかを考えれば分かるだろう。
「覚えやすさ」を優先してきたMicrosoftの開発環境
クラス・ライブラリの習得が楽であればあるほど，開発者の人口は増え，開発要員も集めやすくなる。利用する企業にとっては教育にかかるコストが減ることも見逃せない。これらすべてが，結果として開発費を安く押さえることにつながる。昔はデータベースすら満足に扱えなかったVisual Basicが，Windows上のシステム開発で最もよく使われるようになったのは，まさしくこの「覚えやすさ」が理由である。
マイクロソフトが提供するWindowsアプリケーション開発用のC++クラス・ライブラリMFC（Microsoft Foundation Classes）にも，このことは当てはまる。MFCがオブジェクト指向にのっとっていないとか，Windows API（Application Programming Interface）のラッパー（Wrapper）にすぎない，といった批判を耳にすることは多いが，MFCが開発された10年前の状況を考えれば納得がいく。
MS-DOSからWindowsへの移行期であった当時の一番の問題は，Windowsアプリケーションがとにかく重いことだった。当時主流だったのは，C言語でAPIを直接呼び出すタイプのプログラミング手法である。MFCを使うことで，C＋APIよりも明らかに実行速度が遅くなるようでは誰も使わなかっただろう。メンバー関数の名前をAPIの名前と同じにしたのも，こうした開発者がMFCに移行しやすくするためだ。
当時はC++の仕様すら固まっておらず，オブジェクト指向開発の経験を持つ人が今よりはるかに少なかったことも考慮する必要がある。要するに，MFCは当時の開発者を使う気にさせることを最優先して設計されたのである。
.NETに話を戻すと，すでに一定数の開発者が存在し，実績もあるJavaに対して，後発である.NET Frameworkが勝負を挑むには，短期間に習得できることは最低の条件である。その意味で，.NET Frameworkが習得しやすさを優先したのは企業戦略としては当然なのかもしれない。オブジェクト指向開発にあまりなじみがないVisual Basicプログラマを主なターゲットとするなら，上手くまとめてあるなという気もする。
“覚えやすさ”は本当に初心者のためになるのだろうか
だが，記者個人の気持ちを言えば，これを手放しで賞賛する気にはなれないのである。オブジェクト指向開発に慣れた人にとって，こうした設計のクラス・ライブラリはかえって使いにくいことがある点も見逃してはならない。クラス階層を浅くするために共通の基底クラスやインタフェースを用意していないため，統一的に扱うことができずに同じコードを2度書く羽目になる，というのがその例だ。クラス・ライブラリの構成がまっとうでないと，アプリケーションの設計もどこか歪んだものになってしまう。
特に問題なのは，これからオブジェクト指向を学ぼうという人が，それを正しいものと思ってしまうことだろう。プログラミングに限らず，審美眼は美しいものを目にすることによって磨かれる。美しい設計や美しいコードは，実際に見ることなしにできるようには決してならないのだ。
クラス設計に正解はない。クラスの粒度を粗くするか細かくするか，といった問題は，それぞれメリット/デメリットがあるのが普通である。美しさと覚えやすさのどちらを優先するのかについても，基本的にはバランスの問題だ。ただ，.NET Frameworkのクラス・ライブラリの場合，これがベストかと言われると，筆者は疑問を感じるのである。
一度広く使われるようになったライブラリの寿命は，思いのほか長い。.NET Frameworkも，マイクロソフトの思惑通りに広まれば，今後10年は使われるはずだ。その間にはオブジェクト指向開発も浸透し，開発者の意識や見方も変わってくるだろう。10年後，果たして.NET Frameworkにはどのような評価が下されているだろうか。
（山本 哲史＝日経ソフトウエア編集）
