他の言語の依存性注入フレームワークは、多くの場合、サーバー側の開発に焦点を当てています。したがって、コンポーネントのデフォルトのスコープはsingletonです。サーバーが特定の時間にそのサービスのいずれかのユースケースを実行する必要がある場合があることを考えると、これは理にかなっています。
ただし、デスクトップおよびモバイル開発では、通常、一度に1 つのユース ケースに対応しています。そして、特にモバイルでは、メモリの制約があります。したがって、Typhoon は新しいメモリ スコープをデフォルトとして導入します - TyphoonScopeObjectGraph。このスコープでは、コンポーネントの解決中の共有参照はすべて同じインスタンスを返します。この意味は:
- 循環依存関係 (デリゲートなど) を含むオブジェクト グラフ全体を読み込むことができます。iOS アプリの場合、これは通常、View Controller になります。
- ユースケースが完了したら、このオブジェクトグラフを破棄してメモリを再利用できます。
遅延シングルトンを作成するには:
もちろん、これはデフォルトですが、すべてのコンポーネントがこの動作を必要とするわけではありません。最初のリクエストまでインスタンス化されないシングルトンを作成するには:
definition.scope = TyphoonScopeSingleton;
definition.lazy = YES;
これを行った後:
- コールバック メソッドは、シングルトンに対して 1 回だけ呼び出されます。
- コンポーネントが使用されるまで実行されません。
TyphoonScopeObjectGraph、TyphoonScopePrototype (常に新しいインスタンスを返す)、TyphoonScopesingleton、および TyphoonScopeWeakSingleton の合計 4 つのスコープがあります。これらのそれぞれについての詳しい説明は Typhoon docs にあります。
代替アプローチ:
もう 1 つのアプローチは、コンテナにオブジェクト インスタンスを登録することでした。Typhoon では、特定のインスタンスを登録して何らかの役割を果たす簡単な方法はありません。ただし、任意のオブジェクトを挿入でき、アセンブリ内の他のコンポーネントを生成するコンポーネントを登録できます。したがって、次のことができます。
- (id)configProvider
{
return [TyphoonDefinition withClass:[ConfigProvider class]
configuration:^(TyphoonDefinition* definition){
//Typhoon 1.x was more explicit (withDefintion, withBool, withInstance, etc)
//in 2.0 you just use the word 'with'
[definition injectProperty:@selector(config) with:someObject];
}];
}
- (id)config
{
return [TyphoonDefinition withFactory:[self configProvider]
selector:@selector(config)];
//You can also have args here, eg @selector(configForEnv:)
}
この機能のドキュメントはこちらです。