基于SOLID原则，两种Task创建实现方式哪种更合规？

这是个非常贴合实际开发的好问题！结合SOLID设计原则来看，方式2的实现明显更符合面向对象的设计理念，咱们来具体拆解背后的原因：

先明确两种实现的代码 #

方式1：通过参数传入List并完成添加 #

var tasks = new List<Task>();
CreateTask1(tasks);
CreateTask2(tasks);
CreateTask3(tasks);

private void CreateTask1(List<Task> tasks) {
 // 任务创建相关逻辑
 tasks.Add(new Task());
}

private void CreateTask2(List<Task> tasks) {
 // 任务创建相关逻辑
 tasks.Add(new Task());
}

private void CreateTask3(List<Task> tasks) {
 // 任务创建相关逻辑
 tasks.Add(new Task());
}

方式2：返回Task对象，由调用方管理集合 #

var tasks = new List<Task>();
tasks.Add(CreateTask1());
tasks.Add(CreateTask2());
tasks.Add(CreateTask3());

private Task CreateTask1() {
 // 任务创建相关逻辑
 return new Task();
}

private Task CreateTask2() {
 // 任务创建相关逻辑
 return new Task();
}

private Task CreateTask3() {
 // 任务创建相关逻辑
 return new Task();
}

结合SOLID原则的详细分析 #

1. 单一职责原则（Single Responsibility Principle） #

• 方式1的核心问题：每个CreateTaskX方法同时承担了两个完全不同的职责——创建符合要求的Task对象，以及修改外部集合的状态。这直接违反了“一个类/方法只负责一个明确职责”的原则，后续如果要修改集合操作逻辑，或者修改Task创建逻辑，都得改动同一个方法，维护成本会越来越高。
• 方式2的优势：每个CreateTaskX方法只专注于一件事：创建并返回正确的Task对象。集合的管理（比如添加、移除、存储）完全交给调用方处理，职责边界清晰，后续维护时改动范围也会更小。

2. 依赖倒置原则（Dependency Inversion Principle） #

• 方式1的问题：方法直接依赖List<Task>这个具体的集合类型。如果未来你的需求变化，比如需要把Task存在ObservableCollection<Task>（用于WPF绑定）、HashSet<Task>（去重场景）或者自定义的集合类里，你必须修改所有CreateTaskX方法的参数类型，耦合度极高。
• 方式2的优势：方法不依赖任何具体的集合实现，只关注Task对象本身的创建逻辑。调用方可以自由选择用什么容器存储Task，完全符合“依赖抽象，而非具体实现”的SOLID核心思想。

3. 命令-查询分离（CQS，虽非SOLID但契合其设计思想） #

• 方式1的CreateTaskX是无返回值的方法，但它会偷偷修改外部传入的List状态，属于有副作用的“命令”；但方法名CreateTaskX很容易让调用者误以为它只是创建对象，不会修改外部数据，可读性和安全性都很差，甚至可能引发意外的bug（比如传入的集合被多个方法修改，难以追踪）。
• 方式2的CreateTaskX是纯“查询”性质的方法：它返回一个新的Task对象，不会修改任何外部状态，副作用为零。调用者能清晰知道这个方法的作用，也能自主决定如何处理返回的对象，代码的可读性和可维护性都更好。

额外的灵活性优势 #

方式2的写法还带来了额外的灵活性：如果某个场景下你不需要把Task存入集合（比如临时使用一次就丢弃），直接调用CreateTaskX()就行；而方式1必须传入一个集合，哪怕你根本不需要存储它，这就造成了不必要的约束。

总结一下：方式2完全贴合SOLID的核心设计思想，职责单一、耦合度低、灵活性高，是更合理的实现方式。

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