AppDelegate ではなく、シングルトン クラスでグローバル データ (つまり、NSArray または NSDictionary) を定義することをお勧めします。
どうしてこれなの?
ありがとう、フランク
AppDelegate は、作業中のプロジェクトに固有のものです。作業中のアプリの新しいバージョンを開始する場合、または (可能性が高い) iOS から Mac に移植する場合など...
AppDelegate はそのまま残ります。
このようなグローバル情報をシングルトンに入れることで、それが実行されているアプリから独立したクラスを作成します。
また、AppDelegate にアプリ固有のもの (applicationWillEnterBackground など) を保持することをお勧めします。他のものでそれを詰まらせたくありません。
コードの単体テストを作成する場合は、コードのテストがより困難になるため、グローバル シングルトンを避ける必要があります。同様に、公開されたNSArray
orNSDictionary
のような値を持つことは、私の経験では、すぐにバグが発生しやすいコードです。
私が便利だと思った設計パターンは、必要なすべてのプロパティを持つ構成またはグローバル値オブジェクトを実際に作成することです。通常、このクラスは、plist ファイルからロードできるNSArray
orをラップします。NSDictionary
このオブジェクトは AppDelegate でインスタンス化でき、View Controller やその他のオブジェクトをインスタンス化するときに渡されます。テストで構成オブジェクトを簡単にモックできるため、これはよりテストしやすくなります。
plist ファイルからロードされたときに、この種の構成オブジェクトがどのように見えるかの例:
インターフェース:
@interface ConfigManager : NSObject {
}
@property (readonly) NSString* masterUser;
@property (readonly) UIImage* masterUserImage;
@end
次に、.m
@interface ConfigManager ()
@property (strong) NSDictionary* configDict;
@end
@implementation ConfigManager
-(id)init {
self = [super init];
if ( self ) {
NSString *pathStr = [[NSBundle mainBundle] pathForResource:@"AppConfig" ofType:@"plist"];
NSData *plistData = [NSData dataWithContentsOfFile:pathStr];
NSString *error = nil;
NSPropertyListFormat format;
self.configDict = (NSDictionary*)[NSPropertyListSerialization propertyListFromData:plistData mutabilityOption:NSPropertyListImmutable format:&format errorDescription:&error];
if(nil == self.configDict || nil != error ) {
NSLog(@"%@",error);
return nil;
}
}
return self;
}
-(NSString*)masterUser {
return [self.configDict objectForKey:@"masterUser"];
}
-(UIImage*)masterUserImage {
NSString* imageName = [self.configDict objectForKey:@"masterUserImage"];
return [UIImage imageNamed:imageName];
}
もちろん、必要に応じてオブジェクトのプロパティを変更してください。このアプローチの優れた点は、画像の読み込みなど、アプリのグローバル構成を処理するために必要な共通コードを一度実装できることです。これにより、コード ベース全体で同じコードを何度も複製することによって発生する一般的なバグを防ぐことができます。
AppDelegate を散らかさないようにします。ほとんどの AppDelegate は、グローバル データの流し台のようなものです。そこにすべてが投げ込まれます。シングルトン (または ARC の場合は通常のクラス) を使用すると、実際のグローバル データが基本的な AppDelegate 関数から分離されます。
Singelton が良い解決策だとは思いません。アプリケーション グローバルは、AppDelegate のような正直でグローバルにアクセス可能なクラスに保持する方がよいでしょう。
18 年前、シングルトン コンストラクトはデザイン パターンであると考えられていましたが、後に Erich Gamma は、そのパターンを彼の著書「Design Patterns – Elements of Reusable Object-Oriented Software」に追加するのは悪い考えであることに気付きました。
今日、Java のような最新の言語では、Singelton は悪です。初期化されると削除できないため、単体テストが非常に妨げられます。したがって、少なくともJavaでは、シングルトンを使用すると設計が悪い可能性が高くなります。正直に言うと、グローバル オブジェクトがある場合は、それをそのように処理し、疑似グローバル要素の背後に隠さないでください。
ただし、Objective-C には仮想マシンがないため、おそらくシングルトンは単体テストに影響しません (これについてはよくわかりません)。
単体テストに影響しない場合は、[NSFileManager defaultManager] のようにシングルトンを使用すると便利な場合があります。
しかし、私は NSArray または Dictionary をシングルトンに保存しません。