[C#/Unity] 回顧所使用過的 Singleton 實作方式 – Difference of Four Singleton practicing

Singleton 是個充滿爭論的設計模式,從某些角度來看,Singleton 並不完全符合物件導向設計原則的所有理念,但是 Singleton 又某種程度上的不易被取代。所以一般來說的建議是:少用、小心地用。

過去我曾設計兩套實作方式,企圖用集合管理的方式,完全取代單一 Singleton 的使用:

不過最近我又把單一 Singleton 撿回來使用了,並回顧了我所遭遇過的使用情境,對何時該用何種 Singleton 實作,立下一套主觀原則。

我在 Unity 使用過的四種 Singleton 實作

  • 單一獨立的 Singleton 類別
  • 單一獨立的 MonoBehaviour 與其綁定的 DontDestroy 物件
  • 單一的 MonoBehaviour 註冊系統與其綁定的 DontDestroy 物件
  • 單一的介面(interface) 註冊系統與其依賴的單一的 MonoBehaviour、綁定的 DontDestroy 物件

單一獨立的 Singleton 類別

相當簡易的一個方式,

using UnityEngine;
using System.Collections;

public class Singleton<T> where T : class, new() {
  private static object m_oLock = new object ();
  private static T m_oInstance = null;
  public static T Instance {
    get {
      lock (m_oLock) {
        if (m_oInstance == null) {
          m_oInstance = new T ();
        }
        return m_oInstance;
      }
    }
  }
}

只要類別繼承了 Singleton,便可以擁有 Singlton pattern 的效果,並且有簡單的 thread-safe 功能。

優點

  • 相當簡單易用,隨時可以在專案中大量建立 Singlton pattern (不過當然不建議如此做),輕量且不依賴其他條件。
  • 只有在第一次被使用的時候會進行實體化,雖然時機點不可控,但可以保證需要的時候一定有實體可呼叫。

缺點

  • 整個專案的穩定性 (thread-safe等) 與耦合性 (code coupling) 完全取決於後續的實作方式,容易在不知不覺間過度濫用。
  • 繼承關係會因此實作方式受限,不易沿用部分代碼或進行彈性設計。

使用情境

對於單一的工具,與其他功能不會有主動的互動,而且在專案中具有唯一、貫穿整個專案的特性時,可以考慮使用。目前我用於:事件的註冊管理專案Assets資源的管理等獨立工具上。

** 另外為了避免 thread-safe 的錯誤,我會避免在這個類型的 Singleton 中使用 Unity API。

單一獨立的 MonoBehaviour 與其綁定的 DontDestroy 物件

詳細作法可以參考:http://wiki.unity3d.com/index.php/Singleton

這個作法是上個實作的 MonoBehaviour 版本,是在 Unity 的架構下誕生的特殊存在,會自動產生所需要的 GameObject 進行掛載。

優點

類似一般 Singlton 簡單易用,雖然我只使用過一次。

缺點

因為 Unity 本身是個特殊的架構,所以依附在這架構下的 Singleton 變得相當複雜且不易控。如果許多 Singleton 都有自己的 GameObject,我覺得還蠻討厭的。

使用情境

應該不打算再次用在專案開發上,可能的使用情境就是獨立於專案外,為了可以輕易複製到其他專案使用的小型工具。

MonoBehaviour 為基底的註冊系統

我將這系統的基底類別命名為 GameSystemMono,是在過去文章中介紹過的一套實作,算是對上一個實作進行設計的替代方案。

優點

  • 只有一個 GameObject 作為掛載個體,利用管理器進行各個 Singleton 系統(GameSystemMono) 的添加、移除、呼叫等動作,也因此可以控制每個 Singleton 之間的初始化順序。
  • 配合 Unity 的 Inspector,可以對每個系統保留作為設定的參數欄位,也可以在 Editor 即時監控數值變化,是保留 Unity 編輯器優點的一個方案。
  • 因為有 MonoBehaviour 為基底,所以除了添加及移除,還可以暫時停止系統 (SetActive為 false),有著額外的可控性。

缺點

  • 因為多了一個註冊添加的動作,不能保證隨時可以呼叫,開發時要先行規劃整套系統的建構、呼叫次序。
  • 繼承上相當受限,無法與其他插件或特別設計的 MonoBehaviour 子類別合併使用。
  • 呼叫上程式碼會較冗長一點,並且為了避免不斷重複查詢的動作,會需要像 Component 一般自行暫存的動作。
  • 沒有實作 thread-safe。

使用情境

目前作為我的專案大架構之一,許多與 Unity 的互動與設計會應用單一 MonoBehaviour 來管理其他的複數物件,便會將之註冊於 GameSystemMonoManager 之中。

一般來說一個遊戲的設計,可能會再細分成許多子系統,通常一個子系統我便會包裝成一個 GameSystemMono 作為單一的功能呼叫窗口,避免系統之下的許多物件或腳本相互耦合。

至於每個子系統的回饋與互動,則盡量採用事件的方式來進行傳遞,事件的註冊與管理使用上述的第一種 Singleton 來實作。

介面 (interface) 為基底的註冊系統

我命名為 GameModule,也是在過去文章所實作的一套系統,用來與 GameSystemMono 互補。

優點

  • 嚴格來說不需要任何掛載實體,不過為了使用方便還是會依賴一個 GameObject 。
  • 基底部使用類別而用介面 (interface),所以不會影響到其他的繼承關係設計。
  • 可以透過擴充不同的介面實作得到不同功能,例如 Update、LateUpdate、SlowUpdate、Sleep 等,使用彈性比 GameSystemMono 高。

缺點

  • 與 GameSystemMono 相同,需要註冊添加的動作,不能保證隨時可以呼叫。
  • 呼叫上程式碼會較冗長一點,並且為了避免不斷重複查詢的動作,會需要像 Component 一般自行暫存的動作。
  • 無法透過 Inspector 進行彈性控制。
  • 沒有實作 thread-safe。

使用情境

GameModule 的使用情境我設定為:一個完整且相對獨立的功能,不太需要因為專案變化而進行調整的模塊,除了被動呼叫也會有主動的回饋,是與上述的第一種 Singleton 實作最大差別。

目前我所設計的 GameModule 有場景切換管理整個遊戲的流程控制網路連線與封包的控制等比較通用於專案之間的功能。

小結

雖然說 Singleton pattern 容易呼叫且應該避免耦合,但是要完全不耦合是相當困難的,因此對於這幾個 Singleton 實作,我自己訂下的依賴原則是:可以向上層依賴,但要盡力避免向下層依賴。

而層與層的關係如下:

singleton-class

廣告

2 thoughts on “[C#/Unity] 回顧所使用過的 Singleton 實作方式 – Difference of Four Singleton practicing

  1. 分享我們這邊的經驗,
    Singleton -> GameMoudle -> 其他類別 -> Unity API,
    對於一般功能我們會傾向往右依賴,不能往左依賴,
    而對於流程功能,則沒有任何限制,
    而依賴通常採用 C# Event 來作為溝通手段。

    如此之後要搬功能到其他專案重複使用,
    可以不用改任何程式抑或是連同左邊層的功能一起搬,
    砍掉左邊層類別也不會影響到右邊層的功能類別。

    Liked by 1 person

    • 我們對 “其他類別" 的定義可能不太一樣 XD

      不過我想基本原則的想法是一樣的,只是一些架構上特定部分的名詞或者對於 Singleton 的定位不一樣,畢竟這些東西好像沒有很專有的中文名詞可以溝通,我只是將我自己的用語寫在文章之中而已

      按讚數

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s