Kodeinは、Kotlinでの依存性注入のためのDagger 2の興味深い代替手段です

こんにちは、私の名前はウラジミールです。デジタルビジネスプラットフォームのチームで、SberTechのチーフITエンジニアとして働いています。 一度、昼食時に、Dagger 2の長所と短所、および実装で何を変更したいかについて話し合いました。 私たちはたくさんいます。したがって、私たちも多くのコードを書くので、その時点でアプリケーションにはすでに100500のメソッドと0.5トンのdexファイルがありました。 ポラキニンの頭脳、私たちはより少なく書くことはできないという結論に達しましたが、コンパイル中に生成されるコードの量を減らすことができます。 そこで、既存のGoogleのマストドンの代替品を探すことにしました。

選び方

選択したものの一般的な要件をいくつか説明しました。これにより、不必要なコード生成を防ぐことができます。



1.コンパイル時ではなく、実行時の依存関係の生成



このプロジェクトでは、multidexをはるかに超えて（すでに3回）、現在プロジェクトには4つのdexファイルがあります。 それらの形成における主要な役割は、コンパイル中のコード生成によって果たされます。



2.使いやすさ



状況を想像してください。 依存性注入のアプリケーションに基づいて、アーキテクチャをすばやくマップする必要があります。 フレームワークを使用して依存関係を実装するように指示されたチームから複数のジュニアを選択しました。 数時間の間、彼らはタスクを正常に完了し、プロジェクトは開始され、ランタイムに落ちませんでした。 迅速かつ効率的に、誰もが非常に幸せです。



ダガーの経験では、数時間では足りないと言われています。 そして数日ですら。 または数ヶ月。 使いやすさは高速につながります-そして、2000万人の顧客に依存関係を実装することになると、時間の問題は無視できません。



3. Dagger 2の機能以上の機能



Dagger 2は、多数の興味深い実装機能、スコープ、およびその他の依存性注入機能を提供します。 別のフレームワークに切り替えるときに、このすべてを失いたくありません。



その結果、いくつかのフレームワークに決着しました。

• フェザー
  
  
• プロトン
  
  
• コデイン
  
  
• 輸血
  
  
• つまようじ
  
  
• タイガー
  
  
• ライトセーバー
  
  

最後の4つのオプションはコード生成を使用するため、すぐに破棄しました。 石鹸の千枚通しを変更する理由 したがって、ビューは、フェザー、プロトン、コデインに落ちました。 ただし、最初の2つは長い間サポートされておらず、Kodeinは頻繁にリリースされます。 最後に、私たちはそれにとどまることにしました。

DIまたはSL？

少し叙情的な余談。 RedditとAndroidアーキテクトの間では、このフレームワークが依存性注入パターンの実装なのか、それともサービスロケーターの実装なのかについて議論があります。 サービスロケーターの支持者の議論：ジェイク・ウォートン自身が言ったように、彼はそれをうまく正当化しました。 しかし、それでも、フレームワーク開発者自身は自分をDIとして位置づけています。 チーム内では、このトピックについても議論しましたが、一般的な意見には至りませんでした。 Salomon Brys（フレームワーク開発者）に連絡しました。 私は答えを引用します：



「正確には、DIとSLライブラリには多くの違いがあります。

-DIライブラリは、一時的な依存関係と初期化の順序を理解する必要があります

-DIライブラリはスコープ（シングルトン、プロバイダーなど）を提供する必要があります

Kodeinは確かにDIライブラリです。」



フレームワークの作成者の立場に基づいて、Kodeinは、DIパターンの要件をより満たすため、サービスロケーターではありません。 個人的には、これは用語の問題であり、ツールの機能ではないと思います。 ライブラリがニーズを満たしていれば、それが実装するパターンの名前が何であるかは関係ありません。 主なことは、作業が問題なく行われることです。

実装と欠点

プロジェクトをモジュラーアーキテクチャに移行し始めたときに、Kodeinへの移行が可能になりました。つまり、すべての製品を互いに独立した別個のモジュールに表示します。 これにより手が自由になり、1つの小さなDagger 2モジュールでKodeinを置き換えることができました。 どちらかといえば、モジュールの以前の安定バージョンにロールバックして作業することができます。



最初は、Kotlinで記述され、その「トリック」を使用しているため、KodeinがJavaプロジェクトで正しく動作しないことを少し恐れていました。 しかし、Kodeinは優れたJavaコードをサポートしており、そこに依存関係を注入するのは、Dagger 2を使用するのと同じくらい簡単であることがわかりました（さらに簡単です-以下で詳しく説明します）。



Dagger 2からKodeinへの移行は、モジュールのサイズが非常に小さく、DIがあまり積極的に使用されなかったため、苦痛はありませんでした。 プロセスは十分にスムーズに進み、すべてはハーフキックから始まり、依存関係は意図したとおりに実装されるようになりました。 もちろん、Kaggerで書かれたプロジェクトにKodeinを実装する方が良いのですが、実験していたので、予想外の側面からライブラリを見る必要がありました。



それはすべて、Googleの覇権を終わらせ、Daggerから最高のDIフレームワークのタイトルを獲得する完璧な銀の弾丸のように見えます。 しかし、Kodeinは運用中に非常に重大な欠点を発見しました。

1. 最も重要で大きなマイナス点は、エラーの原因を理解せずにランタイムでエラーを取得できることです。 これは、Dagger 2が除去した最初のDaggerの問題であり、コンパイル中にコード生成に切り替えました。 コデインでも同じことがわかります。 この問題は、徹底的なテストと自動テストでの機能カバレッジによって解決されます。 さらに、フレームワーク自体は、テストの作成時にその機能を使用することを推奨しています。
   
   
2. 古い大規模なJavaプロジェクトがあり、Kotlinを接続する方法がない場合、Kodeinは適切ではありません。 しかし、それは長年の遺産の中で私たちの巨大なプロジェクトの病気です。
   
   
3. 実際のプロジェクトでは人気が低い。 これは、開発者のフィードバックが少なくリポジトリへの貢献者が少ないため、プロジェクトの開発が同じDaggerよりもはるかに遅いという事実につながります。 私たちが発見した欠点に今も苦しんでいるので、コデインを生産に持ち込むことは事実ではありません。
   
   

接続方法

フレームワークをプロジェクトに接続するのにそれほど時間はかかりません。gradleファイルで依存関係を指定するだけです：

implementation 'com.github.salomonbrys.kodein:kodein:4.1.0'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Kotlinでのリンク：

依存関係が宣言されるKodeinオブジェクトを宣言します。

 val kodein = Kodein {   bind<Message>() with provider { MessageFactory(0, 5) }   bind<DbProvider>() with singleton { SqliteDS.open("path/to/file") } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これについてさらに説明します。bindメソッドは、ここではクラスがインライン関数を使用してバインドされることを示しています。 ジェネリックでは、実装を注入するインターフェイスを示します。 バインディングの方法を説明するwithメソッドが来た後、Kodeinにはそれらのいくつかがありますが、それらについては少し後で説明します。この場合はプロバイダーとシングルトンです。 その後、中括弧で、注入するクラスの目的のインスタンスを置き換えます。



バインディング自体は次のようになります。

 class Controller(private val kodein: Kodein) {   private val ds: DataSource = kodein.instance() }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

原則として、複雑なことは何もありません。詳細を知らなくても、このフレームワークですぐに作業を開始できます。

バインディングの種類

Kodeinでは、いくつかの方法で依存関係を注入できます。

• ファクトリバインディングは、ファクトリから必要なタイプのインスタンスを取得するために引数を必要とするバインディングです。 インスタンスは、目的のタイプのインスタンスが要求されるたびに生成されます。
  
  

 val kodein = Kodein {   bind<Message>() with factory { type: Int -> MessageFactory(type) } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

• プロバイダーバインディング-このバインディングは、ストレージから必要なタイプのインスタンスを返します。ファクトリバインディングとは異なり、注入の引数は必要ありません。 リクエストに応じて毎回生成も行われます。
  
  

 val kodein = Kodein {   bind<Message> with provider { MessageFactory(6) } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

• シングルトンバインディング-ここではすべてが簡単です。遅延初期化を使用してシングルトンを作成します。 シングルトンの作成は一度だけ呼び出されます。
  
  

 val kodein = Kodein {   bind<DBProvider>() with singleton { SqliteDS.open("path/to/file") } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

• タグ付きバインディング-異なるインスタンスが生成されるタイプのタグ付けを許可します。
  
  

 val kodein = Kodein {   bind<Message>() with factory { type: Int -> MessageFactory(type) }   bind<Message>("ImageMessage") with provider { MessageFactory(10) }   bind<Message>("PaymentMessage") with singleton { MessageFactory(20) } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

機能もあります：

• 遅延初期化なしでシングルトンを作成します。 Kodeinオブジェクトが初期化されると、オブジェクトが生成されます。
  
  
• インスタンスを受信します（作成された場合のみ）。
  
  
• シングルトンとファクトリバインディングの混合バージョンの作成-引数を持つインスタンスを取得し、毎回新しいインスタンスを作成したくない場合。
  
  

もう1つの便利な機能は、バンドルを弱いリンクとソフトリンクでラップすることです。 これは、オブジェクトが長命であってはならないことを理解している場合に有利です。



興味深い機会は、ローカルストリームをバインドすることです。 つまり、各スレッドには、必要なインジェクションの独自のインスタンスがあります。

モジュールの作成

Kodeinでは、Dagger 2とほぼ同じ方法でバインディングをモジュールに保存できます。例：

 val apiModule = Kodein.Module {   bind<MessengerApi>() with singleton { DefaultMessengerApi() } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、Kodeinオブジェクトを初期化するときに、目的のモジュールを指定できます。

 val kodein = Kodein {   import(apiModule) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

バインドのオーバーライド

デフォルトでは、偶然の「二重」バインディングが予期せぬ結果につながり、問題を見つけるのに時間を浪費する可能性があるため、Kodeinはバインディングのオーバーライドを禁止しています。 しかし、そのような機会は存在します。 これは、たとえば、実装をある種のモックに変更できるクラスをテストする場合に便利です。 これは次のように行われます。

 val kodein = Kodein {   bind<MessengerApi>() with singleton { DefaultMessengerApi() }   /* ... */   bind<MessengerApi>(overrides = true) with singleton { CustomMessengerApi() } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

注入したい型のインスタンスが既にあるかどうかわからないことを想像してください。 そのような場合には、そのようなインスタンスが存在する場合にそれをオーバーロードできる設計があります。

 val kodein = Kodein {   /* ... */   import(testEnvModule, allowOverride = true) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

既にオーバーライドされたインスタンスを取得することが望ましいことを示すフラグもあります。 「新しい」インスタンスに「改善された」機能がある場合：

 val testModule = Kodein.Module(allowSilentOverride = true) {   bind<EmailClient>() with singleton { MockEmailClient() } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

遅延初期化

Kotlinからのプロパティの委任のおかげで、Kodeinでは、ほぼすべてのタイプのバインディングに対して、バインディングの遅延初期化を使用できます。

 class Controller(private val kodein: Kodein) {   private val messageFactory: (Int) -> Dice by kodein.lazy.factory()   private val dbProvider: DataSource by kodein.lazy.instance()   private val randomProvider: () -> Random by kodein.lazy.provider()   private val answerConstant: String by kodein.lazy.instance("answer") }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ランタイムでのクラスの生成方法

クラスは関数を埋め込むことで生成されます。 これにより、コンパイル時にコードにインジェクションを埋め込むことができます。 つまり、コンパイラは、組み込み関数が宣言される場所に必要なコードの一部を挿入するだけです。 コデインでのクラス生成は同じ原理で行われます。 インスタンスの作成に必要なタイプの選択は、具体化されたジェネリックによるものです。 詳細については、記事の最後にあるリンクをご覧ください。

JavaプロジェクトのKodein

しかし、プロジェクトがKotlinではなくJavaで書かれている場合はどうでしょうか？ Kodeinは、古き良きJavaでも同じ機能を提供しますが、いくつかの制限があります。 このフレームワークは、JSR-330仕様、特にJavaでDIに少なくとも一度遭遇したことがある人なら誰でも知っているInjectアノテーションを部分的にサポートします。



ここにはいくつかの欠点があります。 インジェクションは、インライン関数とジェネリックではなく、リフレクションの助けを借りて行われます。 したがって、リフレクションと多言語コンパイルによりパフォーマンスが低下します。 さらに、バインダーを含むオブジェクトはKotlinで作成する必要があります。条件がJavaのみの使用を示している場合、悲しいかな、Kodeinはあなたには適していません。



JavaプロジェクトでKodeinを使用するには、いくつかの手順を実行する必要があります。

1. JxInjectorをgradleに接続します。
   
   

 compile 'com.github.salomonbrys.kodein:kodein-jxinject:4.1.0'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2. jxIntectorモジュールをKodeinオブジェクトに追加します。

 val kodein = Kodein {   import(jxInjectorModule)   /* Other bindings */
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

3.バインドします。 これには2つの方法があります。 最初の方法は古典的な方法です。 必要なフィールドに注釈の挿入を記述し、メソッドを記述するだけです。すべてがDaggerの場合と同じように機能します。

  public class MyJavaController {   @Inject   public MyJavaController(Connection connection, FileSystem fs) {       /* ... */   }   /* ... */ }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2番目の方法は、特定のKodeinオブジェクトを使用することです。

 MyJavaController controller = Jx.of(kodein).newInstance(MyJavaController.class);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または：

 MyJavaController controller = new MyJavaController(); Jx.of(kodein).inject(controller);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

おわりに

夕方に文字通り基本を理解し、それをプロジェクトに実装し、さらにKotlinで記述して実稼働でテストすることを可能にする、シンプルで軽量なDIフレームワークですか？ 良さそうに聞こえますが、コデインではそれが真実になりました。



このフレームワークはDagger 2の100％の代替物ではありませんが、プロパー氏でさえ対処できず、追加のコード生成により新しいdexファイルが生成される可能性のあるコードの大胆なプロジェクトで使用できます。 しかし、小さなプロジェクトではコデインが悪いとは思わないでください。 Dagger 2に固有のメカニズムに関する知識を必要とせずに、依存関係の注入を大幅に簡素化します。



Kodeinはまた、Kotlinに非常に適していて、そのようなプロジェクトではかなり良い気分です。 ここで、少なくとも、クラスのコード生成は非常に興味深いです。これは、コティルンが提供するこれらの機会を支持する反射を伴うアプローチからの逸脱です。 残念ながら、この実験の一部として書かれたすべてのコードをまだ生産していません。フレームワークが私たちの足元を撃たないという100％の確実性がないからです。 研究は進行中です。

便利なリンク

• Kodein Founding Father Repository
• Kotlin言語のインライン関数の詳細については、 こちらをご覧ください。
• プロパティの委任の詳細については、 こちらをご覧ください。