C#? Unity? シングルトン

[エンジン]

ずっとDXライブラリを触っていたのですが、先日Unityにも手を出しました。

そこでなのですが、c++のコーディング技術に関する本でシングルトンは極力避けるようにとの記述があり、乱用はしないようにと考えていたのですが、どうやらc#(Unity?)ではそういうことでもないとよ話を小耳に挟み気になったので質問させていただきました。

大丈夫ということなら使ってみようということで考えて見たのですが、シングルトンの考え方であったり、在り方が分からず困っています。

Managerのような唯一のものをシングルトンにするというイメージなのですが、1つのシーンに1つなのか、プロジェクト全体で1つなのか、はたまたマップ生成のマネージャに1つ、アクターの生成に1つという風に複数あってもいいのかというところが分かりません。

あと、質問を全て書き終えてからでなんなのですが、Unityの質問はここでしてもよろしいものなのでしょうか？c#はUnityでしか触ったことがなく今ひとつ感覚が掴めないでいます。

[hide]

シングルトンが妥当な対象であるならばシングルトンで実装すればいいでしょうし、
そうでないのなら普通に作るべきでしょう。
例えば端末に保存する設定値みたいな、アプリの実行中常にその対象しかないやつはシングルトンで良いかと思います。
逆にマップ生成に1個とかは微妙かと思います。
マップの生成は本当に同時に1つしか存在しえないのでしょうか。ゲームによっては複数あったほうが使いやすい場合もあるでしょう。
アクターの生成だって、複数箇所で同時に別の設定で使いたいかもしれませんね。
この辺はビルダーパターンで作ったほうが使いやすいんじゃないでしょうか。

ちなみに Managerのような唯一のもの とおっしゃっていますが、Managerと言われても周りの人はピンと来ないですよ。
Managerみたいな実際お前何するんだよ的な命名のクラスの多くはただの分解不足な肥満気味のクラスであることが多いです。

フォーラムルールのページの最初にありますが、

質問はＣ言語に限りません。プログラムや開発環境等に関することなら何でも気軽に質問して下さい。

なのでここでも全然問題ないかと思われます

[エンジン]

確かにざわざわシングルトンにしたいものも多くはないですよね＞＜；
でも、必要であれば作っていいのですね。

ビルダーパターンというものを調べてみたいと思います。

マネージャーを作っていて、シングルトンの話をしてもらったのと、それで調べたところでちょうどマネージャーの様なとの記述があったのと、直接質問した人にすんなり通じたことでつい一般的な考え方なのかと思ってました。

これからも気軽に質問したいと思います！

ありがとうございました。

[Dixq (管理人)]

何をシングルトンにしていいか、まだよく分からない時は、「とにかくシングルトンは諸悪の根源だ」と思って避けてコーディングした方がよいクセがつくと思います。
シングルトンは多重化できないことや、単体テストが難しくなることや、初期化タイミングの違いによりバグが混入しやすくなるなどの多くの欠点があります。
多重化しないものをシングルトンにと考えていたものであっても、例えば「キーボードは１つだからシングルトンでいい」と思って設計していたが、
ゲームで2P対戦やオンライン対戦になったら、その設計が破綻したってケースもありえます。

> Managerのような唯一のものをシングルトンにするというイメージなのですが

名前だけではわかりませんが、それはかなり高い確率で間違っています。
何かを指令する役の人がシングルトンになる必要はないはずです。
とりあえずシングルトンは一つもなしで設計してみて、自分でシングルトンの使いどころが理解できてから導入した方がよいと思います。

シングルトンは下手に導入して楽になる要素よりも、安易に取り入れて悪影響に悩まされることの方が大きいのです。