控制反转（IoC）是否会引发程序副作用？其适用场景与TDD适配性如何

你观察到的副作用问题本质和IoC无关，是可变依赖的所有权约定不清晰、接口设计不合理导致的误用，IoC完全可以和封装性共存，不需要限制为仅能注入不可变纯类型。

示例问题的根源 #

你给出的FileSearcher示例有两个明显的设计问题，和IoC本身没有关系：

1. 接口抽象违反了最小依赖原则
   PlayListViewer需要的能力仅仅是「在对应播放列表路径下搜索指定格式的文件」，而你定义的IFileSearcher暴露了SetSearchPath这个本不需要的可变方法，相当于主动把内部状态暴露给了外部。你完全可以把接口设计为无状态的，从根源上避免状态被修改的问题：

public interface IFileSearcher
{
    List<string> FindFiles(string searchPath, string searchPattern);
}

这种设计下，PlayListViewer自己维护播放列表路径参数，调用FindFiles时传入即可，根本不会出现外部修改路径导致逻辑错误的问题。
2. 违反了可变依赖的所有权约定
依赖注入的通用约定是：一旦你将一个可变依赖实例注入给目标类，该实例的所有权就转移给目标类，注入方不应该再持有、修改该实例。如果多个消费者需要使用同类型的依赖，应该为每个消费者分配独立的实例，绝大多数IoC容器都默认支持「瞬态生命周期」，每次请求依赖时都会返回新的实例，完全避免共享可变状态的问题。
你给出的Main方法只要做极小调整就能解决问题：

public static void Main()
{
    // 给PlayListViewer单独创建一个FileSearcher实例，不共享
    var viewer = new PlayListViewer("Hits 2021", new FileSearcher());
    // 另做他用的FileSearcher单独创建实例
    var searcherForPicture = new FileSearcher();
    searcherForPicture.SetSearchPath("C:/Users");
    var pictures = searcherForPicture.FindFiles("*.jpg");

    viewer.FindSongNames().ForEach(Console.WriteLine); // 结果正确
}

可变依赖注入的通用规范 #

对于Date、Stream这类自带状态的可变类型，只要遵循两个规则就可以完全避免你提到的副作用：

• 优先注入不可变版本：Java用LocalDateTime替代可变的Date，C#用只读流替代可写流传入消费者，如果业务必须使用可变依赖，一定要显式说明该依赖的所有权规则
• 全局共享的依赖必须是无状态的：如果要把某个依赖注册为单例全局复用，要保证它没有任何可修改的成员变量，所有方法的执行仅依赖传入的参数，不会修改自身状态

IoC的适用场景 #

完全不需要把IoC的使用限制在仅注入不可变类型的场景，工业级开发中绝大多数场景都适合用IoC，只有两类场景不推荐：

• 性能极端敏感的底层逻辑：比如操作系统内核、高频交易核心路径，IoC容器带来的纳秒级性能损耗不可接受
• 逻辑简单的小型工具脚本：引入IoC框架的复杂度高于解耦、可测试性带来的收益

对TDD的影响 #

上述规则完全不影响TDD的落地：
TDD对代码的核心要求是依赖可替换、可Mock，不管是可变还是不可变类型都可以满足这个要求。按照规范设计的依赖反而会简化单元测试的编写，不需要额外处理可变依赖的状态重置逻辑。

内容的提问来源于stack exchange，提问作者Sean