一、游戏开发中的设计原则：从理论到实战

做游戏开发这些年，我越来越觉得设计原则这东西，不是背出来的，是踩坑踩出来的。今天咱们聊聊三个最常用的原则——SRP、OCP、LSP，在游戏里到底怎么落地。

你想想看，一个游戏项目动辄几十万行代码，角色、技能、AI、UI全搅在一起。如果不讲点章法，改一个需求能让你改三天三夜。我早期参与过一个手游项目，就因为没做好组件化，每次加新功能都要动核心类，那叫一个痛苦。

1.1 游戏对象组件化（SRP）

单一职责原则（SRP）说白了就是：一个类只干一件事。在游戏里，这个原则最经典的应用就是组件化架构。

举个例子，一个游戏角色，它需要移动、播放动画、播放音效、处理碰撞。如果全写在一个类里，会怎样？

// 反面教材：一个类干所有事
class Player {
    void Move() { /* 移动逻辑 */ }
    void PlayAnimation() { /* 动画逻辑 */ }
    void PlaySound() { /* 音效逻辑 */ }
    void HandleCollision() { /* 碰撞逻辑 */ }
};

嗯，这里要注意。一旦你这么做，每次改移动逻辑，都可能不小心影响到动画。我遇到过最惨的一次，只是改了个移动速度，结果角色播放攻击动画时卡住了——因为两个逻辑共用了一个状态变量。

正确的做法是组件化：

// 组件化设计：每个组件只负责一件事
class MoveComponent {
    void Update() { /* 只处理移动 */ }
};

class AnimationComponent {
    void Update() { /* 只处理动画 */ }
};

class SoundComponent {
    void Update() { /* 只处理音效 */ }
};

class Player {
    MoveComponent* move;
    AnimationComponent* anim;
    SoundComponent* sound;
    
    void Update() {
        move->Update();
        anim->Update();
        sound->Update();
    }
};

1.2 事件系统（OCP）

开闭原则（OCP）讲的是：对扩展开放，对修改关闭。在游戏里，事件系统就是OCP的最佳实践。

为什么会这样？因为游戏里到处都是「当A发生时，B要做响应」。比如玩家死亡，要播放死亡动画、播放音效、更新UI、触发复活逻辑。如果把这些写死在代码里，每次加新响应都要改核心逻辑。

// 不好的做法：硬编码响应
void OnPlayerDeath() {
    PlayDeathAnimation();
    PlayDeathSound();
    UpdateUI();
    // 如果要加新响应，必须改这个函数
}

事件系统的做法是：

// 事件系统：对扩展开放
class EventSystem {
    std::map<std::string, std::vector<std::function<void()>>> listeners;
    
    void Subscribe(const std::string& event, std::function<void()> callback) {
        listeners[event].push_back(callback);
    }
    
    void Emit(const std::string& event) {
        for (auto& cb : listeners[event]) {
            cb();
        }
    }
};

// 使用：各自注册自己的响应
EventSystem events;
events.Subscribe("PlayerDeath", PlayDeathAnimation);
events.Subscribe("PlayerDeath", PlayDeathSound);
events.Subscribe("PlayerDeath", UpdateUI);
// 加新响应？直接注册就行，不用改原有代码

1.3 状态机（LSP）

里氏替换原则（LSP）说的是：子类应该可以替换父类，而不影响程序正确性。在游戏里，状态机是LSP的典型应用。

你想想看，游戏角色有各种状态：待机、行走、攻击、受伤、死亡。每个状态的行为不同，但对外接口应该一致。

// 基类：定义统一接口
class State {
public:
    virtual void Enter() = 0;
    virtual void Update() = 0;
    virtual void Exit() = 0;
    virtual ~State() = default;
};

// 子类：各自实现，但接口一致
class IdleState : public State {
    void Enter() override { /* 进入待机 */ }
    void Update() override { /* 待机逻辑 */ }
    void Exit() override { /* 退出待机 */ }
};

class AttackState : public State {
    void Enter() override { /* 进入攻击 */ }
    void Update() override { /* 攻击逻辑 */ }
    void Exit() override { /* 退出攻击 */ }
};

// 状态机：可以替换任何状态
class StateMachine {
    State* currentState;
    
    void ChangeState(State* newState) {
        currentState->Exit();
        currentState = newState;
        currentState->Enter();
    }
    
    void Update() {
        currentState->Update();
    }
};

1.4 三者如何协同工作

这三个原则不是孤立的。在实际项目中，它们经常一起使用：

• 组件化（SRP）：把游戏对象拆成独立组件
• 事件系统（OCP）：组件之间通过事件通信
• 状态机（LSP）：每个组件内部用状态机管理行为

举个例子，一个敌人的AI组件：

// AI组件：只负责AI逻辑
class AIComponent {
    StateMachine fsm;  // 状态机管理行为
    EventSystem* events;  // 通过事件通信
    
    void OnTakeDamage() {
        events->Emit("EnemyHurt");  // 触发受伤事件
        fsm.ChangeState(new HurtState());  // 切换到受伤状态
    }
};

这样设计的好处是：

1. AI组件只干AI的事（SRP）
2. 加新响应只需注册事件（OCP）
3. 状态可以随意替换（LSP）

这张图展示了三个原则如何分层协作。底层是组件化，每个组件各司其职；中间是事件系统，负责组件间的通信；顶层是状态机，管理每个组件内部的行为变化。三者各司其职，又紧密配合。