身为在业界的老鸟，我也很赞同，不必设限该用则用，不该用则不用。但如果是刚入行的程式，我会建议多去试不用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
: |