連載：C# 4入門 最終回 C# 4の使いどころはどこか 株式会社ピーデー　川俣 晶 2011/03/10
Page1 Page2 Page3

分水嶺（ぶんすいれい）はどこにあるのか

　上を見て分かるとおり、もしもソース・コードの見掛けがガラリと変わるポイントを探るとすれば、2回の変化を想定できる。

• ジェネリック導入時
• LINQやラムダ式導入時

　ここで、ジェネリック導入前の時代はもう忘れてよいだろう。その当時からC#を使っていた者たちは少数派であるし、サポートもとうの昔に終わっている。開発環境のVisual Studio .NET 2002／2003は最新のOSであるWindows 7ではなく、1つ前のWindows Vistaの時点ですでに動作がサポートされていない。

　問題はやはり「LINQやラムダ式導入時」という部分だ。つまり、C# 3.0＋.NET Framework 3.5になったタイミングだ。

　これを乗り越えるか否かは、かなり重大な問題であろうと思う。実は、C# 4というのはそれほど重要なバージョンともいえない。C# 3.0をクリアできていれば、C# 4に乗り換えるのにさほど苦労も要らない。冷静に見極めてからでも遅くない。それほど大きな段差ではないからだ。

　やはり問題が大きいのは、技術の段差が大きい変化のときで、サンプル・コードすら読めなくなってしまうほどコードが変化してしまう状態だ。これはある程度の時期までには乗り越えておかないと後で困ったことになる。そういう切実さがあると思ってよいだろう。

　しかも、いまはもう単に「クエリ式が読める」程度ではもはや十分ではない。

　以下のソースは、実際にごく最近筆者が書いたものだ。

public IEnumerable<string> Records {   get   {     return doc.Element("root").Element("collections").Elements("own").Select(c => c.Descendants("ID").First().Value);   } }

　見てのとおり、LINQ to XMLを利用したプロパティだが、もうクエリ式など影も形もない。もちろん、SelectメソッドやFirstメソッドはLINQのメソッドなので、LINQを活用はしているが、もうfrom句は存在しない。LINQにどっぷり浸かったプログラマーはすでにこういうコードを書いてしまう時期に来ているのだ。こういうコードが、さまざまな応用技術を解説するサンプル・コードに入り込む可能性もある。そもそも、説明する本題ではない部分は短く済ませたいので、こういうコードが書かれていても不思議ではない。

パラダイムはひっくり返った

　このような変化は、必ずしも「構文の変化」ではないことに注意が必要だ。ある機能を記述するために、より短い構文が提供されたわけではない。

　そうではなく、もっと本質的な価値観や方法論の転換が行われているのだ。例えば、上の例でいえば、以下のような基本認識がある。

• コレクションの要素の型を変換するにはSelectメソッドが1つあればいい
• 子孫のどこか分からないが、1つだけあると分かっている場合はDescendantsメソッドとFirstメソッドだけでいい（探索するループは要らない）

　これらは、そもそもそれ以前の時代には発想すらなかった使い方といえる。該当する機能を持ったメソッドが存在していなかったからである。

　つまり、意味の分からない機能は整理分類して片っ端から調べればコードが読めるはずであるという認識は、もしかしたら通用しないかもしれない。あるいは、仮に読めても極端に時間がかかる可能性もある。サンプル・コードを書いた人は、ささいな機能だから1行で済ませたつもりなのに、意味を理解するために1日がかりになっては本末転倒である。

パラダイムはもう1回ひっくり返る

　パラダイムはもう1回ひっくり返るかもしれない。メニーコア時代に突入したいま、ソース・コードは大幅な変化を遂げようとしている。C#もそれに追従してメニーコア時代を前提とした並列処理機能を強化しつつある。

　並列でプロセッサが動くということは、効率のためには仲間のプロセッサを待たないで処理を続けたい。つまり非同期動作が基本となり、Visual Studioの次バージョンであるVisual Studio Asyncとも重なる。だが、そこで「メニーコア時代に対応するにはVisual Studio Asyncまで待てばよい」と思うのは早計だ。

　なぜなら、そのための機能の一部はすでに組み込まれているからだ。それが.NET Framework 4に含まれる手軽に複数の処理を並列実行するためのライブラリなどだ。しかも、ハードウェアが先行する形でメニーコア時代はすでに到来しつつある。ソフトウェアに活用されることを待っているのである。

まとめ

　今回のまとめ。

• C# 4は筆者のところではもう常識。使うべきか考えないで使う
• C# 4導入とソース・コード管理は密接な関係を持つ可能性はあり得る
• パラダイムシフトする分水嶺（ぶんすいれい）はC# 3.0の手前にあった
• もう1回パラダイムシフトは来るかもしれない

　最後にC# 4の話を「動的」という切り口に絞ってまとめよう。

　C# 4のテーマは「動的」であるいう。実際にC# 3.0からC# 4への移行期に「動的」なプログラムを作成していたので、その感想から述べよう。

　その前に簡単に何を作成したのかを説明しておくと、テキストのみのノベル・ゲームのフレームワークである。動的に拡張できることが特徴である。もちろん、先にプレーヤ・ソフトを作成して、後からシナリオ・モジュールを作成できるというレベルではない。すでに完成したシナリオ・モジュールに対して、後付けで拡張できることが特徴である。例えば、場所や人物を後から追加することが容易にできる。その際、元モジュールのバイナリを修正する必要はない。必要な調停はフレームワークが動的に解釈してくれる。

　以下がそのフレームワークそのものと、実際の応用例として作成中の推理ゲームである。

• ANGF：Autumn's Novel Game Framework
• 1980オタクのヒデオ

　このANGFというソフトは開発を開始した時点ではVisual Studio 2008＋C# 3.0であったが、ソース管理をTFS 2010に移行した関係で、そのままVisual Studio 2010＋C# 4に移行した。本文で述べたとおりの事情がこのプロジェクトにも作用したわけである。そのため、実際に同じソース・コードを2つのフレームワークで体験するという希有（けう）な経験ができた。

　では、実際に比較してどうだったのだろうか。C# 4に移行して、動的なプログラムは作りやすくなったのだろうか。

　結論からいえば、極端に差は出なかったと感じる。基本クラスをライブラリで提供し、それを継承して実装する形式を取っていると、データ型まで動的になることはなく、C# 4になったからといって極端に変化することはなかった。

　つまり、C# 4の役割は「開拓者」ではない。例えていうならC# 4の役割は「大江戸線の開通」である。確かに大江戸線が開通して駅のなかった地域に多くの駅ができた。それは画期的だが、清澄白河駅ができる前から清澄庭園は存在していたのである。単に、より簡単に訪問可能になっただけである。

　考えてみれば、そもそも.NET Frameworkとは仮想機械語であるIL言語に加えて、アセンブリには豊富なメタデータが付与され、いかようにも動的にメタデータを参照できる環境であった。動的であることは、生まれたときから約束された機能性であったといえる。

　例えば、.NET Framework上のPython言語の実装であるIronPythonの逸話が1つの証明になっている。WikiPediaから引用してみよう。

「IronPythonの起源は、『CLIの設計は動的言語との相性が悪い』という.NET Frameworkの問題点を検証するために作成された検証用のプロトタイプであった。IronPythonの作者であるJim Hugunin氏は2003年に、この論文を発表した。その後、『なぜ、.NET Frameworkは動的言語として駄目なプラットフォームなのか？』という短い論文を書くために、Pythonの移植を試みたところ、彼の意に反してよく動くものができてしまった。」

　このような経緯はある意味で当然である。.NET Frameworkはもともと「動的」と相性がよかったのだ。それは、純粋な機械語であるx86のネイティブ・コードの世界とは異なる世界であったのだ。

　従って、その上に構築されたC#も動的と相性が悪いわけがない。動的に扱えないという話はなく、単にコーディング量に差が付くにすぎない。だから、C# 3.0でも十分に動的なプログラムを書き始めることはできるし、C# 4に移行してもソース・コードは劇的に変化することはない。

　さらにそのような特徴を理解すれば、C# 4を待たずして、すでにC#プログラマーが動的な世界に片足を突っ込めることも分かるだろう。実際、上記の「1980オタクのヒデオ」というソフトには、場所として東京都の全駅を収録している。これは、拡張のための“プレースホルダ”である。しかも、別の誰かが後から拡張するための場所として用意されている。現在は筆者によるサンプル・コードである下高井戸拡張モジュールと、実際にGさんという他人によって後から作成された二子玉川モジュールがあるが、組み込みさえすればシームレスにそのモジュールの世界を訪問できる。組み込むためにレジストリ・エディタすら必要ない（ANGF本体が登録UIを持っている）。

　動的なC#を体験したければ、このようなモジュールを作ってみることも1つの方法だろう。ちなみに、C#以外の言語であっても、仕様を満たすDLLファイルさえ作成できれば作成可能であるが、もちろん提供されるサンプル・コードはC#で書かれている。

• 下高井戸拡張モジュールのソース・コード解説

　話を戻そう。動的であることは実際にはC# 1.0時代から続く特徴でしかない。C++の延長線でしかC#を使用していないプログラマーには直感的に分かりにくい話かもしれないが、実際には本当の断絶はC# 1.0の時代に起きていたといえるのである。C# 4とは、そのC# 1.0から続く一続きの流れの完結編であるといえるのだ。そして、並列処理という新しいテーマのプロローグでもある。この世界は、次のバージョンで開花していくだろう。C# 4という言語はそのような区切りの場所に立っている言語であるともいえるのである。

　そしてもう1ついえることは、動的という側面が完結編として提供されたことは、この後の扱いは一般のプログラマー諸君に委ねられたことを意味する。あなたは、果たしてこの動的な側面で、自分のプログラムにどのような価値をプラスしていくだろうか。

　主導権が読者のあなたに移ったと述べることで、この連載もこれで終わりとしよう。本当のメイン・ステージはこれからである。そして、そこでの主役はC#ではなく、コードを書いていくあなたである。長いお付き合いを感謝したい。

INDEX
	C# 4入門
	最終回 C# 4の使いどころはどこか
	1．C# 4をなぜわたしは使うのか
	2．TFS 2010、VS 2010、C# 4のメリット／3.0、2.0でもよい場合／C# 1.Xはもうやめよう
	3．分水嶺はどこにあるのか／パラダイムはひっくり返った／もう1回ひっくり返る

　

「C# 4入門」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）