クリーンなアーキテクチャに従って、デザイン Interactor はすべてのビジネス ロジックを含む部分です。Interactor という用語は、私にとって非常に紛らわしいものです。Interactor は、データとプレゼンターのような 2 つの異なるレイヤーの間で相互作用するように思えます。
使用するのに適切な用語ですか? どなたかインターアクターの目的をクリアしていただけませんか? どのパターンに従いますか？Interactor が私に思われるものではない場合、レイヤー間相互作用の設計パターンは何ですか?
Interactor は、「ビジネス ロジック」の概念とは関係のない設計パターンです。より深いレベルの詳細には触れませんが、Interactor パターンは Command パターンの拡張です。各「ビジネス ロジック」オブジェクトは、クライアントに対して実行される単純な命令である「ブラック ボックス」として扱われ、操作を実行するオブジェクトをその実行方法を知っているオブジェクトから分離します。(詳細な説明については、参考文献を参照してください)。
Android 環境では、バックグラウンド スレッドで時間のかかるタスクを実行するようにプログラマーに要求する単純な「ルール」があるため、インタラクター パターンは「コマンド パターン」を拡張し、スレッド化のレイヤーを追加します。この複雑なものはすべて、スケーラブルで保守可能で、(ほぼ間違いなく) 理解可能なコードを必要とする「クリーンなアーキテクチャ」を作成するために実装されています。
質問について.. ¿レイヤー間の相互作用の設計パターンは何ですか? 状況によっては、複数の正解がある場合があります。エントリ ポイントとして単純なインターフェイスを使用できるため、Adapter パターンまたは Facade パターンを使用できます。また、より高度な処理を行う場合は、イベントバス システムを実装できます。
出典: 設計パターンの簡単な説明 - auth Alexander Shvets. 14 ページ (アダプター)、32 ページ (コマンド)、47 ページ (ファサード)
From what I'm reading, it's the equivalent of the Presenter in the Model View Presenter (MVP) architecture.
It does business logic, not store or display data. It create a separate layer independent of how or where data is stored or displayed. It only cares about inputs and outputs in any format. It could be used in a combination of the Observer, Adapter, and Façade patterns to be an interface for callbacks, a generic extension point of the code, and a decoupled entry point for any non UI or data-storage usage, respectively.
I assume it is called an Interactor because the View interacts with it to calculate values and refresh any displayed UI elements and it interacts with the Model objects to extract data. It could also interact with a database for CRUD operations, but I think that's mostly addressed in the Repository Pattern as that isn't really business logic.
MVPパターンです。はい、あなたが言ったように、プレゼンターとデータの間のメディエーターです（レストコールまたは共有設定またはSqliteの形式として）。