Androidのリポジトリアンチパターン

記事の翻訳は、コース「AndroidDeveloper」の開始を見越して作成されました。プロフェッショナル」。

---

公式Androidアプリケーションアーキテクチャガイドでは、リポジトリクラスを使用して「アプリケーションの残りの部分がデータを簡単に取得できるようにクリーンなAPIを提供する」ことを推奨しています。ただし、私の意見では、プロジェクトでこのパターンを使用すると、厄介なスパゲッティコードに行き詰まることが保証されます。



この記事では、「リポジトリパターン」について説明し、それが実際にAndroidアプリケーションのアンチパターンである理由を説明します。

リポジトリ

前述のアプリケーションアーキテクチャガイドでは、プレゼンテーション層ロジックを編成するために次の構造を推奨してい







ます。この構造でのリポジトリオブジェクトの役割は次のとおりです



。リポジトリモジュールはデータ操作を処理します。これらはクリーンなAPIを提供するため、アプリケーションの残りの部分はこのデータを簡単に取得できます。彼らは、データを取得する場所と、データが更新されたときにどのAPI呼び出しを行うかを知っています。リポジトリは、永続モデル、Webサービス、キャッシュなどのさまざまなデータソース間の仲介と考えることができます。



基本的に、ガイドでは、リポジトリを使用してアプリケーションのデータソースを抽象化することを推奨しています。とてもリーズナブルで便利に聞こえますね。



ただし、チャットはバッグを投げる（この場合はコードを書く）のではなく、UML図を使用してアーキテクチャのトピックを明らかにすることを忘れないでください。アーキテクチャパターンの実際のテストは、コードでの実装と、その長所と短所の特定です。それでは、レビューする抽象度の低いものを見つけましょう。

Androidアーキテクチャブループリントv2のリポジトリ

約2年前、Android ArchitectureBlueprintsの「最初のバージョン」を確認しました。理論的には、クリーンなMVPの例を実装することになっていますが、実際には、これらの青写真はかなり汚いコードベースになりました。それらにはViewおよびPresenterという名前のインターフェイスが含まれていましたが、アーキテクチャの境界を設定していなかったため、本質的にMVPではありませんでした。あなたはここで与えられたコードレビューを見ることができます。



それ以来、Googleは、Kotlin、ViewModel、およびリポジトリを含むその他の「最新の」手法を使用して、アーキテクチャの青写真を更新してきました。これらの更新されたブループリントには、v2というプレフィックスが付いています。v2ブループリントのTasksRepository



インターフェースを見てみましょう。

interface TasksRepository {
   fun observeTasks(): LiveData<Result<List<Task>>>
   suspend fun getTasks(forceUpdate: Boolean = false): Result<List<Task>>
   suspend fun refreshTasks()
   fun observeTask(taskId: String): LiveData<Result<Task>>
   suspend fun getTask(taskId: String, forceUpdate: Boolean = false): Result<Task>
   suspend fun refreshTask(taskId: String)
   suspend fun saveTask(task: Task)
   suspend fun completeTask(task: Task)
   suspend fun completeTask(taskId: String)
   suspend fun activateTask(task: Task)
   suspend fun activateTask(taskId: String)
   suspend fun clearCompletedTasks()
   suspend fun deleteAllTasks()
   suspend fun deleteTask(taskId: String)
}

コードを読む前でも、このインターフェイスのサイズに注意を払うことができます。これはすでにウェイクアップコールです。1つのインターフェイスでこのような数のメソッドを使用すると、大規模なAndroidプロジェクトでも疑問が生じますが、ここでは、コードが2000行しかないToDoアプリケーションについて説明しています。なぜこのかなり些細なアプリケーションがそのような巨大なAPIサーフェスを持つクラスを必要とするのですか？

神のオブジェクトとしてのリポジトリ

前のセクションの質問に対する回答は、TasksRepositoryメソッドの名前でカバーされています。このインターフェースのメソッドは、重複しない3つのグループに大まかに分けることができます。



グループ1：

fun observeTasks(): LiveData<Result<List<Task>>>
   fun observeTask(taskId: String): LiveData<Result<Task>>

グループ2：

   suspend fun getTasks(forceUpdate: Boolean = false): Result<List<Task>>
   suspend fun refreshTasks()
   suspend fun getTask(taskId: String, forceUpdate: Boolean = false): Result<Task>
   suspend fun refreshTask(taskId: String)
   suspend fun saveTask(task: Task)
   suspend fun deleteAllTasks()
   suspend fun deleteTask(taskId: String)

グループ3：

  suspend fun completeTask(task: Task)
   suspend fun completeTask(taskId: String)
   suspend fun clearCompletedTasks()
   suspend fun activateTask(task: Task)
   suspend fun activateTask(taskId: String)

次に、上記の各グループの責任範囲を定義しましょう。



グループ1は基本的に、LiveData機能を使用したオブザーバーパターンの実装です。グループ2は、データストアへのゲートウェイに加えてrefresh、リモートデータストアがリポジトリの背後に隠れているために必要な2つのメソッドです。グループ3には、基本的にアプリケーションドメインロジックの2つの部分（タスクの完了とアクティブ化）を実装する機能メソッドが含まれています。



したがって、この1つのインターフェイスには3つの異なる責任があります。それがとても大きいのも不思議ではありません。また、単一のインターフェイスの一部として1番目と2番目のグループが存在することは許容できると主張できますが、3番目のグループを追加することは不当です。このプロジェクトをさらに開発する必要があり、それが実際のAndroidアプリケーションになる場合、3番目のグループはプロジェクト内のドメインストリームの数に正比例して成長します。うーん。



非常に多くの責任を共有するクラスには、神聖なオブジェクトという特別な用語があります。これは、Androidアプリケーションで広く使用されているアンチパターンです。 ActivitieとFragmentは、このコンテキストでは標準的な容疑者ですが、他のクラスもDivineオブジェクトに縮退する可能性があります。特に名前が「マネージャー」で終わっているとしたら？



待ってください... TasksRepositoryのより良い名前を見つけたと思います：

interface TasksManager {
   fun observeTasks(): LiveData<Result<List<Task>>>
   suspend fun getTasks(forceUpdate: Boolean = false): Result<List<Task>>
   suspend fun refreshTasks()
   fun observeTask(taskId: String): LiveData<Result<Task>>
   suspend fun getTask(taskId: String, forceUpdate: Boolean = false): Result<Task>
   suspend fun refreshTask(taskId: String)
   suspend fun saveTask(task: Task)
   suspend fun completeTask(task: Task)
   suspend fun completeTask(taskId: String)
   suspend fun activateTask(task: Task)
   suspend fun activateTask(taskId: String)
   suspend fun clearCompletedTasks()
   suspend fun deleteAllTasks()
   suspend fun deleteTask(taskId: String)
}

現在、このインターフェースの名前は、その責任をはるかによく反映しています。

アネミックリポジトリ

ここで、「ドメインロジックをリポジトリからプルすると、問題は解決しますか？」と質問する場合があります。さて、Googleマニュアルの「アーキテクチャ図」に戻りましょう。



たとえばcompleteTask、TasksRepositoryからメソッドを抽出したい場合、それらをどこに配置しますか？Googleが推奨する「アーキテクチャ」によると、このロジックをViewModelの1つに移動する必要があります。そんなに悪い決断ではないようですが、本当にそうです。



たとえば、このロジックを1つのViewModelに配置しているとします。次に、1か月後、アカウントマネージャーは、ユーザーが複数の画面からタスクを完了できるようにしたいと考えています（これは、これまでに使用したすべてのToDoマネージャーに関連しています）。 ViewModel内のロジックは再利用できないため、複製するか、TasksRepositoryに返す必要があります。明らかに、どちらのアプローチも悪いです。



より良いアプローチは、このドメインストリームをカスタムオブジェクトに抽出し、それをViewModelとリポジトリの間に配置することです。その後、さまざまなViewModelがそのオブジェクトを再利用して、その特定のスレッドを実行できるようになります。これらのオブジェクトは、「ユースケース」または「相互作用」として知られています..。ただし、コードベースにユースケースを追加すると、リポジトリは本質的に役に立たないテンプレートになります。彼らが何をするにしても、それはユースケースによりよく適合します。 Gabor Varadiはこの記事でこのトピックをすでに取り上げているので、詳細には触れません。私は彼が「貧弱なリポジトリ」について言ったほとんどすべてを購読します。



しかし、なぜユースケースはリポジトリよりもはるかに優れているのでしょうか。答えは簡単です。ユースケースは個別のストリームをカプセル化します。したがって、徐々にDivineオブジェクトに成長する1つのリポジトリ（ドメインコンセプトごと）の代わりに、いくつかの非常に焦点を絞ったユースケースクラスがあります。ストリームがネットワークと保存されているデータに依存している場合は、適切な抽象化をユースケースクラスに渡すことができ、これらのソース間で「調停」されます。



一般に、不要な抽象化を回避しながら、リポジトリがDivineクラスに劣化するのを防ぐ唯一の方法は、リポジトリを削除することであるように見えます。

Android以外のリポジトリ。

ここで、リポジトリがGoogleの発明であるかどうか疑問に思われるかもしれません。いいえそうではありません。リポジトリパターンは、Googleがアーキテクチャガイドで使用することを決定するずっと前に説明されていました。



たとえば、Martin Fowlerは、彼の著書「Patterns of EnterpriseApplicationArchitecture」でリポジトリについて説明しています。彼のブログには、同じ概念を説明するゲスト記事もあります。 Fowlerによると、リポジトリはストレージ層の単なるラッパーであり、高レベルのクエリインターフェイスと、場合によってはメモリ内のキャッシュを提供します。ファウラーの観点からは、リポジトリはORMのように動作します。



Eric Evansは、彼の著書Domain DrivenDesignでリポジトリについても説明しています。彼が書きました：

, , , — . , . , , .

上記の引用の「リポジトリ」を「ルームORM」に置き換えることができ、それでも意味があることに注意してください。したがって、ドメインドリブンデザインのコンテキストでは、リポジトリはORMです（手動で実装されるか、サードパーティのフレームワークを使用して実装されます）。



ご覧のとおり、リポジトリはAndroidの世界では発明されていません。これは、すべてのORMフレームワークが構築されている非常に健全な設計パターンです。ただし、リポジトリがそうではないことに注意してください。リポジトリがネットワークアクセスとデータベースアクセスの違いを抽象化しようとするべきだと主張した「古典」はありません。



実際、私は彼らがこのアイデアを素朴で自滅的だと思うだろうと確信しています。その理由を理解するために、今回はJoel Spolsky（StackOverflowの創設者）による別の記事を読むことができます。「漏れのある抽象化の法則。」簡単に言えば、ネットワーキングはデータベースアクセスとは大きく異なり、重大なリークはありません。

Androidでリポジトリがアンチパターンになった経緯

それで、Googleはリポジトリパターンを誤って解釈し、ネットワークアクセスを抽象化するという素朴なアイデアを導入しましたか？疑わしい。このGitHubリポジトリで、



このアンチパターンへの最も古いリンクを見つけました。これは、残念ながら非常に人気のあるリソースです。この特定の作者がこのアンチパターンを発明したかどうかはわかりませんが、Androidエコシステム内で一般的なアイデアを広めたのはこのリポジトリだったようです。Google開発者は、おそらくそこから、または2次ソースの1つから入手しました。

結論

そのため、Androidのリポジトリはアンチパターンになっています。紙の上では見栄えがしますが、些細なアプリケーションでも問題が発生し、大規模なプロジェクトでは実際の問題につながる可能性があります。



たとえば、別のGoogleブループリントでは、今回はアーキテクチャコンポーネントについて、リポジトリを使用すると、最終的にNetworkBoundResourceなどのgemが作成されました。サンプルブラウザのGitHubはまだ小さな〜2KLOCアプリであることに注意してください。



私の知る限り、公式ドキュメントで定義されている「リポジトリパターン」は、クリーンで保守可能なコードと互換性がありません。



読んでいただきありがとうございます。いつものように、コメントや質問を以下に残してください。