はじめに
VIPERは、現代のブロガーのように、自身の周りに非常に多くの誇大宣伝を集めています。 彼女はこの建築の理想を神聖に信じる人々と憎しみの両方に現れました。 VIPER嫌悪者は、異なる性質の多くの誤解を引き起こしました。 それらのいくつかを次に示します。
- VIPERモジュールのクラスが多すぎます
- 高い入場しきい値-経験の浅いプログラマーはそれを使用できません
- 多くの問題に対する標準化された解決策はありません。
- プレゼンター-メディエーションのみを扱う不要なコンポーネント
- VIPERが提供する99％のテストカバレッジが必要なのはなぜですか？
VIPERを使用して私が書いた多数のプロジェクトを自慢することはできませんが、それでもそうです。 そして、私の経験に基づいて、これらすべての誤解に対する非常に論理的な答えがあると言えます。
多数のクラスについて
そもそも、アーキテクチャには多くのクラスとプロトコルがあるのには理由があります。 これは、不十分な接続性と高いエンゲージメントを確保するために必要であり、これらを組み合わせることで、コードを理解しやすく、保守しやすく、再利用可能にし、外部の変更に耐えられます。 これにより、プロジェクトの作業が容易になり、チーム開発であるかどうかは関係ありません。 VIPERは、これらの原則を遵守することにより、モジュールの一部を簡単に変更できるようにし、それによって設計または要件の変更に迅速に対応します。
入場閾値について
エントリーのしきい値について。 彼は本当に「ビッグ」ですが、初心者向けです。 私は隠しません-私自身はVIPERモジュールの書き方をすぐに理解しませんでしたが、その時は数ヶ月の開発経験しかありませんでした。 そして、会社で最初にVIPERを使用することに決めたとき、同僚は完成したモジュールのコードレビューを1つだけ作成して、独自のコードを作成しました。 したがって、アーキテクチャは完全に単純であり、自分で強制的に理解することは困難です。
規格について
一見すると、VIPERのすべてが理解できるように見えます-ビューの表示、Interactorが提供する、ルータースイッチ、およびプレゼンターの接続。 しかし、これは氷山の一角にすぎません。 最初のモジュールの作成を開始すると、多くの場合、特定のコードを記述する場所を理解できません。 多くのプログラマーは、1つの問題をさまざまな方法で解決できる他の人のソリューションに基づいています。 そして、プログラマーはVIPERが悪いと言い始めています。 これはVIPERについてではなく、人々が見ているまさにその例についてのようです。 人が自分のコードをレイアウトする前にアーキテクチャを十分に理解している可能性はどのくらいですか？ 路上で恐竜と出会う確率は50％です。 したがって、まず第一に、自分の頭で考える必要があり、それからすべてが所定の位置に収まります。 実際、VIPERでは、モジュールのコンポーネント間の責任が非常に明確に分けられています。 そして、どこに関連するのかわからない場合は、VIPERについてもう一度読み直すか、 Rambler＆Coの本をご覧ください。
プレゼンターについて
PresenterはViewとInteractorの仲介役として機能し、このコンポーネントはVIPERモジュールでは不要であると考えられています。 ここでは、おそらく明らかなことを言いますが、それでもです。 まず、Presenterはモジュール全体の状態を保存します。 次に、Presenterは入出力モジュールとして機能します。 第三に、彼はViewからInteractorなどにコマンドを転送するだけでなく、決定を下します。
テストについて
最後に、なぜVIPERが提供する99％のテストカバレッジが必要なのですか？ 一見、質問に対する答えは表面にあります-そして、アプリケーションの正しい動作を確認します。 しかし、ここでは問題はおそらく図にはありませんが、VIPERが許可しているという事実です。 また、他のいくつかのアーキテクチャとは異なり、十分に簡単になります。 複雑なプロジェクトを開発する場合、これは大きなプラスになります。
おわりに
はい、VIPERには欠点があります（完璧なものはありません）が、無視しないでください。 ただし、すべてのプロジェクトで連続して使用しないでください。 それでも、アプリケーションアーキテクチャは、熱狂的な理由だけでなく、さまざまな要因と要件に基づいて選択されます。 そして、それが良いか悪いかを言う前に、2〜3個のアプリケーションを書いて、すべてを適切に計量する価値があります。
私は、平方センチメートルあたりVIPERという言葉を超えなかったことを望みます。
読んでくれてありがとう！