#はじめに
私は普段C#を使ったUnity開発に取り組んでいます。これまではどちらかと言えば、「良いコードを書きたい」というより、「バグがなくてきちっと動けばそれで良い」という考えでコードを書いてきたように思います。ただ、エンジニアとしてはそれではやはり不十分でしょう。そこで、『Adaptive Code ~ C#実践開発手法』を読んで勉強することにしました。

「アダプティブ」とは、コードを大幅に変更することなく、新しい要求や予想外のシナリオに対処する適応力のことです。

ただ、本書は基本的に.NET Frameworkでの開発を前提として書かれていますし¹、文字数も多いので、自分にとって重要な箇所を抜き出してまとめながら学習を進めることは意味のあることだと思います。
今回のまとめは第3章の内容に当たります。
#本章の目的

メソッドレベルからシステムレベルへの複雑な依存関係を管理する
~~依存関係がもっとも複雑な部分を特定し、ツールを使って複雑さを和らげる~~(.NET Frameworkのツールについての解説なのでここでは触れない)
コードを小さく適応しやすい機能に分割することで、再利用を促進する
階層化パターンをそれらが最適な場所に適用する
依存関係を解決する方法を理解し、依存関係の問題をデバッグする
実装を単純なインターフェースで隠ぺいする

すべてのソフトウェアには依存関係がある。依存関係により、呼び出し元のコードは機能を抽象的に捉えるようになる。依存関係が何をするのか、それをどのように行うのかについては考えなくてもいいが、すべての依存関係が正しく管理されるようにしなければならない。依存関係の連鎖がうまく管理されなければ、必要のない依存関係が強引に作成され、コードが複雑なアセンブリ²参照だらけになってしまう。
#依存関係
依存関係とは、2つのエンティティ間の関係であり、一方が存在しなければ、もう一方が何らかの機能を実行できない、あるいは存在し得ないことを意味する。
この定義をコードに当てはめると、多くの場合、エンティティはアセンブリである(クラス、メソッド、あるいはアセンブリの集まりの場合もある)。
　　　　　
アセンブリAはアセンブリBを使用している。つまり、AはBに依存している。この時、AはBのクライアントであり、BはAのサービスである。Bが存在しなければ、Aは機能しない。
BがAに依存していない点は非常に重要。
コードがクライアントなのか、サービスなのかは、そのコードにどちらの視点からアプローチするのかによって決まる。つまりはどちらにもなり得る。
####有向グラフでの依存関係のモデル化
グラフとは、ノードとエッジの2つの要素からなる数学的構造のこと。エッジに向きがないものを無向グラフ、向きがあるものを有向グラフと呼ぶ。コードの依存関係は有向グラフで表現できる。
　　　　　
この構造は何種類かの粒度で適用することができる。
粒度の粗いノードごとに、より粒度の細かいノードの集まりが存在する。サブシステムの内部にはアセンブリがあり、アセンブリの内部にはクラスがあり、クラスの内部にはメソッドがある、といった感じ。このことから、１つのメソッドに対する依存関係がさらに依存関係を呼び、最終的にサブシステム全体が参照されるという構図が浮かび上がる。
扱っている依存関係がどのようなものであるかはわからない。わかっているのは、依存関係が存在することだけ。依存関係を管理するにあたって知っていなければならないのは2つのエンティティ間の2項関係、つまり「依存関係が存在するか、しないか」のみ。
以下のB→D→E→B→D→E→･･･のようなアセンブリ間の循環依存関係は禁止されており、いかなる場合も阻止される(Visual Studioで設定しようとするとエラーが出る)。
　　　　　
#依存関係の管理
Coming soon...

#階層化
Coming soon...

監訳者の方は、本書の読者対象は、初学者からベテランまでのC#開発者すべてだと断言している。また、サンプルコードはC#でも、他のプログラミング言語(特に型付けされた言語)で開発しているチームにとっても大切なエッセンスを学べるとも。 ↩
ここでのアセンブリとは、クラスやインターフェイスの集合のこと。正しく構造化されたアセンブリには、1つの機能グループにのみ関連するクラスとインターフェイスだけが含まれている。例を上げれば、Views、Controllers、ViewModelsなど。 ↩