LINQが完成版となってリリースされたので、次はその使用方法について考える番である。Keith Farmer氏はLINQを使用することでサブクラスが削除できるとまで言及している。しかしそちらに進む前に、Microsoftからの公式ガイドを見てみよう。
MicrosoftはFramework Design Guidelinesに沿ってLINQに基づいたフレームワーク構築のためのガイドラインをリリースした。LINQ Framework Design Guidelines(source)はAPI設計やビヘイビアなどのトピックスを取り扱っている。多くの企業で見られるコーディングガイドラインと違って、ここではライブラリの公式APIに触れる場合を除いてパターンの名前付けやフォーマットなどの平凡な項目は対象外としている。
オリジナルのFramework Design Guidelinesの大部分は、最終的に、Microsoftとそれ以外の両方で整合性を保ちつつ使用されるコード分析ツールのFxCOPに組み込まれる形となった。
このドキュメントでは、序章に続き、Extension MethodsおよびジェネリックデリゲートであるFunc、Action、およびExpressionについて説明している。通常のメソッドで対応可能な場合に拡張メソッドを多用することに対する標準的な警告が記載されている中、ネームスペースの衝突についての説明は見られない。2つのライブラリが同じ型上で拡張メソッドを使用すると、メソッド名の衝突が起こる可能性がある。これが発生すると、2つのライブラリの一方のみがインポートされ、他方はフルネームを使用して参照しなくてはならなくなる。
LINQ拡張に関するセクションでは、ジェネリック型の名前付けに関する有益な情報が得られる。T型と呼ばれるジェネリック型は常に項目を参照し、S型はその項目の集合体を参照する。これは強制ではないが、少なくともビルトインメソッドの読み取りを簡素化する。
パフォーマンス面では、ICollectionの実装がカウント関連のアクション実行に役立つという記述がある。IEnumerableのみの実装であれば、カウントを得るために集合体全体を移動する必要がある。
ここで、Keith Farmer氏の話に戻って、サブクラスを避ける方法を見てみよう。
私がずっと念頭に置いてきたのは、プロパティ、これらプロパティに直接関連するメソッド、およびコントラクタやコンバータなどの基本機構のみにクラスを減らすことです。
次に、拡張メソッドを使用して、それ自体はエンティティとしてクラス概念を維持する必要がない操作や、（たとえ可能でも）サブタイプを作成する意味がない場合の操作を定義します。
たとえば、ノードはGraphに対する操作を知らなくても十分機能し、おそらくGraphはIsNetworkRouterについての知識を持つ必要がありません。
この場合、Traverse（GraphLink）などがGraph上で有効なメソッドですが、GraphLinkの特定のサブタイプ実装詳細に依存する（つまり、Workメトリクスに関連する）FindLeastWorkRoute（Node, Node）などが、私が考える最適な拡張メソッドです。
この方法によって、アプリケーション特有のロジックを実装するためだけにカスタムのサブタイプを作成する必要がなくなり、結果として関連するクラスの煩雑化が解消されます（例：GraphとGraphLinkの両方ではなく、Graphのみ）。
これは.NETプログラミングに照らしてみて道理にかなうだろうか？Microsoftの設計原則に従うだろうか？また、この件に対して、これらのガイドラインがどれだけ問題となるだろうか？