[程式] Singleton Pattern實作-Instance

[feather623 (小羽毛)]

開發過稍微複雜一點的遊戲的人大概都遇過這個狀況：

●●●

寫了一個負責掌控全局的腳本(許多人習慣命名為GameManager)，它知道玩家現在幾等、
目前是處於第幾關、遊戲是進行中or暫停中，所有需要使用它資訊的物件都必須在程式碼
中宣告並引用之，並且還要開發者自己去拉reference(如圖)，如果線沒牽好，遊戲甚至
還有可能強制終止。

●●●

https://i.imgur.com/gqwJv0u.jpg

當你在其他腳本裡撰寫了public GameManager GM;，就會看到上圖的畫面。這個步驟本身
是正確且可行的，然而，在降低耦合性的程式設計原則下，這並不是工程師所崇尚的作法
。

既然自始至終，所有物件提到的GameManager都是指涉同一個對象，無一例外，那有沒有
什麼方法可以避免這一再拉reference的步驟呢？

這時，我們可以藉助C#的一個特性，單例(Singleton)。

單例，顧名思義，就是在整個系統架構裡面，這個腳本只會有唯一一個代表人，可以免去
手動指定的流程。

https://i.imgur.com/vPmOtZK.jpg

如圖中第7行，我們創造了一個公開(public)但靜態(static)的GameManager，並且命名為
Instance(這也是習慣上的命名，要取名做TheChosenOne也可以XD)。

再來看到第12行的Awake()函式，我們必須把Instance指向this，也就是GameManager它自
己。

經過這兩個步驟，就完成單例的宣告了。

註：之所以將單例的指定放在Awake()裡面，是為了讓這一層關係早在其他腳本呼叫Insta
nce前就搭建起來，避免其他腳本在Start()呼叫了Instance，卻獲得Instance是null的狀
況。

https://i.imgur.com/Nnzp0NR.jpg

我們再開另外一個腳本來檢查結果，當我按下鍵盤的S鍵時，就會在Console中顯示當前的
關卡，而關卡資訊是來自GameManager.Instance.curStage。

https://i.imgur.com/e0ad8eL.jpg

如此一來就不再需要第7行的宣告，也不用親手幫每一個物件掛上GM的reference，可說是
一個便捷又具有設計美感(?)的做法，在越大型的專案裡功效就越顯著！
--
我是羽毛，目標是成為遊戲工程師，請多多指教！
羽毛的電玩新手村
https://tinyfeather1997.wordpress.com
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.249.56.86

※ 編輯: feather623 (111.249.56.86), 09/10/2017 11:58:30
推 coolrobin: 幫推，不過是不是在標題或內文前面加上unity會比較好?
→ coolrobin: 會比較便於搜尋
好的，謝謝你的建議~
推 b87088: 羽毛推
HiHi 請問你是XD
※ 編輯: feather623 (111.249.56.86), 09/10/2017 13:17:03
→ MBRSL: Singleton很容易被濫用造成bug，只建議在小規模的專案使用
推 cjcat2266: 我覺得如果謹慎、分工正確、又有規矩地使用，應該還好
→ cjcat2266: 碰過幾個大專案有多個singleton合作，但是大家很謹慎
→ cjcat2266: 沒看到什麼嚴重的濫用情況，所以我覺得還是看使用者
推 joseph33: http://wiki.unity3d.com/index.php/Singleton 可以寫
→ joseph33: 個singleton的base class出來用
→ b87088: 之前gamejam隊友~，看code才知道每個人都自己寫自己的sin
→ b87088: gleton~~
→ y3k: Singleton我只推薦用在API入口 不然很容易有bug
→ bantime: 我挺好奇會造成什麼bug?有案例嗎?
→ dreamnook: 好奇是甚麼bug+1(沒遇過
推 MBRSL: 最常見是全域變數類的bug，詳細理念請見下一篇文章
→ y3k: 等一下 上面的真的都沒遇過喔XD static變數造成的bug就不用提
→ y3k: 了 我也遇過繼承的問題、Singleton自己去跟其他物件黏答答在
→ y3k: 一起發生的問題... 雖然沒到罄竹難書的地步但是這個寫法一看
→ y3k: 到我都得先花個一兩天把它的code翻一遍才安心
→ y3k: 雖然這不是一個不能用的寫法 但是遇到比較沒經驗或便宜行事的
→ y3k: 捧油用 就容易把人的腦洞放大... 我只能這樣講
→ dreamnook: 大概是我們平時在寫的時候都有特別注意過吧@@
→ y3k: 我覺得是專案規模不大 或有一個SA之類的專職在處理規劃架構
→ dreamnook: 也是 近年來都很少碰過20人以上的專案了
→ y3k: 20人如果全RD 那不少耶= =
→ dreamnook: 整個專案20人 不是純RD 20人xD
→ bantime: 還真的沒遇過..可能我在實作singleton的時候
→ bantime: 都是保證唯一的狀況下 例如你不會同時出現兩個選角介面吧
推 dreamnook: