本稿はDI FrameworkとDagger2.0の概要になります.
対象読者は下記です.
- DI Frameworkを使ったことがない人.
- Dagger2の初学者
スライドの下書きから起こしたものなのであしからず…
依存性
- 具象クラスとの関連は結合度を高める
- インタフェースに依存させたいが, “
new“が具象クラスへの依存性を生む
GitHubStore store = new GitHubDatabase();
制御の反転
依存性解決の方向を反転させれば解決する.
GitHub => new GitHubDatabase
↓ 反転 ↓
GitHub <= new GitHubDatabase
GitHubクラスが依存オブジェクトを決めるのではなく, GitHubクラスの依存オブジェクトを外から指定する.
class GitHub {
private GitHubStore store = new GitHubDatabase();
↓ refactoring↓
class GitHub {
GitHub(GitHubStore store) {...}
}
class Client { ...
public doSomething() {
new GitHub(new GitHubDatabase());
- 制御の反転. Inversion of Control
- ハリウッドの原則. Hollywood Principle
new, new, new…
制御を反転させるだけではオブジェクトを生成するコードがプロジェクト中に散在する.
ClientA:
new GitHub(new GitHubDatabase());
ClientB:
setDatabase(new GitHubDatabase());
ClientC:
create(new GitHubDatabase());
これは下記の問題を引き起こす.
もし, 永続化先をディスク領域に格納されるデータベースから, オンメモリキャッシュに変更したい場合, new GitHubDatabase()のコードを new GitHubMemcached()に置き換えなければならない.
ClientA:
new GitHub(new GitHubMemcached());
ClientB:
setDatabase(new GitHubMemcached());
ClientC:
build(new GitHubMemcached());
これは簡易な例で, 実際には生成オブジェクトの初期化や組み立てといったコードが散在することになり, それらを全て置換するのには骨が折れる.
アーキテクチャのレイヤー境界面も曖昧になり, テストの際に実装の詳細を差し替えられない.
Factory Pattern
生成処理をFactoryに委譲することで, これらの問題を軽減できる.
class GitHubStoreFactory {
public GitHubStore get() {
return new GitHubDatabase();
}
}
ClientA:
new GitHub(GitHubStoreFactory.get());
ClientB:
setDatabase(GitHubStoreFactory.get());
ClientC:
build(GitHubStoreFactory.get());
[]---->[]
------>[]
[]---->[]<---[]
------>[]-----------
Factoryを経由すればClientはインタフェース(GitHubStore)にだけ依存する.
Factoryの問題
Factory Patternは問題の全てを解決してくれない.
Factory関連のクラスは次の問題に悩まされる.
- 数多のクラスからオブジェクト生成を委譲され肥大化する.
- オブジェクトの生成順序, 構築方法にも関心を持つ責務過多.
- 膨大なボイラープレートコードが出来上がる
- SharedObject? Singleton?
- Lifecyle, Scopeの管理が必要になることもある
下記のようなコードがプロジェクト中に散在する.
Factory factory = new Cupcake.Factory(type, key);
factory.get();
Factory factory = new Donut.Factory(type, key);
factory.get();
Factory factory = new Eclair.Factory(type, key);
factory.get();
Factory factory = new Froyo.Factory(type, key);
factory.get();
Factory factory = new Gingerbread.Factory(type, key);
factory.get();
Factory factory = new Honeycomb.Factory(type, key);
factory.get();
DI Framework
こうした問題を軽減, 解決してくれるのが依存性注入に特化したDI Frameworkである.
DI Frameworkのメリット
- アーキテクチャのレイヤーをきれいに分離できる
- 依存オブジェクトの管理を委譲できる
- 柔軟なソフトウェアになる
- ボイラープレートコードを排除できる
- テストしやすいソフトウェアになる
DI Frameworkのデメリット
- ラーニングコストがかかる
- 自動生成コード含め, クラスの数が多くなる
- Frameworkの特性にあわせた依存性の管理
Dagger2
DI Frameworkの実装としてDagger2がある.
Dagger2の特徴は下記の通り.
- DI Framework for Java & Android
- No XML Configuration.
- 高速
- Annotation Processingベースでデバッグしやすい
- コンパイル時に依存性の検証を行う
- Googleがメンテナ
依存性の要求
Dagger2に依存オブジェクトを要求するには, 依存性を注入したい箇所に@Injectでアノテートする.
GitHubDatabase store = new GitHubDatabase();
↓ refactoring ↓
@Inject GitHubDatabase store;
GitHub(new GitHubDatabase()) {...}
↓ refactoring ↓
@Inject GitHub(GitHubDatabase store) {...}
依存オブジェクトの要求を受けたDagger2は適切なオブジェクトをそこに注入する.
@Inject GitHubDatabase store;
↑ inject ↑
Dagger2: new GitHubDatabase();
@Inject GitHub(GitHubDatabase store) {...}
↑ inject ↑
Dagger2: new GitHubDatabase();
依存性の注入には種類がある.
- Constructor Injection
- Field Injection
- (Setter Injection) Dagger2では未サポート
依存性の解決
Dagger2は依存オブジェクトをどのように解決しているのか.
@Inject GitHub(GitHubDatabase store) {...}
↑ inject ↑
Dagger2: new GitHubDatabase();
~~~~~~~~~~~~~~~~~~~~~
Whats happen!?
依存性の要求は, Dagger2管理下にある依存オブジェクトのコレクションから選択・解決される.
Constructorに@InjectアノテートをつけるとDagger2がこれを管理対象として収集する.
class GitHubDatabase {
@Inject GitHubDatabase() {...}
}
@Inject GitHubDatabase() {...}
|
| <登録>
↓
Dagger2
|
| <注入>
+-------> @Inject GitHub(GitHubDatabase db)
|
| <注入>
+-------> @Inject GitHubDatabase db;
依存性の充足
Constructorへの@Injectだけでは依存性を解決できないケースがある.
- インタフェースへの注入(具体化)
- プロジェクト管理外クラスの注入
- オブジェクトの構築を伴う生成, 及び注入
これらを含む依存性を充足させるにはProviderと呼ばれるファクトリメソッドを作る.
@Provides
@Provides
GitHubStore provideGitHubStore() {
return new GitHubDatabase();
}
OR...
@Provides
GitHubStore provideGitHubStore(GitHubDatabase store) {
return store;
}
- プロジェクト管理外クラスの注入
- オブジェクトの構築を伴う生成, 及び注入
@Provides
Retrofit provideGitHubRetrofit() {
return new Retrofit.Builder()
.baseUrl("https://api.github.com")
.addConverterFactory(GsonConverterFactory.create())
.build();
}
@Module
@Providesはモジュールクラス(@Module)のメソッドとして定義する.
@Module
class ApplicationModule {
@Provides
GitHubStore provideGitHubStore(GitHubDatabase store) {
return store;
}
}
Building the Graph
依存性のコレクションはGraphと呼ばれる.
RepositoryViewer
|
|
GitHub
|
|--------------------+
| |
GitHubWebApi GitHubDatabase
| |
| |
Retrofit Orma
Graphの設計図としてコンポーネントクラス(@Component)が必要になる.
@Component(modules=ApplicationModule.class)
interface ApplicationComponent {...}
GraphはComponent単位で生成・管理される.
Dagger2が管理するGraphにアクセスするにはComponentを経由する.
ApplicationComponent component
= DaggerApplicationComponent.builder()
.applicationModule(new ApplicationModule())
.build();
Sample code.
GitHub - Dagger2Sample
- app : Dagger2を使った基本的なsample
- subcomponent : Subcomponentとdependenciesのsample(後述)
テストとアーキテクチャ
DIが促進するもの.
- アーキテクチャにおける”レイヤー”を綺麗に分離することができる
- レイヤーが独立し, レイヤーごと差し替えるといったことが容易
RepositoryViewer
|
GitHub
|
|--------------------+
| |
GitHubWebApi GitHubDatabase
| |
Retrofit Orma
↓ Databaseをやめてオンメモリ管理 ↓
RepositoryViewer
|
GitHub
|
|--------------------+
| |
GitHubWebApi GitHubMemcached*
|
Retrofit
これらはテストの際に役立つ.
- テストは検証用モジュールで実施したい.
- Amazon Device Farm上ではテスト時間短縮のため, オンメモリDBで動作させたい. etc.
上記の詳細はSample codeを参照.
補足
これ以降はDagger2の補助機能.
Graphの操作
ComponentはGraph単位の操作を定義できる.
- Graphが属するScopeの宣言
- 依存性注入のポイントを外部公開
- 他Componentへの依存
Instant Injection
Graph生成後に, 特定オブジェクトの依存性を充足させる.
@Component(...)
interface ActivityComponent {
void inject(RepositoryViewerActivity activity);
}
class RepositoryViewerActivity extends Activity {
@Inject GitHub github;
protected void onCreate(Bundle b) {
ActivityComponent component
= DaggerActivityComponent.builder()
...
component.inject(this);
}
}
Scope
依存オブジェクトのライフサイクルを指定する.
- Application単位のSingleton性を持たせる
- Activity単位のSingleton性を持たせる etc.
@Singleton
class GitHubDatabase {...}
@ActivityScope
class GitHub {...}
Qualifier
依存性の注入先に識別子を付ける.
同じ型の依存性解決に使用される.
public GitHub(...,
@Named("executionScheduler") Scheduler executionScheduler,
@Named("postScheduler") Scheduler postScheduler) {
@Named("executionScheduler")
@Provides @ActivityScope
public Scheduler provideExecutionScheduler() {
return Schedulers.newThread();
}
@Named("postScheduler")
@Provides @ActivityScope
public Scheduler providePostScheduler() {
return AndroidSchedulers.mainThread();
}
Lazy injections
- 依存性の注入タイミングをオブジェクト取得時まで遅らせる遅延初期化
@Inject Lazy<GitHub> github;
github.get().findRepository(...);
Provider injections
- 依存性注入の都度newするnon-cached指定
@Provides LocalTime provideLocalTime() {
return LocalTime.now();
}
@Inject Provider<LocalTime> localTimeProvider;
localTimeProvider.get();
Subcomponent
- ComponentAとComponentBに親子関係を持たせる
- ComponentA＋ComponentBのGraphをつくる
@Component(...)
public interface ParentComponent {
ChildComponent newChildComponent(...);
}
@Subcomponent(...)
public interface ChildComponent {...}
dependencies
- ComponentAとComponentBに使用関係を持たせる
- ComponentA＋ComponentBのGraphをつくる
@Component(dependencies = DependeeComponent.class, ...)
public interface DependerComponent {...}
@Component(...)
public interface DependeeComponent {...}
以上.
