概要
一週間ほど前、
俺は今日、Shadow Dependency Injection っていう最強概念を発明したぜ──Clean Architecture超えたかもしれん
という記事を書かせていただきましたが（というかほぼGPTとのChatを転載しただけw)、昨日無事 GitHub に PlayGround レベルのソースコード（.NET/C#) を公開しましたので謹んでご報告申し上げます。
利用イメージ
何がしたいのかというと、結局 C/C++ でいうところのヘッダファイル、Java でいう SPI のような、"アプリケーションのメインコンポーネントが依存するのは、利用するモジュールとの契約まで。ソースコードレベルで実装には依存しない" という世界を軽量に、C#/.NET の世界で実現したかったんですね。
※ .NET の世界には MEF もありますが、重いっ、ってことで(*'▽')
左: 普通のDIコンテナ利用例（だと思う）
右: 本ShadowDIでのコンテナ利用（RegisterTypeを直接書かない）
※ 「普通のコンテナ利用例」も、依存性逆転したクリーンアーキテクチャのシンプルな例、に、なれてるはず！笑
じゃあどうやってこの IMessageModel とか IMessageWriterDispatcher の実装がコンテナに Inject されるかというと、
ShadowInjectable という属性をクラスに付与 (MessageModelの例 / MessageWriterDispatcherの例) し、
.csproj 側で「依存関係生成」のための .target ファイル（※）を Import (MessageModelの例 / MessageWriterDispatcherの例) して、
※ MSBuildの拡張ポイント、昔でいう Makefile の一部
エントリポイント側の .csproj で「依存関係取得」のための .target ファイルを Import する形です。
ちなみに各種ファイルの先頭に5桁の番号が付いているのは、ソリューションエクスプローラー上で例の「同心円」を再現しようという趣味です 笑
利用結果イメージ
ShadowDI不使用の場合
もちろん、エントリポイント(DIコンテナにInjectをする側)では、「実装」コンポーネントへの依存（プロジェクト参照）が発生します。
これはつまり、エントリポイントは実装の public メンバに自由にアクセス可能、ということで、逆に、実装(Impl)側では、いろんなものを public にする際は警戒を怠れないということになります。
ShadowDI使用の場合
エントリポイントにおいても、「実装」コンポーネントへのプロジェクト参照が発生しません。
これはつまり、実装(Impl)側で、エントリポイントや他のコンポーネントから依存されない安心感があるので、未来の拡張実装で必要そうなメンバは public にすることができる(≒OCPにおけるOpenな「拡張ポイント」を作っておける) ということなんじゃないかとも考えられます。（もちろんコンポーネント間の依存も Contracts 限定の想定、Impl依存は、同レイヤの未来の拡張コンポーネントから、という意味。）
あと大規模プロジェクトとかだとコードメトリクスにも結構良い影響が出てくるんじゃないかと想像してますが、そういったプロジェクトでの試験は未実施です。（ソフトウェア工学の大学生/大学院生の卒論・修論ネタになりそう。誰か書きません？w）
TODO
- インタフェイス側のアノテーション
- このインタフェイスはShadowInjectable実装必須だよ！的な
- コンテナ登録時のスコープ関連（子コンテナの扱いとかどうする？）
- 診断ログ
- 優先度つきの ShadowInjectable 属性とか
- ドキュメンテーション
みたいなところでしょうか。
時間があるときにでも頑張れるかもしれません。（やらない権利の最大限留保w）
おしまい