あなたが何かおかしなことをしているのでない限り、余分な保持/解放は問題を引き起こさないはずです。
したがって、ivarに保存することに実際の問題はありません...
これを行うより良い理由は、入力を保存することではなく、クラスのテスト可能性/再利用性を向上させることです。これをivarにすることで、動作を変更するために別のクラスを挿入できます。
デフォルトでシングルトンを提供するアクセサーを作成することを検討しますが、このように選択した場合は、別のクラスを注入できます。
- (SingletonClass *)singletonObj;
{
return _singletonObj = _singletonObj ?: [SingletonClass sharedInstance];
}
アップデート:
また、「このシングルトンを使用することと、ivarを使用することをなぜ異なるものにするのか」についても検討する価値があります。ivarのようにクラス全体で使用する場合、なぜまったく異なる方法でアクセスするのですか?
たとえば、私が使用する場合、managedObjectContext
アプリ全体に1つしかないことがよくあります。多くの人がアプリデリゲートをシングルトンとして使用し、その方法でアクセスしますが、私はそれをivarとして渡すことを好みます。概念的にmanagedObjectContext
は、これは他のivarと同じように使用している別のオブジェクトですが、アクセス方法を精神的に切り替える必要があるのはなぜですか?
これは悪いです
[(MyAppDelegate *)[[UIApplication sharedApplication] delegate] managedObjectContext];
良い
self.managedObjectContext;
これにより、2つの利点が得られます。
私のクラスにへの呼び出しが散らばっている場合、[(MyAppDelegate *)[[UIApplication sharedApplication] delegate] managedObjectContext];
このプロジェクトからそれを取り除いて、危険な検索と置換なしに別のプロジェクトに配置することは困難です。「アクセサー」の1つの場所でシングルトンにアクセスする場合、コードを変更する場所は1つだけです。
私の本番アプリでは、データを永続的にしたいのでmanagedObjectContext
、永続ストアを使用してオブジェクトにアクセスできるようにしますが、テストでは、テスト間で状態を永続化したくないので、オブジェクトを非永続にします代わりに保存してください。