データマネージャクラスとしてシングルトンを使用していますか？

Question

私は通常、データの格納を必要とするアプリケーションを作成し、このデータはプログラム全体で使用されます。しかしそれほど大したことではないので、私は通常このデータをロード/セーブするのにNSUserDefaultsを使用します。しかし、セーブ/ローディングコードは、データのパッキング/アンパックに伴って領域を占有します。グローバルシングルトン内で再利用可能なメソッドにこのコードを移動することをお勧めします。それはうまくいったようです。

でも、私は最近、シングルトンやグローバルオブジェクトの邪悪なことをたくさん読んでいます。私は第二の考えを持っています。シングルトンの使用は、ほとんど常に貧弱な設計の兆候であると人々はしばしば言います。ほとんどの場合、私は同意しません（このような単純な使い方は良いデザインパターンだと思いますが）、私は確かにこの問題について専門家ではありません。

だから、このような単純な方法でもシングルトンを使用していますか？もしそうなら、もっと良い選択肢は何ですか？

Answer 1

シングルトンが邪悪であることは間違いありません。おそらく時には過度に使用されることもありますが、場合によっては仕事にぴったりです。アプリケーションによっては、何らかの一般的なデータマネージャを持つことが理にかなっています。シングルトンパターンは、SDK自体（アプリケーションデリゲート、共有マネージャ、デフォルトセンターなど）で広く使用されています。ほとんどの場合、共有インスタンスにアクセスできるだけでなく、必要に応じて新しいインスタンスを作成できるため、これらは「純粋な」シングルトンではありません。

自分自身に質問する必要がある質問は、いつでもどこからでもデータマネージャの単一インスタンスにアクセスすることが有益かどうかということです。そうでない場合は、シングルトンはおそらく必要ありません。しかし、マルチスレッド環境でシングルトンを使用する場合は、競合状態（別のスレッドがリソースにアクセスしている間にスレッドを変更することができます）を心配する必要があります。ドキュメントでは、これをCocoa 。

例を挙げてみましょう - 私が書いたゲームのコードを使用しています。たとえば、GameMapクラスとTileクラスがあるとします。 GameMapは、Tileオブジェクトの2次元グリッドを表します。

GameMap *gameMap = [[GameMap alloc] init]; 
NSArray *theTiles = gameMap.tiles; 

GameMapのインスタンスは、タイルのグリッドを所有しており、ゲームマップが作成されたときにタイルを作成します。シングルトンは必要ありません。

あなたは「私は一度にGameMapを1つしか持っていません、それは大したことですか？」と言うかもしれません。保存されたゲームの読み込みや新しいレベルの読み込みはどうですか？

// In whatever class object owns the game map 
self.gameMap = [[GameMap alloc] initWithSaveData:saveData]; 

結論として、物事の他のインスタンスを管理するコードを持つクラスのインスタンスを作成します。できるだけグローバルなレベルを保ち、コードのスケーラビリティとメンテナンス性を向上させます。