列挙子を列挙するときに、現在の位置が知りたい場合がある。頭の中にまだLINQの武器が少ないときは、諦めてfor文に逃げたりする。
int[] data = new int[] { 123, 456, 789 };
List<int> results = new List<int>();
for (int index = 0; index < data.Length; index++)
{
results.Add(data[index] * (index + 1));
}
LINQを使うなら、こういったループ制御構文を出来るだけ使わないようにする事だ。これが最終的に、ロジック重視の設計からデータドリブンの設計に移行するカギとなる。
インデックスが必要なら、インデックスを列挙させれば良い。
int[] data = new int[] { 123, 456, 789 };
List<int> results =
(from index in Enumerable.Range(0, data.Length)
select data[index] * (index + 1)).
ToList();
for文やforeach文で（ロジック的に）記述してしまうと、その後の応用性が失われてしまう。Enumerable.Rangeでインデックスの列挙子を生成すれば、結果は列挙子となる。上の例では早々にToListしてしまったが、もちろん、ここから続けて別のクエリを書く事が出来るし、そうすることでパイプライン実行が行われる。AsParallelすれば並列実行も出来る。応用性が全く違うというわけだ。
ところで、上の例は元ネタとなるdataが配列であるので、要素数が分かる。だからEnumerable.Rangeでインデックスを生成できるのだが、配列である事を想定しているので詰めが甘い。ここは一つ、任意の列挙子で実現してみよう。
ただ置き換えるのであれば、以下のようになる。
IEnumerable<int> data = new int[] { 123, 456, 789 };
List<int> results =
(from index in Enumerable.Range(0, data.Count())
select data.ElementAt(index) * (index + 1)).
ToList();
配列はIEnumerableを実装しているので、Count拡張メソッドを使って要素数を取得するのは間違っていない。また、Count拡張メソッドの実装は、対象がICollectionを実装していることを検知して、実際に列挙することなく要素数を得る事が出来るので、効率も良い。
しかし、列挙子が配列ではない、任意の列挙子であった場合、しかもICollectionを実装していない場合は、一旦列挙を行って要素数を数え上げる。要素数を取得するだけならこれでも良いが、その直後、LINQクエリ内のElementAtで、また列挙を開始するため、二重に列挙を行っていることになる。
コストについてピンと来ないかもしれないが、仮に列挙子がデータベースクエリを抽象化していると、データベースに対して2回のクエリ実行を行うことになる。ほとんどの場合において、これは許容出来ない（LINQ to SQLやLINQ to Entitiesでこのような事をしないように）。
では、どうやって改善するか。
public static IEnumerable<Tuple<int, T>> Indexing<T>(this IEnumerable<T> enumerable)
{
int index = 0;
return from value in enumerable select Tuple.Create(index++, value);
}
またしても、ヘルパー拡張メソッドだ。これを使えば、タプルクラスで作った「インデックス詰め合わせ」に変換できる。
IEnumerable<int> data = new int[] { 123, 456, 789 };
List<int> results =
(from entry in data.Indexing()
select entry.Item2 * (entry.Item1 + 1)).
ToList();
危ういロジック記述に頼ることなく、インデックスを保持する外部変数に頼ることなく、2回列挙することなく、クエリを簡便に記述可能になった。しかも、Indexingメソッドの実装もまたLINQクエリなので、返された列挙子は遅延実行される。つまり、パイプライン実行が可能ということだ。
Windows Formsで、コントロールの階層を親方向に辿りたいと思ったことがあるかも知れない。
List<Control> list = new List<Control>();
Control current = innerMostControl;
while (current != null)
{
list.Add(current); // 実際にはリストに溜めるのではなく、ロジックを書いちゃったりするよね
current = current.Parent;
}
この「while」を止めたいのだ。LINQに慣れてくると、「ループ終了条件」が正しいかどうかを、演算式だけで担保したくなる。whileやforやifによる制御構文があると、ロジックによる分岐が一々大丈夫かどうか確認するのが煩わしいし、ミスも生じやすくなる。「インデックスって0からだっけ、1だっけ？最後は”<"か"<="か？」とか、ifでこっちに行って、elseであっちに行ってとか、非常にうっとおしい。思考の邪魔だ。
このようなループ制御を行っている場合は、うまく考えればクエリ化出来る。もうかなりのLINQクエリを書いているが、どうしてもループ制御構文を使わなければ実現できなかったコードは、ほんの僅かだった。
この親コントロールをたどるwhileループは、要するに親までの一方向リンクをリスト化するということだ。やってみよう。
public static IEnumerable<T> TraverseLink<T>(this T begin, Func<T, T> predict)
{
T current = begin;
while (current != null)
{
yield return current;
current = predict(current);
}
}
このyield構文は、前回のyield構文と書き方は同じだが、メソッドが直接IEnumerableを返してしまう点で、更に強力だ。と、同時に、使い慣れていないと、メソッドが返却しているモノが一体何であるのか、混乱するかもしれない。
さて、この武器を使えば、リンクリストの追跡など、安全でたやすく、シンプルだ。
List<Control> list = innerMostControl.TraverseLink(delegate(control) { return control.Parent; }).ToList();
ええ、と？ あ、一行か :-)
もちろん、型がControlである必要はない。リンク先がParentである必要もない。これらを担保するのは、ジェネリック引数とFuncデリゲートだ。つまり、任意のリンクリストをこのTraverseLink拡張メソッドでたどる事が出来る。