この投稿は、記事の無料翻訳です。 なぜViperは、 セルゲイ・ペトロフによる次のアプリケーションにとって悪い選択なのか

過去1年間、誰もがVIPERについて書きました。 このアーキテクチャは、本当に開発者に刺激を与えます。 しかし、実際には、ほとんどの記事はかなり偏っています。 彼らはこのネガティブな側面については黙って、この建築パターンの急勾配を示すだけです。 しかし、彼は他の人よりも劣らない問題を抱えています。 そして、この記事では、VIPERが彼らが言うほど良くない理由と、それがあなたのアプリケーションのほとんどに適さない理由を説明しようとします。

アーキテクチャの比較に関するいくつかの記事では、通常、VIPERは他のMVCアーキテクチャとはまったく異なると主張しています。 しかし、実際には、VIPERは通常のMVCであり、コントローラーはインタラクターとプレゼンターの2つの部分に分かれています。 ビューはそのままで、モデルはエンティティに名前が変更されました。 ルーターには特別な注意が必要です。はい、他のアーキテクチャでは略語でこの部分に言及していませんが、暗黙的に（ pushViewController



を呼び出すと、単純なルーターを作成します）またはより明白です（例としてFlowCoordinators）。

VIPERが提供する「グッズ」について話しましょう（ この本を参照します ）。 目標2を見てみましょう。これは、SRP（共有責任の原則）を指します。 それは失礼に聞こえますが、これを利点と見なすにはどのような種類のエキセントリックが必要ですか？ あなたは問題を解決するための報酬を受け取ります。流行の言葉を一致させるためではありません。 はい、TDD、BDD、単体テスト、レルムまたはSQLite、依存性注入、その他多くのことを引き続き使用しますが、これらはすべて使用目的だけでなく、クライアントの問題を解決するためにも使用します。

テスト。

これは別の興味深い側面であり、非常に重要なタスクです。 良い面としては、多くの人がテストについて話しているので、テストに関する別の記事を書くことができますが、実際にアプリケーションをテストする人は少なく、正しい人も少ないです。

主な理由の1つは、良い例がないことです。 assert 2 + 2 == 4



単体テストの作成方法に関する記事はかなりありますが、実際の例はありません（ただし、 Artsyはアプリケーションをオープンソースのままにしており、プロジェクトを確認する必要があります）。

VIPERは、すべてのロジックを責任を共有する多くの小さなクラスに分けることを提案しています。 これによりテストが容易になりますが、常にそうではありません。 はい、単純なクラスの単体テストを書くのは簡単ですが、これらのテストのほとんどは何もテストしません。 たとえば、ほとんどのプレゼンターメソッドを見てみましょう。これらは、ビューと他のコンポーネントとの間のプロキシにすぎません。 このプロキシのテストを作成できます。これにより、コードのテストカバレッジが向上しますが、これらのテストは役に立ちません。 また、副作用があります。コードを変更するたびに、これらの役に立たないテストを更新する必要があります。

テストの正しいアプローチには、インタラクターとプレゼンターの即時テストが含まれる必要があります。これらの2つの部分は互いに密接に関連しているためです。 さらに、ロジックを2つのクラスに分割するため、単一のクラスよりも多くのテストが必要です。 これは単純な組み合わせです。クラスA



は4つの可能な状態があり、クラスB



6つの可能な状態があり、それらの組み合わせには24の可能な状態があり、それらをテストする必要があります。

テストを簡素化する適切なアプローチは、複雑なコードを多数のクラスに分割するのではなく、コードを清潔にすることです。

奇妙なことに、ビューのテストは、ビジネスロジックの一部をテストするよりも簡単です。 ビューは特定のプロパティのコレクションであり、これらのプロパティの外観を継承します。 FBSnapshotTestCaseを使用して、ステータスと外観を比較できます。 このことは、カスタムトランジションのような特別なケースをまだ処理しませんが、どれくらいの頻度で使用しますか？

設計のオーバーエンジニアリング。

VIPERは、元ジャビストがiOSの世界に侵入したときに起こることです。 -n0damage、 redditに関するコメント

正直なところ、誰かがこれを見て、「はい、これらの追加のクラスとプロトコルは本当に私のアプリケーションで何が起こっているかについての私の理解を向上させます」と言うことができます。

簡単なタスクを想像してください。サーバーから更新を開始するボタンがあり、サーバーから受信したデータを表示するビューがあります。 この変更の影響を受けるクラス/プロトコルの数を推測しますか？ はい、少なくとも3つのクラスと4つのプロトコルは、このような単純な機能を実装するために変更されます。 Springがいくつかの抽象化で始まり、 AbstractSingletonProxyFactoryBean



で終わった方法を覚えていますか？ 私はいつも、コード内に「 シングルトーンのみを作成するプロキシファクトリ用の便利なプロキシファクトリスーパークラス 」を夢見ていました。

冗長コンポーネント

（冗長コードは、私が考えていたほど無害ではありません。その必要性について誤ったシグナルを与えます。）

前述のように、プレゼンターは通常、ビューからインタラクター（ このようなもの ）に呼び出しを渡すだけの非常に愚かなクラスです。 はい、時には複雑なロジックが含まれることがありますが、基本的には単なる冗長コンポーネントです。

「DIに優しい」プロトコルの数

（いコードは認識しやすく、コストも簡単に見積もることができます。抽象化が正しくない場合はそうではありません。）

この略語には一般的な混乱があります。VIPERはSOLID原則を実装しています。DIは「 注入 」ではなく「依存性反転 」です。 依存性注入は、「制御の反転」パターンの特殊なケースであり、もちろん接続されていますが、依存性の反転とは異なります。

依存性反転とは、異なるレベルのモジュールを抽象化することにより、それらを分離することです。 たとえば、UIモジュールはネットワークモジュールに直接依存しないようにしてください。 制御の反転は別です。 これは、モジュール（通常は変更できないライブラリから）が何かを別のモジュールに委任するときです。通常は、最初のモジュールに依存関係として提供されます。 はい、 UITableView



データソースを実装するときは、IoC原則を使用します。 さまざまな高レベルのものに同様の名前を使用すると、混乱の原因になります。

VIPERに戻る。 同じモジュール内のクラス間には多くのプロトコル（少なくとも5つ）があります。 そして、それらのすべてが必要というわけではありません。 プレゼンターとインタラクターは、異なるレイヤーのモジュールではありません。 IoCの原則を適用することは理にかなっているかもしれませんが、自問してください。1つのビューに対して少なくとも2人のプレゼンターを獲得する頻度はどれくらいですか？ あなたのほとんどが「決して」と答えないだろうと確信しています。 それでは、なぜ私たちが決して使用しないこの一連のプロトコルを作成する必要があるのでしょうか？

さらに、これらのプロトコルのため、IDEでコードを簡単にナビゲートすることはできません。 結局のところ、 cmd+click



は、それを実装するのではなく、プロトコルに投げ込みます。

パフォーマンスの問題

これは重要なポイントですが、多くは単純にそれについて心配しないか、単に貧弱なアーキテクチャの影響を過小評価しています。

Typhoonフレームワーク（objective-cの世界では依存性注入で非常に人気があります）については説明しません。 もちろん、特に自動展開を使用する場合は、パフォーマンスにある程度の影響がありますが、VIPERはその使用を必要としません。 代わりに、ランタイムとアプリケーションの起動、およびVIPERが文字通りどこでもアプリケーションを遅くする方法について説明します。

アプリケーションの起動時間。 このトピックについてはほとんど説明しませんが、重要です。 結局、アプリケーションの起動が非常に遅い場合、ユーザーはそれを使用しません。 前回のWWDCで、彼らはアプリケーションの起動時間の最適化について話していました 。 アプリケーションの開始時間は、その中のクラスの数に依存します。 100個のクラスがある場合-これは正常な状態であり、遅延はごくわずかです。 ただし、アプリケーションに100のクラスしかない場合、この複雑なアーキテクチャが本当に必要ですか？ しかし、たとえばFacebookアプリケーション（ 18Kクラス ）で作業している場合など、アプリケーションが巨大な場合、違いは顕著になります：約1秒。 はい、アプリケーションのコールドスタートは、すべてのクラスメタデータをロードするのに1秒しかかかりません。

ランタイムの課題。 ここではすべてがより複雑で、主にSwiftコンパイラーにのみ適用されます（Objective-Cランタイムにはより多くの機能があり、コンパイラーは最適化を安全に実行できないため）。 メソッドを呼び出したときに「内部で」何が起こるかについて話しましょう（2番目はSwiftにとって常に正しいとは限らないため、「メッセージを送信する」ではなく「呼び出す」と言います）。 Swiftには3つのタイプの呼び出し（高速から低速へ）があります：静的、呼び出しテーブル、およびメッセージの送信。 後者はObjective-Cで使用される唯一のものであり、Objective-Cコードとの互換性が必要な場合、またはメソッドがdynamic



と宣言されている場合にSwiftで使用されます。 もちろん、ランタイムのこの部分は高度に最適化され、すべてのプラットフォームのアセンブラーで記述されます。 しかし、コンパイル時に正確に何が呼び出されるかをコンパイラーに知らせることにより、このオーバーヘッドを回避できるとしたらどうでしょうか？ これはまさに、Swiftコンパイラーが静的テーブルと呼び出しテーブルで行うことです。 静的呼び出しは高速ですが、コンパイラは100％型保証なしではそれらを使用できません。 そして、変数の型がプロトコルの場合、コンパイラはテーブル呼び出しを使用することを強制されます。 これは遅すぎることはありませんが、1ミリ秒があり、1ミリ秒があります。今では、クリーンなSwiftコードで達成できるものと比較して、合計実行時間が1秒以上増加しています。 この項目は、プロトコルに関する以前の項目に関連していますが、コンパイラを使用して、使用されていないプロトコルの数に関する懸念を大騒ぎから切り離した方が良いと思います。

抽象化の弱い分離

これを行うための明確な方法は1つ、できれば1つだけにする必要があります。

VIPERコミュニティで最も人気のある質問の1つ：「Xはどこに持っていくべきですか？」 一方では、物事を正しく行う方法について多くのルールがあり、他方では、多くの決定が他人の意見に基づいていることがわかります。 これらは、 NSFetchedResultsController



またはUIWebView



を使用してCoreData



を処理するなど、複雑な場合があります。 しかし、 UIAlertController



を使用するなどの一般的なケースでさえも議論の対象です。 見てみましょう。 ここでは、ルーターがアラートと対話しますが、 ここではビューを示しています。 この単純なアラートは、クローズ以外のアクションを伴わないアラートの特殊なケースであると答えることができます。

特別な場合は、規則を破るのに十分ではありません。

その通りですが、なぜここにそのようなアラートを作成する 工場があるのですか？ その結果、 UIAlertController



さえ混乱していUIAlertController



。 これ欲しい？

コード生成

可読性が重要です。

これはどのようにアーキテクチャ上の問題になりますか？ 手動で記述するのではなく、テンプレートからクラスの束を生成するだけです。 ここで問題は何ですか？ 問題は、ほとんどの場合、コードを書いているのではなくコードを読んでいるということです。 このようにして、ほとんどの時間、コードと混合した定型コードを読み取ります。 いいですか？ そうは思いません

おわりに

私の目標は、あなたをVIPERの使用を思いとどまらせることではありません。 恩恵を受けるだけのアプリケーションがあるかもしれません。 ただし、アプリケーションの開発を開始する前に、次の2つの質問を自問する必要があります。

1. このアプリのライフサイクルは長くなりますか？

   
   
   
   
   
   
   

2. 要件は十分に安定していますか？ そうしないと、小さな変更を加えた場合でも、無限のリファクタリングが発生します。

   
   
   
   
   
   
   
3. アプリを本当にテストしていますか？ 自分に正直になってください。

3つの質問すべてに「はい」と答えた場合にのみ、VIPER がアプリケーションに適しています。

そして最後に、最後：あなたはあなた自身の決定をしなければなりません。 「Use X、X is cool」と言うMedium（またはHabr）の男を盲目的に信頼するだけではありません。 この男も間違っている可能性があります。