VIPER アーキテクチャでのプロトコルの利点については、少し混乱しています。DI (Dependency Injection) がプロトコルを介して達成され、オブジェクト間の直接的な依存関係を回避するのに役立つことを理解しています - 同意します。
しかし、私は使用の観点から実際の利点を見ています。例としては、特にユニットテスト (Interactor 部分のテスト) でプロトコルがどのように役立つかが挙げられます。
メソッド Callback の using ブロックを介して同じことを達成することはできませんか? 誰かがいくつかの例で使用法の観点から理解するのを手伝ってくれることを願っています
乾杯
たとえば、Interactor から Presenter へのコールバックを使用すると、Presenter のテストが難しくなる可能性があります。
プレゼンターが (Interactor から送信された) 入力を処理する方法のテストを作成する場合、テストでは、Presenter で Interactor を呼び出す何らかのメソッドを呼び出す必要があります。これにより、Interactor はデータを Presenter に送信します。 .
Presenter に Interactor によって定義されたプロトコルを実装させることで、テストは Presenter で適切な入力メソッドを直接呼び出すことができます。
プロトコルを宣言する限り、オブジェクトではなくロールのモックのスタイルで TDD を実践しています ( http://www.jmock.org/oopsla2004.pdf )。プロトコルは、オブジェクトがどのようにそれを行うかではなく、何をするか (その役割) に焦点を当てることで、より良い抽象化を提供するのに役立ちます。
プロトコル自体は、単体テストにはほとんど価値がありません。単体テストは、テスト中のシステムの依存関係のテスト ダブル ( http://martinfowler.com/bliki/TestDouble.html ) を提供します。依存関係を具象クラスとして公開したとしても、テスト用のテスト ダブルを作成できます。
Objective-C では、OCMock ( http://ocmock.org ) や OCMockito ( https://github.com/jonreid/OCMockito )などのモッキング ライブラリを使用して、オブジェクトのスタブ、スパイ、またはモックを作成できます。具体的なクラス。
Swift では、依存関係として使用される各具体的なクラスをサブクラス化することで、テスト ダブルを作成できます。
つまり、プロトコルは単体テストを容易にするために使用されるのではなく、より高いレベルの抽象化で、アプリケーションが何をするかを記述するために使用されます。
以下は、抽象プロトコルを持つことが実際にどのように有益であったかを示す例です。
ProfileUserActionsユーザーが画面上で実行できるアクションchangeNameを表すプロトコルを作成しましたchangeAddress。プレゼンターは を実装し、ビューはを依存関係としてProfileUserActions受け入れました。ProfileUserActionsユーザーが画面上のボタンをタップすると、ビューは適切なメッセージをそのuserActionsオブジェクトに送信します。
分析を追加したいと思ったとき、新しい独立したProfileAnalyticsクラスを作成することができましたProfileUserActions。ビューとプレゼンターの間に分析オブジェクトを挿入しました。これにより、ビューまたはプレゼンターを変更することなく、アプリが分析をキャプチャできるようになりました。
プロトコルを使用すると、VIPER 構造の実装を簡単に交換できます。たとえば、ファイルシステムに書き込みを行っているクラスを操作するインタラクターがあるとします。単体テストでファイルシステムをテストしたくないので、代わりにファイルシステムの書き込み操作をプロトコルの背後にあるインタラクターに配置すると、ファイルシステムの書き込み操作をメモリ内実装に置き換えることができます。
インタラクター自体のプロトコルに関しては、選択についてもう少し現実的になるのが得策だと思います。テスト用のインタラクターを簡単に作成でき、テストの一部として副作用が発生しない場合は、おそらくプロトコルは必要ありません。一方、他の多くの依存関係を作成する必要がある場合は、インタラクターから取得する出力をより簡単に偽造できるように、インタラクターをプロトコルに準拠させることをお勧めします。