C# 初学者的 3 种重构模式

(Martin Fowler's Example)

1. 积极使用 Guard Clause（保护语句）

"如果条件不满足，立即返回。将核心逻辑放在最少缩进的地方。"

概念定义

Guard Clause（保护语句） 是一种在函数开头检查特定条件是否满足，如果不满足则立即退出（return） 的方法。
它的目的是减少不必要的 if 嵌套，使代码更加线性和平坦（flat） 。

Before（不好的示例）

if (user != null)
{if (user.IsActive){Process(user);}
}

代码嵌套过多，核心逻辑 Process() 被隐藏在最内层。
随着条件的增加，代码会形成“金字塔代码（Pyramid of Doom）”，变得越来越复杂。
当测试条件增多时，代码覆盖率和调试的可读性都会变差。

After（好的示例）

if (user == null) { return; }
if (!user.IsActive) { return; }Process(user);

在条件不满足的情况下，通过提前返回 快速整理流程。
核心逻辑 Process() 位于最少缩进的中央部分 ，可读性更高。
在测试/重构时，可以轻松追踪条件与结果 。

反对意见：“否定条件违背直觉”

一些开发者可能会提出以下观点：

“比起 if (!condition) return;，if (condition) { ... } 更加直观。
否定条件会让代码难以理解。”

回应反对意见：

关键在于条件的正/负，而不是‘意图’和‘重要性’的排序。
如果“在这种情况下不应该执行操作”是明确的，那么否定条件更为清晰 。

指南：

不重要的条件 = 否定形式 + 提前返回
重要的条件 = 肯定形式 + 执行核心逻辑

补充提示：Guard 子句不仅可以使用 return，还可以使用 throw 或 continue

if (value == null) { throw new ArgumentNullException(nameof(value)); }foreach (var item in collection)
{if (item.IsEmpty) { continue; }Process(item);
}

什么时候应该积极使用 Guard 子句？

情况	描述
包含大量验证的函数	通过提前返回来清理条件
包含许多状态分支的循环	使用`continue`作为 Guard 子句
存在未检查的异常风险	清理`null`、`range`、`permission`等潜在问题
方法开始变长时	使用 Guard 子句整理条件过滤，简化代码

实战技巧

Guard Clause 通过去除不必要的嵌套 + 提前退出 ，使代码变得更加平坦（flat） 。
这是一种设计策略，旨在将核心逻辑放在缩进最少、最显眼的位置。
条件越多 、失败案例越明确 、测试越复杂 ，Guard Clause 的优势就越明显。

Dictionary<TKey, TValue> 在内部使用哈希表（Hash Table) 实现。

因此，键查找的平均时间复杂度为 O(1) ，这在很多情况下比 switch-case 更快

2. 战略性地将 Switch 转换为 Dictionary 映射

"条件分支越复杂，代码的责任应被分解得越清晰。"

概念定义

在 C# 中，switch-case 语句对简单的分支处理非常有用，但当分支数量增加时，在维护性和扩展性方面会暴露出局限性 。
在这种情况下，使用 Dictionary<Enum, Action> 或 Dictionary<Enum, Func<T>> 构建显式映射 ，可以显著提升可读性和功能扩展性 。

Before（不好的示例）

switch (state)
{case UserState.Idle:HandleIdle();break;case UserState.Running:HandleRunning();break;case UserState.Dead:HandleDead();break;default:throw new InvalidOperationException();
}

随着分支增多，代码变得冗长。
如果在 switch 内部处理过多逻辑，容易违反单一职责原则（SRP） 。
当新增状态时，需要找到对应的分支、添加逻辑并测试，修改分散且繁琐。

After（好的示例）

private static readonly Dictionary<UserState, Action> stateHandlers = new()
{{ UserState.Idle, HandleIdle },{ UserState.Running, HandleRunning },{ UserState.Dead, HandleDead }
};public void Handle(UserState state)
{if (stateHandlers.TryGetValue(state, out Action action)){action.Invoke();}else{throw new InvalidOperationException($"No handler for {state}");}
}

状态与操作的关系通过映射明确管理 。
新增状态时只需在字典中注册即可完成。
测试时可以独立验证每个处理器。

使用场景示例

UI 状态机（State Machine）

Dictionary<GameState, Action> renderState = new()
{{ GameState.MainMenu, DrawMainMenu },{ GameState.InGame, DrawGame },{ GameState.Paused, DrawPauseScreen },
};

什么时候适合使用？

情况	描述
基于 Enum 的分支较多时	`switch-case`变得过于冗长时
命令/输入处理分支	键/按钮输入 → 动作映射
状态机	状态 → 行为对应结构
需要分离出可测试的逻辑时	`switch`单元测试困难 → 将处理器拆分为独立函数后易于测试

缺点及注意事项

缺点	应对措施
未注册的键没有对应处理	`TryGetValue`失败时明确抛出异常或执行空操作（No-op）
不保证顺序	使用`OrderedDictionary`或重构 Enum 以体现顺序
复杂条件分支难以处理	仅适用于简单条件逻辑，复杂逻辑仍需使用`if/switch`

实战技巧

命令模式（Command Pattern）的简易实现
可以像 Dictionary<string, ICommand> 一样，将命令和执行对象进行映射。
向函数式编程（FP）靠拢的信号
基于字典的映射实际上是将代码转换为数据驱动的表格式结构 ，这与 FP（函数式风格命令调度）的理念更为接近。

(MSDN Magazine Issues Volume 32 Number 3)

(Read only, frozen, and immutable collections - Developer Support)

3. 不可变数据（Immutable Data）习惯

“调试地狱从何开始？——正是从那些意外的值变更开始。”

概念定义

不可变（Immutable）数据 是指一旦定义后，其值不会改变的状态 。
在 C# 中，可以通过 readonly、const、record 等方式实现有意图的不可变设计 。

Before（不好的示例）

public class Player
{public int health;public void TakeDamage(int amount){health -= amount;}
}

在这种结构中，很难追踪 health 是在哪里被修改的。
特别是在多线程或事件驱动系统中，副作用 的累积会使调试难度急剧上升。

After（好的示例）

public class Player
{private readonly int maxHealth = 100;private int currentHealth;public int GetHealth() => currentHealth;public void SetHealth(int value){currentHealth = Math.Clamp(value, 0, maxHealth);}
}

maxHealth 是一个永远不会改变的常量 → 使用 readonly 声明。
状态修改仅通过 SetHealth() 方法完成 → 访问控制与不可变性分离 。

为什么在游戏开发中很重要？

如果状态（State）变更以不透明的方式扩散：

UI 更新延迟
Bug 不规则发生
多人环境中同步问题

解决方法：将状态本身建模为不可变对象 进行管理。

public readonly struct PlayerState
{public readonly int health;public readonly bool isDead;public PlayerState(int health, bool isDead){this.health = health;this.isDead = isDead;}
}

状态不是用来修改的，而是‘重新创建’的。→ 函数式编程模式

Unity 开发者可以这样使用

使用 ScriptableObject 存储配置数据时 → 只读结构化
避免使用 public int value; 形式，改为没有 setter 的 SerializedField
推荐将状态对象存储在不可变的 struct + Copy-on-Write 模式中，而不是放在可变的 MonoBehaviour 中。

[SerializeField] private int initialHealth = 100;public int InitialHealth => initialHealth; // 只允许读取

从 C# 9 开始引入了 `record`

record 默认是不可变对象 。
使用 with 表达式进行修改时会创建新对象（immutable-safe） 。

var newStatus = status with { Health = status.Health - 10 };

高级技巧：并行处理与架构设计建议

`readonly` + `volatile` 组合

private volatile bool isGameOver;
private readonly object lock = new();public void SetGameOver()
{lock (lock){isGameOver = true;}
}

将看似不可变的值在多线程环境中保持一致性保护 。
这种组合也常用于双重检查模式。

注意：所有内容都必须不可变吗？

如果在游戏循环中性能至关重要的结构 ，需要考虑 struct 不可变对象的创建成本。
对于需要频繁状态变更的对象，可以采用“内部不可变性（internal immutability）”作为折衷方案。

什么时候适合使用不可变模式？

场景	描述
需要跟踪状态时	难以追踪状态变更的结构会导致调试噩梦
线程间共享数据	不可变性设计可以在无锁的情况下保证稳定性
可测试的状态建模	基于对象复制的测试和时间点比较更加容易
UI 状态更新	在 ViewModel 中便于变更跟踪和绑定