Re:Re: [程式] Unity的Singleton Pattern實作-Instance

[gsyung (阿爾．克萊茵)]

身為在業界的老鳥，我也很贊同，不必設限該用則用，不該用則不用。但如果是剛入行的程式，我會建議多去試不用singleton的寫法，知道有不同的做法後，再來選擇用singleton，跟不思考就用，能獲得的成長是不一樣的。

※ 引述《cjcat2266 (CJ Cat)》之銘言：
: ※ 引述《littleshan (我正在想要換什麼)》之銘言：
: : 先感謝分享，但這邊提出一些不同的看法。
: : Singleton 本身並不會降低耦合，實際上它造成很強烈的耦合。
: 感謝分享，我也想要提出一些意見提供參考
: 剛踏入業界的時候，我也是非常小心地遵從教科書上的教誨
: 大部分 "缺點多" 或者 "不建議使用" 的系統設計方式一概不碰
: 與老鳥們合作一段時間之後，反而有不太一樣的見解
: 我們家的共識是，全域變數用起來心裡會有疙瘩，沒錯
: 但是當其方便性夠值得的時候，還是就安心用下去吧
: 當然，前提是得保有紀律，不落入教科書提及的眾多圈套中
: 我們在乎的方便性不單只是程式寫起來簡不簡潔
: 是否在debugger裡面的watch window能方便檢視也很重要
: 過去我有幾次提出不同重構singleton的方法
: 同事們往往都一語中的: "Good luck getting that in the watch window."
: 上篇推文有提到，不用singleton那manager類型的物件怎麼管理?
: 放在MainGame物件裡面? 那單一MainGame物件到頭來也是個singleton呀
: 追朔遊戲的最上層，總是會有某種形式的singleton存在
: 所以說要死都不用singleton又顯得有點綁手綁腳
: 如果硬是要只有MainGame這個類別才准許有singleton
: 其實對watch window稍微不太友善
: 首先要在watch window裡面輸入g_mainGame
: 然後要嘛要手動展開g_mainGame找到想要檢視的manager
: 要嘛得多存個g_mainGame.m_myManager在watch window
: 當MainGame規模變大、如此手續重複次數變多，watch window使用效率就下降了
: 又如果為了抽象性，還把眾多manager藏到的更神祕的地方
: 那在一個隨便的break point要去挖資料還得更費工夫
: 我們的做法是，manager類型的直接用全域變數沒關係
: 像是InputManager, NpcManager, ObjectManager
: 我們都直接用赤裸裸的全域變數g_inputMgr, g_npcMgr, g_objManager
: 好處是不管遊戲停在哪個break point
: 我要看NPC的清單，然後檢視特定NPC的資料
: 只要在watch window輸入g_npcMgr就好，不用從別的出發點爬過去
:   + g_npcMgr
:   |--+ m_aNpc[kMaxNpcs]
:      |--+ m_aNpc[0]
:      |      m_name    "my NPC"
:      |      m_health  90
:      |--+ m_aNpc[1]
:             ...
: 當遇到全域變數相關的問題時
: 我們的做法是見招拆招，目前沒有遇到什麼瓶頸
: 該重構時就重構吧，過度擔心反而開發起來綁手綁腳的
: 一個遊戲的開發方向與路程永遠是未知領域
: 系統架構沒有最佳解，想要做出 "最正確" 與 "最完美" 的架構，反而是另外一個陷阱
: 能夠實作出目標遊戲機制的架構，就是個可行的架構
: 老話一句:
: "Make games, not game engines."
: (除非你是在開發Unity或Unreal XD)
: 以上是我對singleton的一點看法
: P.S. 這不代我認為全域變數可以隨便用
:      該有的紀律還是要有

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.140.15.194
※ 文章網址: https://www.ptt.cc/bbs/GameDesign/M.1505219101.A.C76.html
→ coolrobin: 說實話，其實你可以推文...
→ dreamnook: 同意1F xD
→ Schottky: 這字數大概要推到第四行了，我認為回文並無不妥
推 chchwy: 贊成回文 之前GameDesign版推文成章的風氣太嚴重了
推 cjcat2266: 這樣說來好像也對喔
→ grezod: 夠精闢的觀念回文很好啊 推文反而容易被忽略