「シングルトン」の使い方
クラスをシングルトン化する
public class PlayerData : MonoBehaviour
{
// シングルトン
private static PlayerData instance;
public static PlayerData Instance
{
get
{
if (null == instance)
{
instance = (PlayerData)FindObjectOfType(typeof(PlayerData));
if (null == instance) Debug.Log(" PlayerData Instance Error ");
}
return instance;
}
}
void Awake()
{
GameObject[] obj = GameObject.FindGameObjectsWithTag("Player"); //タグで判別
if (1 < obj.Length) Destroy(gameObject);
else DontDestroyOnLoad(gameObject);
}
// ここに処理を書く
}{
get
{
略
}
シングルトン化されたクラスへのアクセス
public int Gold = 0; PlayerData.Instance.Gold += 100;懸念点がなくはない
ワタシはSingletonがキライだより引用・Singleton と static 結合Singleton は static な結合を招く。インスタンスの数は問題ではない。アクセス方法を static に規定するのが悪。static 結合はテスト不能なクラスへの道。
・Singleton は単体テストの敵。
・まとめSingleton は現代のグローバル変数。結合度が高くテストしにくいコードを招く。SingletonでやりたいことはTyphoon などの DIコンテナを使えば美しく実現できる。
シングルトンパターンの誘惑に負けないより引用・「必要なインスタンスは1つだけ」という要望は、多くの場合推測にすぎない。クラスを作った時には「インスタンスは絶対に1つしかいらないだろう」と考えていても、後にそうもいかなくなることが多いのです。
・マルチスレッド環境での使用は特に危険が大きい。マルチスレッドでは、シングルトンオブジェクトへのアクセスにはロックが必要になりますが、単純なロックでは効率が良いとは言えないため、いわゆるDCLP(Double-Checked Lockingパターン)を使うことが増えています。しかし困ったことに、これだと危険性が高まってしまう恐れがあります。多くの言語で、DCLPはスレッドセーフでないということがわかっているからです。
・プログラム終了の際には、シングルトンも自動的にクリーンアップされることになります。ただし、複数のシングルトンがある時、どのような順序でクリーンアップされるかは決まっていません。相互に依存し合うシングルトンがアプリケーションに含まれている時、これは問題になります。アプリケーションのシャットダウン時に、あるシングルトンが別のシングルトンにアクセスしようとするけれど、そのシングルトンはすでにクリーンアップされてしまっている、という事態になる恐れがあるからです。
