服務定位器 Service Locator

遊戲設計模式 Game Programming PatternsDecoupling Patterns

提供服務的全局接入點，避免使用者和實現服務的具體類耦合。

動機

一些遊戲中的對象或者系統幾乎出現在程序庫中的每一個角落。 很難找到遊戲中的哪部分永遠不需要內存分配，記錄日誌，或者隨機數字。 像這樣的東西可以被視爲整個遊戲都需要的服務。

我們考慮音頻作爲例子。 它不需要接觸像內存分配這麼底層的東西，但是仍然要接觸一大堆遊戲系統。 滾石撞擊地面（物理）。 NPC狙擊手開了一槍，射出子彈（AI）。 用戶選擇菜單項需要響一聲確認（用戶界面）。

每處都需要用像下面這樣的東西調用音頻系統：

// 使用靜態類？
AudioSystem::playSound(VERY_LOUD_BANG);

// 還是使用單例？
AudioSystem::instance()->playSound(VERY_LOUD_BANG);

儘管每種都能獲得想要的結果，但是我們會絆倒在一些微妙的耦合上。 每個調用音頻系統的遊戲部分直接引用了具體的AudioSystem類，和訪問它的機制——是靜態類還是一個單例。

這些調用點，當然，需要耦合到某些東西上來播放聲音， 但是直接接觸到具體的音頻實現，就好像給了一百個陌生人你家的地址，只是爲了讓他們在門口放一封信。 這不僅僅是隱私問題，在你搬家後，需要告訴每個人新地址是個更加痛苦的問題。

有個更好的解決辦法：一本電話薄。 需要聯繫我們的人可以在上面查找並找到現在的地址。 當我們搬家時，我們通知電話公司。 他們更新電話薄，每個人都知道了新地址。 事實上，我們甚至無需給出真實的地址。 我們可以列一個轉發信箱或者其他“代表”我們的東西。 通過讓調用者查詢電話薄找我們，我們獲得了一個控制找我們的方法的方便地方。

這就是服務定位模式的簡短介紹——它解耦了需要服務的代碼和服務由誰提供（哪個具體的實現類）以及服務在哪裏（我們如何獲得它的實例）。

模式

服務 類定義了一堆操作的抽象接口。 具體的服務提供者實現這個接口。 分離的服務定位器提供了通過查詢獲取服務的方法，同時隱藏了服務提供者的具體細節和定位它的過程。

何時使用

當你需要讓某物在程序的各處都能被訪問時，你就是在找麻煩。 這是單例模式的主要問題，這個模式也沒有什麼不同。 我對何時使用服務定位器的最簡單建議是：少用。

與其使用全局機制讓某些代碼接觸到它，不如首先考慮將它傳給代碼。 這超簡單，也明顯保持瞭解耦，能覆蓋你大部分的需求。

但是…… 有時候手動傳入對象是不可能的或者會讓代碼難以閱讀。 有些系統，比如日誌或內存管理，不該是模塊公開API的一部分。 傳給渲染代碼的參數應該與渲染相關，而不是與日誌之類的相關。

同樣，代表外設的系統通常只存在一個。 你的遊戲可能只有一個音頻設備或者顯示設備。 這是周圍環境的屬性，所以將它傳過十個函數讓一個底層調用能夠使用它會爲代碼增加不必要的複雜度。

如果是那樣，這個模式可以幫忙。 就像我們將看到的那樣，它是更加靈活、更加可配置的單例模式。 如果用得好，它能以很小的運行時開銷，換取很大的靈活性。

記住

使用服務定位器的核心難點是它將依賴——在兩塊代碼之間的一點耦合——推遲到運行時再連接。 這有了更大的靈活度，但是代價是更難在閱讀代碼時理解你依賴的是什麼。

服務必須真的可定位

如果使用單例或者靜態類，我們需要的實例不可能不可用。 調用代碼保證了它就在那裏。但是由於這個模式是在定位服務，我們也許要處理失敗的情況。 幸運的是，我們之後會介紹一種處理它的策略，保證我們在需要時總能獲得某些服務。

服務不知道誰在定位它

由於定位器是全局可訪問的，任何遊戲中的代碼都可以請求服務，然後使用它。 這就意味着服務必須在任何環境下正確工作。 舉個例子，如果一個類只能在遊戲循環的模擬部分使用，而不能在渲染部分使用，那它不適合作爲服務——我們不能保證在正確的時間使用它。 所以，如果你的類只期望在特定上下文中使用，避免模式將它暴露給整個世界更安全。

示例代碼

重回我們的音頻系統問題，讓我們通過服務定位器將代碼暴露給代碼庫的剩餘部分。

服務

我們從音頻API開始。這是我們服務要暴露的接口：

class Audio
{
public:
  virtual ~Audio() {}
  virtual void playSound(int soundID) = 0;
  virtual void stopSound(int soundID) = 0;
  virtual void stopAllSounds() = 0;
};

當然，一個真實的音頻引擎比這複雜得多，但這展示了基本的理念。 要點在於它是個沒有實現綁定的抽象接口類。

服務提供者

只靠它自己，我們的音頻接口不是很有用。 我們需要具體的實現。這本書不是關於如何爲遊戲主機寫音頻代碼，所以你得想象這些函數中有實際的代碼，瞭解原理就好：

class ConsoleAudio : public Audio
{
public:
  virtual void playSound(int soundID)
  {
    // 使用主機音頻API播放聲音……
  }

  virtual void stopSound(int soundID)
  {
    // 使用主機音頻API停止聲音……
  }

  virtual void stopAllSounds()
  {
    // 使用主機音頻API停止所有聲音……
  }
};

現在我們有接口和實現了。 剩下的部分是服務定位器——那個將兩者綁在一起的類

一個簡單的定位器

下面的實現是你可以定義的最簡單的服務定位器：

class Locator
{
public:
  static Audio* getAudio() { return service_; }

  static void provide(Audio* service)
  {
    service_ = service;
  }

private:
  static Audio* service_;
};

靜態函數getAudio()完成了定位工作。 我們可以從代碼庫的任何地方調用它，它會給我們一個Audio服務實例使用：

Audio *audio = Locator::getAudio();
audio->playSound(VERY_LOUD_BANG);

它“定位”的方式十分簡單——依靠一些外部代碼在任何東西使用服務前已註冊了服務提供者。 當遊戲開始時，它調用一些這樣的代碼：

ConsoleAudio *audio = new ConsoleAudio();
Locator::provide(audio);

這裏需要注意的關鍵部分是調用playSound()的代碼沒有意識到任何具體的ConsoleAudio類； 它只知道抽象的Audio接口。 同樣重要的是，定位器 類沒有與具體的服務提供者耦合。 代碼中只有初始化代碼唯一知道哪個具體類提供了服務。

這裏有更高層次的解耦： Audio接口沒有意識到它在通過服務定位器來接受訪問。 據它所知，它只是常見的抽象基類。 這很有用，因爲這意味着我們可以將這個模式應用到現有的類上，而那些類無需爲此特殊設計。 這與單例形成了對比，那個會影響“服務”類本身的設計。

一個空服務

我們現在的實現很簡單，而且也很靈活。 但是它有巨大的缺點：如果我們在服務提供者註冊前使用服務，它會返回NULL。 如果調用代碼沒有檢查，遊戲就崩潰了。

幸運的是，還有一種設計模式叫做“空對象”，我們可用它處理這個。 基本思路是在我們沒能找到服務或者程序沒以正確的順序調用時，不返回NULL， 而是返回一個特定的，實現了請求對象一樣接口的對象。 它的實現什麼也不做，但是它保證調用服務的代碼能獲取到對象，保證代碼就像收到了“真的”服務對象一樣安全運行。

爲了使用它，我們定義另一個“空”服務提供者：

class NullAudio: public Audio
{
public:
  virtual void playSound(int soundID) { /* 什麼也不做 */ }
  virtual void stopSound(int soundID) { /* 什麼也不做 */ }
  virtual void stopAllSounds()        { /* 什麼也不做 */ }
};

就像你看到的那樣，它實現了服務接口，但是沒有幹任何實事。 現在，我們將服務定位器改成這樣：

class Locator
{
public:
  static void initialize() { service_ = &nullService_; }

  static Audio& getAudio() { return *service_; }

  static void provide(Audio* service)
  {
    if (service == NULL)
    {
      // 退回空服務
      service_ = &nullService_;
    }
    else
    {
      service_ = service;
    }
  }

private:
  static Audio* service_;
  static NullAudio nullService_;
};

調用代碼永遠不知道“真正的”服務沒找到，也不必擔心處理NULL。 這保證了它永遠能獲得有效的對象。

這對故意找不到服務也很有用。 如果我們想暫時停用系統，現在有更簡單的方式來實現這點了： 很簡單，不要在定位器中註冊服務，定位器會默認使用空服務提供器。

日誌裝飾器

現在我們的系統非常強健了，讓我們討論這個模式允許的另一個好處——裝飾服務。 我會舉例說明。

在開發過程中，記錄有趣事情發生的小小日誌系統可助你查出遊戲引擎正處於何種狀態。 如果你在處理AI，你要知道哪個實體改變了AI狀態。 如果你是音頻程序員，你也許想記錄每個播放的聲音，這樣你可以檢查它們是否是以正確的順序觸發。

通常的解決方案是向代碼中丟些對log()函數的調用。 不幸的是，這是用一個問題取代了另一個——現在我們有太多日誌了。 AI程序員不關心聲音在什麼時候播放，聲音程序員也不在乎AI狀態轉換，但是現在都得在對方的日誌中跋涉。

理念上，我們應該可以選擇性地爲關心的事物啓動日誌，而遊戲成品中，不應該有任何日誌。 如果將不同的系統條件日誌改寫爲服務，那麼我們就可以用裝飾器模式。 讓我們定義另一個音頻服務提供者的實現：

class LoggedAudio : public Audio
{
public:
  LoggedAudio(Audio &wrapped)
  : wrapped_(wrapped)
  {}

  virtual void playSound(int soundID)
  {
    log("play sound");
    wrapped_.playSound(soundID);
  }

  virtual void stopSound(int soundID)
  {
    log("stop sound");
    wrapped_.stopSound(soundID);
  }

  virtual void stopAllSounds()
  {
    log("stop all sounds");
    wrapped_.stopAllSounds();
  }

private:
  void log(const char* message)
  {
    // 記錄日誌的代碼……
  }

  Audio &wrapped_;
};

如你所見，它包裝了另一個音頻提供者，暴露同樣的接口。 它將實際的音頻行爲轉發給內部的提供者，但它也同時記錄每個音頻調用。 如果程序員需要啓動音頻日誌，他們可以這樣調用：

void enableAudioLogging()
{
  // 裝飾現有的服務
  Audio *service = new LoggedAudio(Locator::getAudio());

  // 將它換進來
  Locator::provide(service);
}

現在，對音頻服務的任何調用在運行前都會記錄下去。 同時，當然，它和我們的空服務也能很好地相處，你能啓用音頻，也能繼續記錄音頻被啓用時將會播放的聲音。

設計決策

我們討論了一種典型的實現，但是對核心問題的不同回答有着不同的實現方式：

服務是如何被定位的？

如果服務不能被定位怎麼辦？

在這些選項中，我看到最常使用的是會找到服務的簡單斷言。 在遊戲發佈的時候，它經歷了嚴格的測試，會在可信賴的硬件上運行。 無法找到服務的機會非常小。

在更大的團隊中，我推薦使用空服務。 這不會花太多時間實現，可以減少開發中服務不可用的缺陷。 這也給你了一個簡單的方式去關閉服務，無論它是有漏洞還是干擾到了現在的工作。

服務的服務範圍有多大？

到目前爲止，我們假設定位器給任何需要服務的地方提供服務。 當然這是這個模式的典型的使用方式，另一選項是服務範圍限制到類和它的依賴類中，就像這樣：

class Base
{
  // 定位和設置服務的代碼……

protected:
  // 派生類可以使用服務
  static Audio& getAudio() { return *service_; }

private:
  static Audio* service_;
};

通過這樣，對服務的訪問被收縮到了繼承Base的類。這兩種各有千秋：

我的通用準則是，如果服務侷限在遊戲的一個領域中，那麼限制它的服務範圍在一個類上面。 舉個例子，獲取網絡接口的服務可能限制於在線聯網類中。 像日誌這樣應用更加廣泛的服務應該是全局的。

參見