Final LINQ Extensions II

C# LINQの基礎について解説しています。発表自体はかなり前ですが、現在（.NET 5）においても全く問題ありません。

------

Center CLR Part.3 （DoorKeeperは退会したため、募集エントリは残っていません）

Transcript

1. Final LINQ Extensions Ⅱ Center CLR Part.3 – 2015.05.10 Kouji Matsui @kekyo2
2. 自己紹介  けきょ (@kekyo2 Kouji Matsui)  LINQ, Async, .NETとか  Center CLRオーガナイザーです  会社やってます  アーキとかフレームワーク設計とか
3. アジェンダ  雑魚の始末  クエリ構文との連携  演算子の適用回数を減らすこと  短縮演算子  Where条件の合成  LINQ⇔制御構文  強力な武器を手に入れる  更なる演算子  LINQソース  式木の使われ方  IEnumerableへのフォールバック  並列化  Pick it up for Multiple!  TPLとの関係
4. クエリ構文との連携  クエリ構文は「構文糖」です。 クエリ構文 メソッド構文（拡張メソッド） Selectが展開されない事に注意 メソッド構文 （非拡張メソッド）
5. クエリ構文との連携  クエリ構文は「構文糖」です。  ある「条件」を満たせば、独自の実装をLINQクエリ構文で記述させることが 出来るようになります。  クエリの連結を成立させるには： 条件 内容 メソッドの種類 インスタンスメソッドでも拡張メソッドでも良い。 演算子の対応 クエリ構文でサポートされている演算子に対応したメソッド名で定義する。 Where, Select, SelectMany, OrderBy(Descending), ThenBy(Descending), Join, GroupBy, Grouping （但し、全部定義する必要はない） メソッド戻り値 前段の演算子の戻り値から、演算子メソッドのオーバーロードを特定可能にする。 列挙可能性 IEnumerable<T>の実装は必須ではない。
6. クエリ構文との連携  例えば、ここに独自の「HogeModel」クラスがあったとします… 何となくWhere演算子っぽいメソッド。 拡張メソッドでなくても良い。 指定されたラムダ式で、 文字の位置を取得する
7. クエリ構文との連携  HogeModelクラスに対して、クエリ構文が使用できる 普通にメソッドの呼び出し。 戻り値がintである事に注意。 HogeModelに対して、 クエリ構文が使用可能に！！ こ れ が 出 来 る と
8. クエリ構文との連携  selectはどこに行った？ from句で範囲変数とした「ch」を selectでそのまま射影した場合は、 Selectメソッドに展開されない。 Selectメソッドはない
9. クエリ構文との連携  クエリが連結されるとき、どうなっているか？ valueをそのまま射影しなかった場合は Whereの戻り値が、次のSelectの入力に ならなければならない Select演算子が生成される
10. クエリ構文との連携  クエリの連結を成立させるには Whereの戻り値が、次のSelectの入力にならなければならないので、 別のクラスを定義して、それを返す このクラスで、Selectが使える
11. クエリ構文との連携  クエリの連結を成立させるには クエリ構文で記述可能 WhereはHogeFilteredModelを返す HogeFilteredModel.Select()が使える
12. クエリ構文との連携  クエリの連結を成立させるには：  System.Linq.Enumerableクラスには、上記の条件を満たした標準演算子 メソッドが定義されている ので、クエリ構文が普通に使える！ Enumerable.Where() Enumerable.OrderBy() Enumerable.Select() 条件 内容 メソッドの種類 インスタンスメソッドでも拡張メソッドでも良い。 演算子の対応 クエリ構文でサポートされている演算子に対応したメソッド名で定義する。 Where, Select, SelectMany, OrderBy(Descending), ThenBy(Descending), Join, GroupBy, Grouping （但し、全部定義する必要はない） メソッド戻り値 前段の演算子の戻り値から、演算子メソッドのオーバーロードを特定可能にする。 列挙可能性 IEnumerable<T>の実装は必須ではない。
13. 演算子の適用回数を減らすこと  0～9999999までの数値を降順にソートした数値文字列のうち、偶数 のものを得る 何が問題？
14. 演算子の適用回数を減らすこと  このクエリの何が問題ですか？ 10000000回の文字列変換が 発生する しかし、実際には半数が 捨てられてしまう 絞り込んだ後で、 変換する 実 行 順
15. 演算子の適用回数を減らすこと  このクエリの何が問題ですか？ 10000000件のソートが発生する しかし、その後半数が 捨てられる 絞り込んだ後で、ソートする 実 行 順
16. 演算子の適用回数を減らすこと  このクエリの何が問題ですか？ 範囲変数に代入すると、内部では Select演算子が挿入される 無意味かつ実装が明瞭であれば、 範囲変数への代入を削除する 実 行 順
17. 演算子の適用回数を減らすこと  範囲変数の定義で、自明であっても本当に射影しているのか？  ILSpyでデコンパイルして確かめる let valueString= value.ToString() 範囲変数に対応する射影がない
18. 演算子の適用回数を減らすこと  演算子を減らす  総数が少なくなるように整理する  無駄な演算をしないようにする  LINQ to Objectsには「クエリオプティ マイザー」はありません。
19. 短縮演算子  絞り込んでスイッチ、絞り込んでスイッチ、絞り込んでスイッチ… 絞り込んで、最初の要素を得る 演算子を一つ削減 FirstOrDefaultオーバーロード
20. 短縮演算子  短縮演算子の種類 機能グループ 演算子 フィルター First / FirstOrDefault Last / LastOrDefault 単項（即値） Any / All Max / Min Count パフォーマンスのための演算子だけど、 後から機械的なリファクタリングで対応可能ネ！
21. Where条件の合成  何度も何度も絞り込み… 要するに、AND条件 単一のWhereにまとめる → ラムダ式の呼び出し回数が削減される
22. LINQ⇔制御構文  データの抽出はLINQを使って書きますが… 何がダメですか？ 1000000000件の乱数を生成し、 偶数の値だけ抽出する
23. LINQ⇔制御構文  LINQを使って書きたいけど、何故置き換えが難しいのかな… List<int>に1000000000個の乱数を追加。 そもそも無理ゲー。 実際には約半数ぐらいで済む気がする… しかし、乱数なので正味個数は不明 全体を見ればより良く最適化出来そう だけど、それだと部品化出来ない
24. LINQ⇔制御構文  LINQはデータの抽出「式」を定義する事で、抽出処理を実現します。  だから、そこで使う部品（演算子）は、すべからく「式」でなけれ ばなりません。  まずは、「式」の体をなしていない「GetRandomValues」を矯正しま しょう。 引数ではなく、戻り値として List<int>を返す
25. LINQ⇔制御構文 出力（戻り値） 入力（引数） 入力と出力が明確に分離されている事。 これは非常に重要な事です。
26. LINQ⇔制御構文  これでGetRandomValuesは式の体をなしたので、呼び出し側も変えま す。 listの扱いについて、頭を悩ます要素 （誰が生成してどう管理するのか）が減った
27. LINQ⇔制御構文  ところで、これはforeachで書けますね indexが削減された！
28. LINQ⇔制御構文  あ、Resharperが何か言ってる… 「おいコラ、クソコード書いてんじゃねぇ、 LINQで書けるだろーが」
29. LINQ⇔制御構文  で、こうなりました。 抽出条件がLINQクエリ化  List<int>にLINQクエリが書けるのは、何故でしたか？  List<T>がIEnumerable<T>を実装しているから、でしたね。  オーバーロードの選択によって、System.Linq.Enumerable.Where()が呼び出さ れますね。
30. LINQ⇔制御構文  という事は、ローカル変数listの型はList<int>ですが、実は：  List<int> → IEnumerable<int> で良いんですよね。
31. LINQ⇔制御構文  では、GetRandomValuesの戻り値の型も：  List<int> → IEnumerable<int> で良いって事ですよね。
32. LINQ⇔制御構文  という事は、そもそもList<int>を用意する必要はなく： 乱数を逐次返却
33. LINQ⇔制御構文  あーれれ？目の上のコブだったList<T>が無くなってしまいました。  この例では、アルゴリズムの再考を行うことなく、リファクタリン グ技術のみで、制御構造で書かれた処理をLINQに置き換え、更にメ モリ使用量を劇的に改善しました。  これを実現するポイント：  処理中に存在する部品は、「式」化する。入力と出力を明確に分離し、 「入出力」として使用しないように注意する（副作用を持ち込まない）。  より抽象度の高い型を使用する。 配列やList<T>は、IList<T>へ。 IList<T>は、IReadOnlyList<T>へ。 IReadOnlyList<T>は、IEnumerable<T>へ。 非ジェネリックIEnumerableは LINQで使えないので、ここまで。
34. LINQ⇔制御構文  制御構文→LINQ  これが必要なのは、見通しの悪い、リスクの高いコードの整理を行う場合 です。LINQクエリに置き換えると、処理の意味（意図）が明瞭になります。  ここで見せたように、制御構文寄りで書かれたコードをLINQクエリに置き 換えるのは大変です。  大変になる主な理由は、副作用の見極めと排除作業に依ります。
35. LINQ⇔制御構文  LINQ→制御構文  逆に、既存のLINQクエリを制御構文に置き換えるのは簡単です。  LINQクエリは「式」であり、まず副作用が無い事が見込める（副作用があ るとまともに動作しない）ため、単純に展開すれば良いのです（whereなら if文に置き換えるなどの、機械的な置換操作）。  これが必要になるのは、LINQクエリのパフォーマンスが問題になる場合で す。しかし、難易度が低いので、とりあえずLINQで実装して、後で測定し てから修正でも、全く問題ないと言えます。最終的には、プロダクトリ リースを早める武器の一つとなるでしょう。 だから、データ抽出処理は、 LINQで書かなければならない、のです！
36. LINQ⇔制御構文  データ操作をLINQで自在に書けるようになるためには、もう少し武 器が欲しいですね。
37. アジェンダ  雑魚の始末  クエリ構文との連携  演算子の適用回数を減らすこと  短縮演算子  Where条件の合成  LINQ⇔制御構文  強力な武器を手に入れる  更なる演算子  LINQソース  式木の使われ方  IEnumerableへのフォールバック  並列化  Pick it up for Multiple!  TPLとの関係
38. 更なる演算子  標準演算子をほぼ網羅  前回と合わせて目指せマスター！ 機能グループ 演算子 単項（即値） Average Contains SequenceEqual 抽出 DefaultIfEmpty First / FirstOrDefault Last / LastOrDefault Single / SingleOrDefault ElementAt / ElementAtOrDefault Cast / OfType 集合演算 Except / Intersect / Union 単純結合 Concat / Zip 結合 Join / Grouping ジェネレータ Empty / Range / Repeat 演算器 Aggregate
39. 単項（即値）  Average  シーケンスの平均値を求めます。 152 124 238 54 568.0 平均値の型はdouble
40. 単項（即値）  Averageのオーバーロード 数値ではないシーケンスにAverageは使えない （オーバーロードがない：Average<T>ではない） ラムダ式で数値（ここではchar）を返すように すれば、平均値を求めることが可能 （≒短縮演算子）
41. 単項（即値）  Contains  シーケンスに値が含まれているかどうかを検査します。 152 124 238 54 238 存在すればtrue
42. 単項（即値）  Containsのオーバーロードはない 真ん中の文字が「E」の 文字列があるかどうか どうする？
43. 単項（即値）  Containsのオーバーロードはない 真ん中の文字が「E」の 文字列があるかどうか 短縮演算子でスッキリ Whereで絞り込んでAny で存在確認
44. 単項（即値）  SequenceEqual  シーケンスが同じかどうかを検査します。 152 124 238 54 同一 : true 152 124 238 54 一致しない : false 要素数が違う : false
45. 抽出  DefaultIfEmpty  シーケンスが空の場合は、デフォルト値を返す 152 124 238 54 152 124 238 54 空ではないので、 そのまま 0 空なので、デフォルト値 default(int) 単一のシーケンスを 返す
46. 抽出  First / Last  シーケンスの先頭・終端の値を得る 152 124 238 54 152 54 First シーケンスが空だと どうなる？ Last
47. 抽出  FirstOrDefault / LastOrDefault  シーケンスが空の場合に、デフォルト値を返す シーケンスが空の場合に default(int) を返す 0 FirstOrDefault LastOrDefault
48. 抽出  Single / SingleOrDefault  シーケンスの、ただ一つの要素を返す 152 Single 152 0 SingleOrDefault シーケンスが0個or1個「ではない」 場合は例外がスローされる
49. 抽出  なぜ、Single / SingleOrDefaultのようなものが必要なのですか？ First / FirstOrDefaultでも いいんじゃない？
50. 抽出  Single / SingleOrDefaultと書いてあれば、「このシーケンスには複数 の要素が来ることはない」というのが見ただけで分かります。  複数の要素が来たら、バグですよね多分。  コードの「意図」を明確にすることが重要です。  制御構文からLINQクエリへ： 基本要素（forとかwhileとかifと かswitch）の羅列では、読解に労力を要します。LINQクエリで 記述することで、より高度でありながら抽象度の高い記述が 可能になり、コードの誤りを避けたり摘出が容易になります。  LINQクエリに意図を盛り込む：「どうするか」ではなく、 「何をしたいか」を記述することで、コードがより意図的に なります。コードから意図が読み取りやすいほど、保守性は 劇的に良くなります。  Wikipedia: 「インテンショナルプログラミング」
51. 抽出  Element / ElementAtOrDefault  指定された位置の要素を返す 152 124 238 54 238 0 (2) (4) シーケンスが範囲外の場合は、 default(int) が返される
52. 抽出  配列なら、インデクサーでもいいんじゃね？ LINQ遅そうだし ElementAtの内部実装（等価） IList<T>を実装していれば（配列含む）、 インデクサアクセスするので高速 確かに配列インデクサアクセスの方が高速だが、 LINQの内部実装も工夫はしている。 しかもElementAtは、順列アクセスしかできない場 合でも、正しく動作する。
53. 152 抽出  Cast / OfType  シーケンスの要素をキャストしながら抽出する Cast “ABC” 124 987.654 152 “ABC” 124 987.654 152 OfType “ABC” 124 987.654 152 124 238 … … … 54 OfTypeは指定された型にキャスト 出来るものだけが抽出される 要素のインスタンスに変化はないが、 IEnumerable<T>のジェネリック引数型が与えられる
54. 抽出  Castは、LINQが使えないコレクションをLINQで使用可能にします。 IEnumerable → IEnumerable<IFormattable> Windows Formsの古いコレクションなどで LINQ使いたい場合に、Castを使います。 非ジェネリックIEnumerableでは、LINQは使えない
55. 集合演算  Except（差集合） / Intersect（積集合） / Union（和集合） 数学の「集合」と同じネ Except（差集合） Intersect（積集合） Union（和集合）
56. 集合演算  Except（差集合） 123 datas0 datas1 456 1234 3456 121 223 2345 789 494
57. 集合演算 123 datas0 datas1 456 1234 3456 121 223 2345 789 494  Intersect（積集合）
58. 集合演算 123 datas0 datas1 456 1234 3456 121 223 2345 789 494 重複する要素は1回しか 列挙されないことに注意  Union（和集合）
59. 単純結合  Concat（シーケンスの結合） Unionと異なり、単純に2つのシーケンスを結合 するので、重複する可能性があります。 データベース的にはUNION ALLです。
60. 単純結合  Zip（縫い合わせる） 片方で要素数が不足する場合は、 その要素は列挙されない 123 456 789 1234 “ABC” “DEF” “GHI” “JKL” 2345 3456 2つの要素を射影させる λ “123:ABC” “456:DEF” “789:GHI” “1234:JKL”
61. 結合  Join（キーによる積集合） 比較するキーを「on～equals」で指定する。 「equals」以外は指定出来ない。 演算自体はIntersectに似ている。 データベースの内部結合に相当。
62. 結合  メソッド構文で書いた場合： 結合対象 on句の左辺と右辺 射影式を含む
63. 結合  Joinじゃなくて、サブクエリ的に書いたら？ Joinなんて、また新しいもの覚えたくないし、 Containsで同じことが実現できるじゃん？
64. 結合  全然ダメです。確かに結果は同じですが、Containsを使うとほぼ二重ルー プのブルートフォースと同じで、件数によって膨大な計算量が必要にな ります。  Joinを使うと、内部ではハッシュテーブルを使って一時的にキーを割り当 て、高速にマッチングを行います。
65. 結合  GroupBy（キーによるグループ化） ID タイトル 123 IT業界の闇について 456 萌に関する101通りの方法 456 萌に関する101通りの方法 アドバンスド 666 ウォーターフォールがうまくいく3つのポイント 666 ウォーターフォールがうまくいく666つのポイント 789 デスマーチとは 789 デスマーチ再び ID タイトル 123 IT業界の闇について 456 萌に関する101通りの方法 萌に関する101通りの方法 アドバンスド 666 ウォーターフォールがうまくいく3つのポイント ウォーターフォールがうまくいく666つのポイント 789 デスマーチとは デスマーチ再び これこそが、LINQがSQL の延長上「ではない」 最大の強力な武器 同じIDを持つデータを集約したい。 （たまたま同じIDが並んでいるが、 当然IDが離れていても集約する）
66. 結合  GroupBy（キーによるグループ化） どの項目でグループ化するか（キー） グループ化結果を格納する、一種の射影 キャストは実際には不要（参考）
67. 結合  GroupBy（キーによるグループ化） キー毎に、n個のタイトルを表示
68. 結合  メソッド構文で書いた場合： 集約対象 どの項目でグループ化するか（キー）
69. 結合  明示的に射影しなかった場合： IGroupingとは？ グループ化結果の1グループ分を示す。 ID タイトル 456 萌に関する101通りの方法 萌に関する101通りの方法 アドバンスド
70. 結合  IGrouping<TKey, TElement>インターフェイスは、 IDictionary<TKey, TElement>に似ています。  IDictionaryは、「キー・値」の組のコレクションです。  IGroupingは、値コレクションにキーが付けられた、一つ分のグループです。 ID タイトル 123 IT業界の闇について 456 萌に関する101通りの方法 456 萌に関する101通りの方法 アドバンスド 666 ウォーターフォールがうまくいく3つのポイント 666 ウォーターフォールがうまくいく666つのポイント 789 デスマーチとは 789 デスマーチ再び ID タイトル 123 IT業界の闇について 456 萌に関する101通りの方法 萌に関する101通りの方法 アドバンスド 666 ウォーターフォールがうまくいく3つのポイント ウォーターフォールがうまくいく666つのポイント 789 デスマーチとは デスマーチ再び 辞書的（IDictionary） グループ化（IEnumerable<IGrouping>）
71. 結合  グループ化は、従来のデータベースでは実現不可能だった、「階層化された データ」をそのまま処理できます。  データベースで階層化データを扱えないのは、あくまで「表」という構造に縛 られているためです。.NET CLRの世界ではそのような制約はありません。  処理自体は、SQLでのGROUP BYに相当しますが、マルチレコードセットのよう な扱いにくい概念ではなく、ごく自然にクラス型にマッピング出来ます。 ID タイトル 123 IT業界の闇について 456 萌に関する101通りの方法 萌に関する101通りの方法 アドバンスド 666 ウォーターフォールがうまくいく3つのポイント ウォーターフォールがうまくいく666つのポイント 789 デスマーチとは デスマーチ再び グループ化されたキー グループ化された値群
72. ジェネレーター  Empty（空シーケンス生成） 正規に使用するシーケンスの代わりにEmptyを 与える事が出来る。 インスタンスは生成しないので、効率は良い
73. ジェネレーター  Range（順列シーケンス生成） あるあるコード：forが邪魔。ifも邪魔。 forの代わり。順列シーケンスを 供給する カッコつきに射影してstring.Join で結合すれば、ifを無くせる 似て異なる実装
74. ジェネレーター  Repeat（繰り返しシーケンス生成） 10000個 123 123 123 … 123
75. ジェネレーター [Ref] [Ref] [Ref] … [Ref] 10000個の参照  Repeatを参照型で使う場合の注意点： FooModel 単一のインスタンス FooModel FooModel FooModel … FooModel 10000個のFooModel（への参照）
76. アジェンダ  雑魚の始末  クエリ構文との連携  演算子の適用回数を減らすこと  短縮演算子  Where条件の合成  LINQ⇔制御構文  強力な武器を手に入れる  更なる演算子  LINQソース  式木の使われ方  IEnumerableへのフォールバック  並列化  Pick it up for Multiple!  TPLとの関係 その昔、クリスタルの魔力をわが手中に せんとする陰謀が、 「これが最後」というタイトルと共に、 幾度となく繰り返された伝説があった…
77. ポルナレフ 『俺は確かに奴を倒したが 奴は目の前に立っていた...』
78. 次回予告 Final LINQ Extensions Ⅲ （仮題）  LINQソース  式木の使われ方  IEnumerableへのフォールバック  並列化  Pick it up for Multiple!  TPLとの関係 近日公開！！！
79. お疲れ様でした！  スライドはブログに掲載します。 http://www.kekyo.net/  素材Thx:  http://free-illustrations.gatag.net/2013/10/05/000000.html  http://free-illustrations.gatag.net/tag/%E8%A1%A3%E6%9C%8D-%E8%A1%A3%E9%A1%9E  http://sundriveplus.blog54.fc2.com/blog-entry-945.html