1. 项目概述：当游戏系统变得臃肿不堪

做Unity游戏开发，尤其是项目进入中后期，你有没有遇到过这样的场景：为了播放一个过场动画，你需要先找到AnimationManager，再调用AudioManager播放背景音乐，接着通知UIManager隐藏HUD，最后还要确保GameStateManager切换到了正确的状态。任何一个环节漏掉，都可能出现角色在播片时UI还飘在屏幕上，或者音画不同步的尴尬Bug。

这还不是最头疼的。当策划提出“我们想在战斗胜利时，除了播放特效和音效，还要弹出一个奖励界面并自动保存进度”这种需求时，你会发现你需要同时修改四五个不同管理器的代码，牵一发而动全身。系统间的耦合像一团乱麻，新人接手代码时望而生畏，老手添加新功能也如履薄冰。

这就是复杂子系统带来的“架构债”。而外观模式（Facade Pattern），正是我们偿还这笔债务、重构游戏架构的一把利器。它不是什么高深的新技术，而是一种经过时间检验的、用于管理复杂度的设计思想。简单说，外观模式就是为一系列复杂的子系统接口，提供一个统一、简洁的高级接口。它像一个“前台”或“总控台”，把背后繁琐的调用流程封装起来，让客户端（你的游戏逻辑）只需要跟这个“前台”打交道。

在Unity里，这意味着你可以创建一个GameplayFacade类，它内部聚合了动画、音频、UI、场景、存档等各个管理器。当你需要播放一个过场时，只需调用GameplayFacade.PlayCutscene(“intro”)，所有脏活累活都在外观类内部按正确顺序搞定。这不仅能极大简化客户端代码，更能将子系统间的复杂依赖关系隐藏起来，让整个游戏架构变得清晰、稳定且易于维护。接下来，我们就深入拆解，如何将这一经典的结构型模式，落地为Unity复杂系统封装的终极解决方案。

2. 外观模式的核心思想与Unity适配

2.1 为什么是“结构型”模式？

设计模式通常分为创建型、结构型和行为型。外观模式被归为结构型模式，是因为它的核心价值在于重新组合对象之间的关系，形成一个更清晰、更易用的结构，而不是专注于如何创建对象或定义对象的行为。

想象一下游戏中的“任务系统”。一个任务可能涉及：从QuestDatabase读取数据，在UIManager中更新任务追踪界面，通过NotificationManager弹出接取提示，在AnalyticsManager中发送日志。如果没有外观模式，你的任务逻辑代码里会散落着对这些子系统的大量直接调用，结构混乱。而引入一个QuestSystemFacade后，它内部持有这些子系统的引用，对外提供AcceptQuest(int questId)、CompleteQuest(int questId)等简洁方法。外观类在这里扮演了“胶水”和“路由器”的角色，它定义了子系统之间应该如何协作，并将这种协作关系固化在一个统一的接口背后，从而优化了整体的代码结构。

2.2 外观模式在Unity中的独特价值

Unity开发有其特殊性：大量使用组件（Component）、单例（Singleton）管理器、以及由MonoBehaviour生命周期驱动的脚本。这些特性使得外观模式的应用更具实战意义。

1. 对抗“单例滥用”导致的耦合：很多项目会用AudioManager.Instance.Play()这种方式。直接调用单例虽然方便，但导致业务逻辑与具体管理器紧耦合。外观模式可以将这些单例调用收拢。例如，你有一个SoundFacade，内部调用AudioManager.Instance。未来即使你将音频系统重构为基于Addressables的资源加载，也只需要修改SoundFacade内部，所有业务逻辑代码都不受影响。
2. 简化MonoBehaviour脚本的复杂度：一个PlayerController脚本如果既要处理移动输入，又要直接调用动画、音效、特效，会变得非常臃肿。通过引入PlayerFXFacade，提供PlayFootstep()、PlayJump()等方法，PlayerController的代码会清爽很多，职责也更单一。
3. 统一异步操作与生命周期管理：Unity中很多操作是异步的，如资源加载、场景切换。外观模式可以封装这些异步流程。比如SceneFacade.LoadGameScene()内部可以处理：显示加载界面、异步加载场景、加载完成后隐藏界面、初始化场景内对象等一系列步骤，对外却提供一个清晰的async方法或回调，让调用者无需关心细节。

注意：外观模式不是用来取代接口抽象或依赖注入的。它更侧重于“简化使用”，而非“定义契约”。你可以先使用依赖注入来解耦，然后再用外观模式来提供一个便捷的入口。

2.3 与其它Unity常用模式的区分

• 与中介者模式（Mediator）：两者都用于减少对象间通信的复杂性。关键区别在于，中介者模式侧重于对象间的双向通信协调，对象知道中介者，中介者也知道所有对象。而外观模式侧重于为子系统提供一个单向的、简化的访问入口，子系统通常不知道外观的存在。在Unity的UI系统中，一个管理多个UI面板打开关闭逻辑的UIMediator是中介者；而一个封装了UI、音频、特效来表现“升级”效果的LevelUpFacade则是外观。
• 与适配器模式（Adapter）：适配器模式是“转换接口”，让不兼容的接口能一起工作（比如将旧的存档系统接口适配成新的）。外观模式是“简化接口”，它背后可能调用多个复杂的接口，但目的是提供一个更友好的新接口。
• 与单例模式（Singleton）：外观类本身经常被实现为单例，以方便全局访问。但它的核心价值在于封装，单例只是其实现方式之一。你也可以通过依赖注入将外观类的实例传递到需要的地方，以获得更好的可测试性。

3. 实战：构建一个游戏流程外观（GameFlowFacade）

理论说再多不如一行代码。我们以一个游戏中最常见的流程——“从主菜单开始新游戏”为例，来构建一个完整的GameFlowFacade。这个流程通常涉及：UI切换、场景加载、数据初始化、音频控制等多个子系统。

3.1 定义子系统接口与实现

首先，我们定义几个核心的子系统的接口（或抽象类），这是为了解耦，让外观类依赖于抽象而非具体实现。

// 音频系统接口 public interface IAudioSystem { void PlayBGM(string bgmName); void StopBGM(); void PlaySFX(string sfxName); } // UI系统接口 public interface IUISystem { void ShowMainMenu(); void HideMainMenu(); void ShowLoadingScreen(); void HideLoadingScreen(); } // 场景管理系统接口 public interface ISceneSystem { Task LoadSceneAsync(string sceneName, Action<float> onProgress = null); void UnloadSceneAsync(string sceneName); } // 游戏数据管理系统接口 public interface IDataSystem { void CreateNewSaveFile(string saveSlot); void LoadGameData(string saveSlot); }

在Unity项目中，你会有对应的具体实现类，比如AudioManager : MonoBehaviour, IAudioSystem，它们内部实现了具体的播放逻辑、资源加载等。

3.2 实现GameFlowFacade外观类

现在，我们来创建外观类。它聚合了上述所有子系统，并提供高级别的流程方法。

using System.Threading.Tasks; using UnityEngine; public class GameFlowFacade { // 持有子系统引用（可通过构造函数注入，此处为简化使用服务定位器模式） private IAudioSystem _audioSystem; private IUISystem _uiSystem; private ISceneSystem _sceneSystem; private IDataSystem _dataSystem; public GameFlowFacade(IAudioSystem audio, IUISystem ui, ISceneSystem scene, IDataSystem data) { _audioSystem = audio; _uiSystem = ui; _sceneSystem = scene; _dataSystem = data; } // 核心方法：开始新游戏 public async Task StartNewGame(string saveSlotName) { Debug.Log("[GameFlowFacade] 开始新游戏流程..."); // 1. 隐藏主菜单 _uiSystem.HideMainMenu(); // 2. 显示加载界面 _uiSystem.ShowLoadingScreen(); // 3. 停止主菜单BGM _audioSystem.StopBGM(); // 4. 异步加载游戏场景（例如“GameScene”） await _sceneSystem.LoadSceneAsync("GameScene", (progress) => { // 这里可以更新加载界面的进度条，UI系统提供接口 Debug.Log($"场景加载进度: {progress:P0}"); }); // 5. 创建新的存档数据 _dataSystem.CreateNewSaveFile(saveSlotName); // 6. 加载游戏数据（初始化玩家状态、关卡等） _dataSystem.LoadGameData(saveSlotName); // 7. 播放游戏场景的BGM _audioSystem.PlayBGM("Gameplay_BGM"); // 8. 隐藏加载界面 _uiSystem.HideLoadingScreen(); Debug.Log("[GameFlowFacade] 新游戏流程完成。"); } // 另一个高级方法：返回主菜单 public async Task ReturnToMainMenu() { Debug.Log("[GameFlowFacade] 返回主菜单流程..."); _uiSystem.ShowLoadingScreen(); _audioSystem.StopBGM(); await _sceneSystem.LoadSceneAsync("MainMenuScene"); _audioSystem.PlayBGM("Menu_BGM"); _uiSystem.HideLoadingScreen(); _uiSystem.ShowMainMenu(); } }

3.3 在Unity中初始化和使用

你需要一个地方来初始化这个外观类并管理其生命周期。通常可以在一个永不销毁的GameManager或AppController中完成。

public class AppController : MonoBehaviour { private GameFlowFacade _gameFlow; void Awake() { DontDestroyOnLoad(gameObject); InitializeSystems(); } void InitializeSystems() { // 实例化或获取子系统的具体实现（这里假设它们都是MonoBehaviour单例） IAudioSystem audio = AudioManager.Instance; IUISystem ui = UIManager.Instance; ISceneSystem scene = SceneLoader.Instance; IDataSystem data = SaveManager.Instance; // 创建外观实例 _gameFlow = new GameFlowFacade(audio, ui, scene, data); } // 提供给UI按钮调用的方法 public void OnStartNewGameButtonClicked() { // 注意：Unity事件不能直接等待async方法，需要“fire and forget”或使用UniTask等方案 #pragma warning disable CS4014 StartNewGameAsync("AutoSave"); #pragma warning restore CS4014 } private async Task StartNewGameAsync(string slot) { await _gameFlow.StartNewGame(slot); } }

现在，你的UI按钮只需要调用AppController.Instance.OnStartNewGameButtonClicked()即可。所有复杂的流程顺序、子系统交互都被隐藏在GameFlowFacade内部。如果将来需要在加载场景前增加一个“播放过渡动画”的步骤，你只需要修改GameFlowFacade.StartNewGame方法，而所有调用它的地方都无需改动。

实操心得：在实现外观类时，我强烈建议将所有对子系统的调用都包裹在try-catch块中，或至少进行空引用检查。因为外观类作为协调者，一个子系统的失败不应该导致整个流程崩溃。你可以在外观类内部定义一套优雅的降级或重试机制。例如，如果播放某个音效失败，可以记录警告并使用一个默认音效替代，而不是让游戏卡住。

4. 高级封装：应对Unity特有的复杂性

基本的流程封装只是开始。Unity开发中还有许多特有的复杂性，外观模式可以帮你更好地封装它们。

4.1 封装Addressables资源加载与依赖管理

现代Unity项目普遍使用Addressables进行资源管理。加载一个角色预制体，可能同时需要加载它的模型、动画控制器、材质球、音效等多个依赖项。我们可以创建一个AssetLoadingFacade。

using UnityEngine.AddressableAssets; using UnityEngine.ResourceManagement.AsyncOperations; public class AssetLoadingFacade { public async Task<GameObject> LoadCharacterPrefabAsync(string characterKey) { // 内部可能先加载一个配置表，获取该角色需要的所有资源地址 // 然后使用Addressables.LoadAssetsAsync来批量加载所有依赖 // 最后再加载主预制体并实例化 // 对外，调用者只需要关心“加载某个角色” var handle = Addressables.LoadAssetAsync<GameObject>(characterKey); await handle.Task; if (handle.Status == AsyncOperationStatus.Succeeded) { return handle.Result; } else { Debug.LogError($"加载角色 {characterKey} 失败: {handle.OperationException}"); // 可以返回一个兜底的错误模型 return LoadFallbackCharacter(); } } public void ReleaseCharacter(GameObject characterInstance) { // 智能地释放该实例及其相关资源，调用者无需关心引用计数 Addressables.ReleaseInstance(characterInstance); } private GameObject LoadFallbackCharacter() { /* ... */ } }

4.2 封装复杂的UI交互链

一个商店购买操作，UI上需要：弹出确认窗口、播放金币扣除动画、更新库存数字、显示获得物品的弹窗、播放音效。我们可以用ShopFacade来封装。

public class ShopFacade { private IUISystem _ui; private IAudioSystem _audio; private IInventorySystem _inventory; private ICurrencySystem _currency; public async Task<bool> PurchaseItem(ShopItem item) { // 1. 检查货币是否足够（内部调用CurrencySystem） if (!_currency.CanAfford(item.Price)) { _ui.ShowMessage("金币不足！"); _audio.PlaySFX("Error"); return false; } // 2. 弹出确认窗口（异步等待玩家选择） bool confirmed = await _ui.ShowPurchaseConfirmDialog(item); if (!confirmed) return false; // 3. 执行购买逻辑序列 _currency.Deduct(item.Price); _inventory.AddItem(item.Id, 1); // 4. 播放一系列反馈效果（顺序很重要） _audio.PlaySFX("CoinSpend"); await _ui.PlayCoinAnimationAsync(-item.Price); // 等待金币动画完成 _audio.PlaySFX("ItemGet"); _ui.ShowItemAcquiredPopup(item.Icon, item.Name); // 5. 记录日志或触发成就 Analytics.LogPurchase(item); AchievementSystem.UnlockIfNeeded("FirstPurchase"); return true; } }

这样，在商店UI的按钮事件里，只需要一行代码：await _shopFacade.PurchaseItem(selectedItem);。所有复杂的交互逻辑和时序控制都被完美地封装和复用。

4.3 为编辑器工具提供简化接口

外观模式不仅用于运行时，也能极大提升编辑器扩展的开发效率。比如，你有一个复杂的地图编辑工具，涉及地形刷、物体摆放、路点设置、光照烘焙等多个独立编辑器窗口。

你可以创建一个MapEditorFacade静态类，提供类似这样的方法：

public static class MapEditorFacade { public static void CreateNewMap(int width, int height, TerrainType defaultTerrain) { TerrainSystem.CreateGrid(width, height, defaultTerrain); LightingSystem.SetupDefaultLighting(); PathfindingSystem.GenerateNavMesh(); UndoSystem.ClearHistory(); // 清理撤销记录 EditorWindow.GetWindow<MapOverviewWindow>().Refresh(); } public static void PlacePrefabOnTerrain(GameObject prefab, Vector3 worldPos) { // 自动对齐到地形高度 worldPos.y = TerrainSystem.GetHeightAt(worldPos); var instance = PrefabUtility.InstantiatePrefab(prefab) as GameObject; instance.transform.position = worldPos; // 自动添加到对象管理列表 ObjectManagementSystem.RegisterMapObject(instance); // 标记场景为脏，需要保存 EditorSceneManager.MarkSceneDirty(EditorSceneManager.GetActiveScene()); } }

这样，你的编辑器脚本或者自定义的Inspector按钮，调用一两个简单的方法就能完成一系列复杂的编辑操作，大大降低了工具使用的门槛和出错概率。

5. 外观模式的陷阱与最佳实践

尽管外观模式非常强大，但滥用或误用也会带来问题。以下是几个关键的注意事项和实战建议。

5.1 避免成为“上帝类”

外观类很容易变成一个无所不包的“上帝类”（God Class），这违背了单一职责原则。关键在于按功能领域划分外观，而不是只有一个全局外观。

• 好的做法：
  • AudioVisualFacade: 封装所有视听反馈（音效、音乐、屏幕震动、后处理特效）。
  • GameplayLogicFacade: 封装核心游戏玩法逻辑（开始回合、计算伤害、判断胜负）。
  • DataPersistenceFacade: 封装所有数据读写（存档、读档、设置、统计）。
  • NetworkFacade: 封装网络连接、匹配、消息发送接收。
• 不好的做法：一个GameFacade包含了从音频播放到网络通信再到数据保存的所有方法，变得极其臃肿，难以维护。

5.2 处理好与子系统的依赖关系

外观类依赖于具体的子系统接口。如何管理这些依赖是关键。

1. 依赖注入（推荐）：通过构造函数注入所有依赖。这使外观类易于测试（你可以传入Mock对象），也明确了它的依赖关系。

   public class MyFacade { private ISystemA _a; private ISystemB _b; public MyFacade(ISystemA a, ISystemB b) { _a = a; _b = b; } }

2. 服务定位器（谨慎使用）：在静态类或容器中获取实例。虽然方便，但隐藏了依赖，不利于测试和理解。

   public void DoSomething() { var audio = ServiceLocator.Get<IAudioSystem>(); // 依赖被隐藏 }

3. 单例引用（快速原型）：在小型项目或原型阶段可以直接引用Manager.Instance。但在中大型项目中，这会导致外观类和具体实现类紧耦合，不利于重构。

避坑指南：我个人的经验是，在项目初期可以使用服务定位器或单例来快速搭建外观，让主要游戏逻辑先跑起来。当架构逐渐稳定后，再花时间重构为依赖注入，这对项目的长期健康至关重要。

5.3 性能考量：避免过度包装

每一次通过外观方法的调用，都意味着一层额外的函数调用开销。对于在Update中每帧调用成千上万次的极度性能敏感代码（如物理检测、粒子更新），直接调用子系统可能更高效。外观模式更适合用于离散的、逻辑复杂的、调用频率相对较低的操作，如流程控制、资源加载、复杂交互等。

你可以通过提供一个“快速路径”来平衡。例如：

public class ParticleFacade { private IParticleSystem _particle; // 高级接口，用于复杂效果 public void PlayExplosionAt(Vector3 pos, float scale) { ... } // 低级接口，供性能关键代码直接调用 public IParticleSystem GetLowLevelSystem() { return _particle; } }

5.4 版本管理与向后兼容

外观类成为了客户端代码的主要依赖点。当你需要修改或升级某个子系统时，应尽量保持外观类的方法签名不变，通过修改外观类的内部实现来适配新的子系统。这为你的代码提供了宝贵的向后兼容性。

例如，你的音频系统从基于AudioSource升级到了Wwise音频中间件。你只需要重写IAudioSystem的具体实现类，并确保它满足原有接口契约。然后，在创建AudioVisualFacade时传入这个新的Wwise实现类即可。所有通过外观类调用音频的代码都无需任何修改。

6. 实战案例：重构一个真实的怪物生成系统

让我们看一个更具体的案例。假设我们有一个老旧的怪物生成系统，代码散落在各处，直接调用了多个管理器。

重构前（混乱的调用）：

// 在某个关卡脚本中 void SpawnEnemyWave() { for(int i = 0; i < waveCount; i++) { // 1. 从配置加载怪物数据（直接调用DataManager） var enemyData = DataManager.Instance.GetEnemyData(enemyId); // 2. 异步加载怪物预制体（直接调用Addressables） var loadHandle = Addressables.LoadAssetAsync<GameObject>(enemyData.PrefabPath); yield return loadHandle; var prefab = loadHandle.Result; // 3. 实例化并设置位置 var spawnPos = GetRandomSpawnPoint(); var enemyObj = Instantiate(prefab, spawnPos, Quaternion.identity); // 4. 初始化怪物属性（直接调用多个系统） var enemyComp = enemyObj.GetComponent<Enemy>(); enemyComp.Init(enemyData); EnemyManager.Instance.RegisterEnemy(enemyComp); // 注册到管理器 AISystem.Instance.AssignBrain(enemyComp, enemyData.AIType); // 分配AI // 5. 播放生成特效和音效（直接调用特效和音频管理器） VFXManager.Instance.PlayAt("SpawnPoof", spawnPos); AudioManager.Instance.PlaySFX("EnemySpawn"); // 6. 更新UI计数 UIManager.Instance.Get<WaveUI>().UpdateEnemyCount(++currentEnemyCount); // 7. 释放Addressables句柄？经常忘记！ // Addressables.Release(loadHandle); } }

这段代码的问题显而易见：职责不清、资源句柄可能泄漏、难以测试、修改生成逻辑需要到处找代码。

重构后（使用EnemySpawnFacade）：

首先，我们创建外观类：

public class EnemySpawnFacade { private IEnemyDataProvider _dataProvider; private IAssetLoader _assetLoader; private IEnemyManager _enemyManager; private IAISystem _aiSystem; private IVFXSystem _vfx; private IAudioSystem _audio; private IGameUI _ui; public EnemySpawnFacade(... /* 依赖注入 */) { ... } public async Task<Enemy> SpawnEnemyAsync(string enemyId, Vector3 position) { // 1. 获取数据 var data = await _dataProvider.LoadEnemyDataAsync(enemyId); if (data == null) throw new ArgumentException($"无效的敌人ID: {enemyId}"); // 2. 加载资源 var prefab = await _assetLoader.LoadEnemyPrefabAsync(data.PrefabKey); // 3. 实例化与初始化 var enemyObj = GameObject.Instantiate(prefab, position, Quaternion.identity); var enemy = enemyObj.GetComponent<Enemy>(); enemy.Initialize(data); // 4. 注册与配置 _enemyManager.Register(enemy); _aiSystem.AssignBehavior(enemy, data.AIBehavior); // 5. 播放反馈 _vfx.Play("Spawn", position); _audio.PlayOneShot("EnemySpawn", position); // 6. 通知UI（可选，可通过事件系统解耦得更彻底） _ui.OnEnemySpawned?.Invoke(); // 7. 资源释放由AssetLoader内部管理 return enemy; } public async Task SpawnWaveAsync(WaveDefinition wave) { _ui.UpdateWaveInfo(wave); foreach (var spawn in wave.EnemySpawns) { var pos = CalculateSpawnPosition(spawn); await SpawnEnemyAsync(spawn.EnemyId, pos); await Task.Delay(TimeSpan.FromSeconds(spawn.DelayAfterSpawn)); // 控制生成间隔 } } }

然后，在关卡脚本中，代码变得极其简洁：

public class WaveManager : MonoBehaviour { [SerializeField] private WaveDefinition[] _waves; private EnemySpawnFacade _spawner; void Start() { // Facade通过依赖注入在别处初始化并传入 _spawner = GetComponentInParent<GameSession>().EnemySpawner; StartCoroutine(RunWaves()); } IEnumerator RunWaves() { foreach (var wave in _waves) { yield return _spawner.SpawnWaveAsync(wave).AsCoroutine(); yield return new WaitUntil(() => _spawner.AreAllEnemiesDefeated()); } } }

重构带来的好处：

1. 职责清晰：WaveManager只负责调度波次，所有生成细节由EnemySpawnFacade负责。
2. 可测试性：你可以轻松为EnemySpawnFacade编写单元测试，通过Mock所有子系统来验证生成逻辑。
3. 资源安全：资源加载和释放的逻辑被封装在IAssetLoader实现中，避免了内存泄漏。
4. 易于修改：如果想在怪物生成时增加一个“扫描玩家”的行为，只需修改EnemySpawnFacade.SpawnEnemyAsync方法，在初始化后添加一行_scanSystem.ScanForPlayer(enemy);即可。
5. 代码复用：任何需要生成敌人的地方（如剧情触发、作弊码、测试工具）都可以复用这个外观类。

7. 总结与个人体会

外观模式不是银弹，但它确实是处理Unity中复杂系统依赖的一剂强效解耦药。从我十多年的项目经验来看，它的价值在项目规模扩大、团队人数增加时体现得尤为明显。

我个人最深的体会是：外观模式本质上是一种“契约”和“缓冲区”。它为混乱的子系统交互定义了一份清晰的契约（高级接口），并在契约与实现之间建立了一个缓冲区。当子系统内部发生剧烈变动（比如换用新的资源管理框架、重构网络模块）时，只要这份契约保持不变，缓冲区就能吸收所有的冲击，保证游戏核心逻辑的稳定。

在具体实施中，我建议：

1. 不要一开始就过度设计：在原型阶段，直接调用管理器或许更快。当某个功能点的调用涉及到3个以上的子系统，且逻辑开始变得复杂时，就是引入外观模式的好时机。
2. 以“功能域”而非“技术层”划分外观：不要创建AudioFacade、UIFacade，而是创建GameplayFeedbackFacade（处理游戏内反馈）、FrontendFlowFacade（处理前端界面流）。前者只是对子系统的简单转发，后者才是真正提供业务价值的简化接口。
3. 让外观类成为“用例”的体现：外观类的方法名应该直接反映玩家的操作或游戏的业务逻辑，如PurchaseItem、StartNewGame、EquipWeapon，而不是PlaySoundAndShowUIAndSaveData。

最后，记住所有设计模式的根本目的都是管理复杂度。外观模式通过提供一个精心设计的“简化视图”，让你和你的团队在面对Unity游戏这座日益复杂的“城市”时，手中能有一张清晰的地图，而不是迷失在无数相互缠绕的“电缆”和“管道”之中。当你下次再面对一堆需要协调的管理器时，不妨停下来想一想：“这里是不是该有一个Facade了？”