API と Dependency Injection

Microsoft 的には *1，API を呼んでいてくれた方が色々打つ手が増えてアプリケーションの互換性が高まるわけですが，このあたりに微妙に DI (Dependency Injection) な側面を感じたり．
id:NyaRuRu:20040703#p1 で取り上げたように，Microsoft は「設定ファイルによって実行時に依存性を注入する (こともできる)」という仕組みによって，開発サイクル全体を合理化している会社です．
ITpro の記事，本当はすごい「Windowsの互換性維持」のブックマークを見るとみんな「ときメモ」ばっかりに目が行っているみたいですが，テスターが問題を発見し，マーケティング的な判断で対応することが決定され，「ソースコードを一行も変更せずに」修正が行える仕組みというところがポイントかなと．

4月26日に公開された新パッチは，この不具合を解消するためにとても単純な対策を実施した。新パッチは，OSのレジストリを修正して，HPとNVIDIAの該当ソフトを「Verclsid.exeが検証を行わないプログラムのリスト（許可リスト）」に追加したのである。Verclsid.exeにも，HPやNVIDIAのソフトにも手を加えていない。OSに「HPとNVIDIAのソフトにだけ適用される特別なルール」を追加することによって，この問題を解決したのであった。

記事には「場当たり」が協調されていますが，ソースコードで「場当たり」を行うのと，Dependency Injection で「場当たり」を行うのでは話が違います．環境が変わるたびに毎回ソースコードからコンパイルし直す文化だと，#ifdef を恐れずにがんがん使い，問題が起きたらソースにパッチをあててリコンパイル，という手法が主流ですが，この方法が長期戦・多正面作戦に強いかどうかという点では多少疑問に思っています．だからこそ S2Container.NET とかにもアンテナを向けているわけですけど．
そういう意味では .NET はバージョニングを厳密に行うのはいいのですが，この手のパッチあてや DI っぽい仕組みに，実績ある標準があるかという話になると，まだまだこれからかもしれませんね．アセンブリのバージョンリダイレクトがあるにはありますが，粒度の大きく，セキュリティフィックスには使用できても，アプリケーションの互換性解消で本当に使い物になるかという点ではまだまだ経験値不足かなと．
ライバルは 10 年単位の修羅場をくぐり抜けてきた古参兵なわけで，これから .NET 方面にもそういう汚れ仕事役が登場することになるかもしれませんね．(ああでも COM はそういうのあんまり手を出してなかった気がするから .NET でもこのままという可能性高いかも)

*1:あとまあ wine 的にもこの方がありがたいかな