Swift 4の小さなiOSアプリケーションの例に関するVIPERアーキテクチャの分析

「誰もが自分のVIPERを持っています。」 不明な著者

この記事では、VIPERアーキテクチャーを小さな具体例で検討したいと思います。これは同時に、このアーキテクチャーの全能力を示し、最新のSwift 4で書かれています。 記事全体を読まずにすぐにコードを見たい人のために、ラップへのリンクは一番下にあります。

目次

• エントリー
• 第0章。VIPERアーキテクチャスキーム
• 第1章非常に単純なモジュールの例
• 第2章より複雑なモジュールの例
• おわりに
• リポジトリリンク

エントリー

Habre（ 1、2 ）など、 VIPERのアーキテクチャについてはかなり多くのことが書かれています。 したがって、私は他の人に追いつき、別の「有用な」ガイドを書くことにしました。 この記事で詳しく説明されているように、すべてはApple MVCアーキテクチャがあまり成功していないという事実から始まりました。 要するに、 MVCはMassive View Controllerになりました。 巨大なView Controllerで、彼はたくさん許可されていました。 多くのUIとビジネスロジックが含まれていたため、そのようなコードはテスト、デバッグ、および保守がほとんど不可能でした。

したがって、開発者は、 SOLIDの原則（特に「 唯一の責任の原則 」）と整合性のある、柔軟性の高い異なるアーキテクチャと、 クリーンなアーキテクチャ （ ロシア語のレビュー ）が必要でした。

ランブラーはこのトピックを取り上げ、 会議全体をそれに捧げ、さらには本を書きました。 ところで、VIPERに慣れていない場合は、この本をアーキテクチャの紹介として読むことをお勧めします。 このVIPERが何のために必要なのか、どのように表示されたのかをよく説明し、噛んでいます。 この本は、古典的なVIPERの問題、およびRamblerの開発者がその中で少し変更したことについても説明しています。 残念ながら、この本は2016年に書かれており、その例はObjective-Cとそのオープンソースプロジェクトに関するものです。 このプロジェクトは、多くの追加事項、過剰な抽象化、および多すぎるクラスでハングしています。 一見、複雑すぎて反発的に見えるかもしれません。

したがって、VIPERアーキテクチャで小さなアプリケーション「 通貨コンバーター 」を作成し、各レイヤーで記述する必要があるものと、各レイヤーに設定されているルールを示しました。 私はいわゆるいわゆるを使用しなかったとすぐに言われるべきです ランブラーの経験とその例に触発された、古典的なVIPERとそのわずかに変更されたバージョン。

Swiftでもっとエレガントに何かを書けるかどうかは、文句を言わないでください。 それでも、この記事は建築に関するものであり、 Swift自体の美しさに関するものではありません。 また、意図的にサードパーティのライブラリと依存関係を使用しませんでした。 全体の例は、ネイティブiOSライブラリのみを使用して記述されています。

第0章。VIPERアーキテクチャスキーム

VIPERの原則に基づいてクイックランを実行します。 1つの画面または正確には1つのView Controllerは、VIPERの1つのモジュールに対応する必要があります。 一般に、VIPERは、長い間苦労しているView Controllerを多くのレイヤーに分割するように設計されており、すべてのユーザーがそれぞれの役割を果たします。 概略的に、モジュール内の接続を下図に示します。



おそらく他のスキームを見たことがあるでしょう。


略語VIPERからの各文字は何かを意味します：閲覧者–紹介者–受入者–実体– Rアウター。 しかし現実には、これらのコンポーネントだけがモジュールに含まれているわけではなく、エンティティは一般にモジュールの概念に含まれていない可能性があります。 は、任意のモジュールまたはサービスで使用できる自己完結型のクラスです。 複雑な画面では、モジュールをサブモジュールに分割することができ、各サブモジュールには独自のプレゼンターとインタラクターがあります。

従来のVIPERとは異なり、鉱山には2つの役割を実行したため、 Wireframeがありません。モジュールを組み立て、別の画面（モジュール）に切り替えました。 この図は、 Configuratorがモジュールの構築を担当し、 Routerが移行を担当することを示しています。 Ramblerからこのロジックを採用しましたが、唯一の違いはConfiguratorの代わりにAssemblyがあることです。 しかし、本質は同じです。

Configuratorは、モジュール内のすべての依存関係を認識しています。 ViewControllerにはPresenterがあり、 PresenterにはInteractorなどがあることを示しています。 例の後半でさらに詳しく検討します。

また、古典的なVIPERでは、 セグエは放棄されたため、ストーリーボードを使用して画面を切り替えることはできません。 私たちのケースでは、Ramblerと同様に、 セグエを介した移行が機能し、Appleが望んでいたように、使用が推奨されます。

たまたま、100％パッシブビューをView Controllerから作成できません。 Apple自体は、ライフサイクルとメソッド（ viewDidLoad 、 viewDidAppearなど）で特定の役割を果たしているため、これを考慮し、これに基づいてアーキテクチャを構築する必要があります。 モジュールアセンブリは、View Controllerが既に初期化されているだけでなく、すでにロードされているときにviewDidLoadから起動されます。 また、クラシックバージョンで行われていたAppDelegateではなく、ストーリーボードから初期ビューコントローラーを設定する機会を提供します。 これは、特定のエントリポイントへの厳密なバインドがなく、簡単に変更できるため、はるかに便利です。

モジュールを組み立てた後、モジュールのさらなる動作は非常に古典的です。 View / ViewControllerは 、ボタンのクリック、テキスト入力、またはUIとのその他の対話のロジックについて責任を負いません。 これらはすべて、すぐにPresenterに転送されます。 ビューは、モジュールの一部として、または共通のビューとして、さまざまなモジュールで使用できます。

プレゼンターは、アクションのリダイレクト先をルーターまたはインターアクターに決定します。 ルーターは現在の画面を閉じるか、新しい画面を開きます。 遷移の特定の実装は、その中で実行されます。 インタラクターは、受信したイベントをどのように処理し、どのサービスを呼び出すかを決定します。 モジュールのロジックが含まれています。

しかし、 Presenterのより重要な機能は、ユーザーに表示されるView / ViewControllerの視覚データの準備と送信です。 プレゼンターはモジュールの中心であり、どのデータがどのような形式で表示されるかを知っています。 異なるスキームであっても、彼は常に真ん中にいます。 （そしておそらくInteractor 、脳による）

Interactorは、他のサービスのファサードです。 インタラクターには、ロジック自体を含めることもできます。 MVCでは 、コントローラーと比較できますが、コントローラーはデータの表示方法について何も知りません。

私たちの解釈におけるサービスとは、アプリケーションのさまざまなモジュールや部分（認証ロジック、データベースの操作、サーバーの操作、暗号化など）からアクセスできるさまざまなヘルパーやその他のクラスを指します。 サービスは相互に、またEntityと対話できます。 エンティティは、単なる受動的なエンティティ（ユーザー、書籍、単語）です。 前述のように、 エンティティは VIPERモジュールのコンポーネントではありません。 一般に、アーキテクチャは元々 VIPと呼ばれていました。

何も理解していない場合は問題ではありません。 さらにこの例では、すべてが明らかになりますが、それは表面的な説明にすぎません。

第1章非常に単純なモジュールの例

奇妙なことに、最初のより複雑な画面からではなく、非常に単純な「アプリケーションについて」画面からアーキテクチャを検討し始めます。 画面自体には、いくつかのラベル、 「閉じる」ボタン、およびサイトへのリンクのあるボタンがあります。 [ 閉じる ]をクリックすると、現在の画面が閉じて前のメイン画面が表示され、リンクをクリックするとSafariで開きます。 ラベルは受動的であり、変更されません。

アプリケーションのこのような画面には、一部の人が考えるようにViewControllerにすべてを配置できるため、VIPERのすべての能力と必要性が表示されません。 しかし、純粋なアーキテクチャのイデオロギーはこの原則に反するため、最も単純な画面や最も単純なアプリケーションでさえ、VIPERアーキテクチャ上で作成することができます。 常にルールを順守する必要があります。

クラスのモジュール内ではこの名前に追加の単語が追加されるため、モジュール名は短く選択することをお勧めします。 たとえば、 「About Application」モジュールはAboutと呼ばれます。 View ControllerはAboutViewControllerと呼ばれます 。 残りのクラスはAboutPresenter 、 AboutInteractor 、 AboutConfiguratorなどです。

モジュールの初期化がView Controllerから始まる場合、モジュールはそれから開始する必要があると考えてください。 AboutViewControllerクラスとAboutConfiguratorクラスを作成します。 AboutConfiguratorクラスは、 AboutConfiguratorProtocolプロトコルに準拠する必要があり、メソッドは1つだけです。

protocol AboutConfiguratorProtocol: class { func configure(with viewController: AboutViewController) } class AboutConfigurator: AboutConfiguratorProtocol { func configure(with viewController: AboutViewController) { } } 

将来、このメソッド内で、モジュールを構成します。 AboutViewControllerには、 viewDidLoadで設定されるコンフィギュレータープロパティと、 AboutPresenterProtocolプロトコルに準拠するプレゼンタープロパティがあります。

重要なルール！ すべてのコンポーネントは、直接ではなくプロトコルを介してのみ相互に通信します！ これは、将来単体テストを記述し、コード全体をクリーンに保つために必要です。

AboutPresenterProtocolにはconfigureView（）メソッドが含まれている必要があります 。このメソッドは、View Controllerの視覚要素の初期データを初期化および構成します。 この時点で、 AboutViewControllerは次のようになります。

 class AboutViewController: UIViewController { var presenter: AboutPresenterProtocol! let configurator: AboutConfiguratorProtocol = AboutConfigurator() override func viewDidLoad() { super.viewDidLoad() configurator.configure(with: self) presenter.configureView() } } 

プレゼンターには、 「閉じる」ボタンとサイトへのリンクのあるボタンをクリックしたときに呼び出されるルーターとメソッドもあります 。 AboutPresenterProtocolは次のようになります。

 protocol AboutPresenterProtocol: class { var router: AboutRouterProtocol! { set get } func configureView() func closeButtonClicked() func urlButtonClicked(with urlString: String?) } 

このモジュールは非常にシンプルであるため、View Controllerの全体の構成は、 URLを持つボタンの署名がビジュアルエディターからではなくコードから設定されることです。 AboutViewControllerの場合、このようなプロトコル：

 protocol AboutViewProtocol: class { func setUrlButtonTitle(with title: String) } 

AboutPresenter内で、メソッドを実装します。

 func configureView() { view.setUrlButtonTitle(with: interactor.urlRatesSource) } 

ターンが始まり、インタラクターが現れました。 ロジックとデータの保存/取得は、常にそこに転送する必要があります。 この場合、インタラクターには、サイトのURLを保存するプロパティと、このURLを開くメソッドがあります 。

 protocol AboutInteractorProtocol: class { var urlRatesSource: String { get } func openUrl(with urlString: String) } 

しかし、 閉じるボタンをクリックするイベントの処理についてはどうでしょうか？ ここで、プレゼンターは、このイベントが画面間の遷移に関連付けられていると判断し、処理がルーターに送信されます。 このモジュールでは、ルーターは現在のView Controllerのみを閉じることができます。

彼のプロトコル：

 protocol AboutRouterProtocol: class { func closeCurrentViewController() } 

プレゼンタープロトコルは次のようになります。

 protocol AboutPresenterProtocol: class { var router: AboutRouterProtocol! { set get } func configureView() func closeButtonClicked() func urlButtonClicked(with urlString: String?) } 

VIPERモジュールのコンポーネントについて説明したプロトコルがすべて揃ったので、これらのメソッドの実装に移りましょう。 View ControllerがAboutViewProtocolプロトコルに準拠していることを忘れずに追加してください。 ストーリーボードのボタンをView Controllerのプロパティに関連付け、クリックするイベントを割り当てる方法については説明しないため、View Controllerのメソッドをすぐに記述します。

 @IBOutlet weak var urlButton: UIButton! @IBAction func closeButtonClicked(_ sender: UIBarButtonItem) { presenter.closeButtonClicked() } @IBAction func urlButtonClicked(_ sender: UIButton) { presenter.urlButtonClicked(with: sender.currentTitle) } func setUrlButtonTitle(with title: String) { urlButton.setTitle(title, for: .normal) } 

View Controllerはボタンをクリックした後に何をすべきかわかりませんが、 setUrlButtonTitle（with title：String）メソッドが呼び出されたときに何をすべきかを正確に知っています。 View Controllerは、プレゼンターがこのメソッドを呼び出したデータに基づいて、 UI要素の更新、移動、再描画 、非表示のみを行います。 同時に、プレゼンターは、このデータがView / ViewControllerにどのように配置されているかを正確に知りません。

完全なプレゼンタークラスは次のようになります。

 class AboutPresenter: AboutPresenterProtocol { weak var view: AboutViewProtocol! var interactor: AboutInteractorProtocol! var router: AboutRouterProtocol! required init(view: AboutViewProtocol) { self.view = view } // MARK: - AboutPresenterProtocol methods func configureView() { view.setUrlButtonTitle(with: interactor.urlRatesSource) } func closeButtonClicked() { router.closeCurrentViewController() } func urlButtonClicked(with urlString: String?) { if let url = urlString { interactor.openUrl(with: url) } } } 

コンフィギュレーターを完全に忘れていました。 結局のところ、彼なしでは何も機能しません。 彼のコードは：

 class AboutConfigurator: AboutConfiguratorProtocol { func configure(with viewController: AboutViewController) { let presenter = AboutPresenter(view: viewController) let interactor = AboutInteractor(presenter: presenter) let router = AboutRouter(viewController: viewController) viewController.presenter = presenter presenter.interactor = interactor presenter.router = router } } 

参照サイクルを取得しないために、View Controllerのプレゼンターは強いと示され、PresenterのView Controllerは弱いと示され、プレゼンターとのインタラクターは弱いと示されます。 このチェーン全体で、 ViewControllerが最も重要です。 したがって、ここではパッシブビューについて話すことは不適切です。 ViewControllerを閉じると、他のすべての要素も破棄されます。これは、 ViewControllerへの強力なリンクを誰も持つことができないためです 。 そうしないと、 メモリリークが発生します。

インタラクタークラスは次のようになります。

 class AboutInteractor: AboutInteractorProtocol { weak var presenter: AboutPresenterProtocol! let serverService: ServerServiceProtocol = ServerService() required init(presenter: AboutPresenterProtocol) { self.presenter = presenter } var urlRatesSource: String { get { return serverService.urlRatesSource } } func openUrl(with urlString: String) { serverService.openUrl(with: urlString) } } 

コードは非常に単純なので、コメントは冗長です。 ServerServiceに注意する価値があります。 これは、View Controller上のボタンのURLを提供し、Safari（または他の何か）でリンクを開くサービスです。 ServerServiceとそのプロトコルのコードは次のようになります。

 protocol ServerServiceProtocol: class { var urlRatesSource: String { get } func openUrl(with urlString: String) } class ServerService: ServerServiceProtocol { var urlRatesSource: String { return "https://free.currencyconverterapi.com" } func openUrl(with urlString: String) { if let url = URL(string: urlString) { UIApplication.shared.open(url, options: [:]) } } } 

ここのすべても簡単です。 ルーターのみが残ります。

 class AboutRouter: AboutRouterProtocol { weak var viewController: AboutViewController! init(viewController: AboutViewController) { self.viewController = viewController } func closeCurrentViewController() { viewController.dismiss(animated: true, completion: nil) } } 

繰り返しますが、すべてのソースコードはリポジトリにあります。 記事の最後にリンクします。

第2章より複雑なモジュールの例

今度は、アーキテクチャをより複雑な例で見て、各レイヤーのルールを要約します。



すべての画面を備えたストーリーボードは次のようになります。 メイン画面では、変換する通貨と変換する通貨を選択できます。 別の通貨に変換する金額を入力することもできます。 別の通貨に換算された金額は、入力フィールドの下に表示されます。 そして一番下には、変換率と「 アプリケーションについて 」画面に切り替えるためのボタンがあります。

すべての通貨とその為替レートのデータは、無料サイトhttps://free.currencyconverterapi.comからリクエストされます 。 例の単純化のために、 データをUserDefaultsに保存しますが、 Core Dataまたは他の方法で保存するために1つのクラスのみを簡単に変更できます。

VIPERモジュールフレームの外観がわかったので、メイン画面でも同じことが簡単に行えます。 メインモジュール（メイン画面）のファイルが右側に表示されます。 アーキテクチャの小さな不便さは、モジュールごとに多くのファイルを作成する必要があり、手動で多くの時間がかかることです。 そのため、RamblerがGenerambaコードジェネレーターを考案しました。 掘り下げると、自分用にカスタマイズできます。 または、 Xcodeのテンプレートを使用できます。ネット上には多くの例があります。 たとえば、 https://github.com/Juanpe/Swift-VIPER-Moduleまたはhttps://github.com/infinum/iOS-VIPER-Xcode-Templates 。 これらのトピックは、次のように詳細に検討されることはありません。 これは記事の範囲外です。

プロトコルのために、各モジュールに個別のファイルを作成したことは驚くべきことです。 このアプローチが気に入らない場合は、クラス自体のファイルにプロトコルを直接記述できます。 個人的には、すべてのモジュールプロトコルが1か所に集められている方が便利です。 好みの問題。

伝統的に、View Controllerからのモジュールも検討し始めます。 View / ViewControllerの重要なルールは、 Entityがそれらに直接渡されないことです。 このためには、追加のレイヤー/サービスを作成する必要があります。

viewDidLoadメソッドは、 Aboutモジュールの実装と同じです。 モジュール構成が呼び出され、 View （この場合はViewController ）を構成するためのコマンドがインタラクターに与えられます。

モジュールの構成は、 Aboutモジュールとほぼ同じです。 ただし、メイン画面では、 CurrencyPickerViewの追加のViewコンポーネントが必要です。これは、別個のクラスとして作成され、他の場所またはアプリケーションでさえ再利用できます。 ストーリーボードのメイン画面に、通常のUIViewが追加され 、 CurrencyPickerViewクラスが設定されます。

すべてのCurrencyPickerViewコードは考慮されません。 IBOutletは彼のView Controllerにありますが、彼のロジックはプレゼンターで処理されます。 したがって、それへのリンクがコンフィギュレーターに登録されます。 CurrencyPickerViewにはデリゲートもあり、View Controllerではなくプレゼンターになります。 コンフィギュレーターで、次の呼び出しを追加します。

 class MainConfigurator: MainConfiguratorProtocol { func configure(with viewController: MainViewController) { ... presenter.currencyPickerView = viewController.currencyPickerView viewController.currencyPickerView.delegate = presenter } } 

より複雑な例を使用すると、View Controllerがアンロードされ、ロジックがプレゼンターからインタラクターに、さらにサービスに転送されることが明らかになります。 このモジュールでのViewの構成はより複雑で、アプリケーションを閉じる前に最後に使用された保存値の設定が含まれます。 コードは次のとおりです。

 func configureView() { view?.setInputValue(with: inputValue) view?.setOutputValue(with: outputValue) view?.setInputCurrencyShortName(with: inputCurrencyShortName) view?.setOutputCurrencyShortName(with: outputCurrencyShortName) view?.addDoneOnInputCurrencyKeyboard() updateRateText() interactor.getAllCurrencies() } 

UIコンポーネントの初期値の設定に加えて、すべての通貨のリストの要求がインタラクターに送信されます。 プレゼンターは、このデータの受信元を知りませんが、必要なことは知っています。 また、値inputValue 、 outputValue 、 inputCurrencyShortNameおよびoutputCurrencyShortNameがインタラクターから要求されます。 この保存されたデータの入手先を知っているのは彼だけです：

 var inputValue: String? { set { if let value = newValue { interactor.inputValue = Double(value) ?? 0.0 } } get { var input = String(interactor.inputValue) if input.hasSuffix(".0") { input.removeLast(2) } return input } } var outputValue: String? { get { let formatter = NumberFormatter() formatter.numberStyle = .decimal formatter.maximumFractionDigits = 2 formatter.roundingMode = .down formatter.usesGroupingSeparator = false let number = NSNumber(value: interactor.outputValue) var output = formatter.string(from: number)! if output.hasSuffix(".00") { output.removeLast(2) } return output } } var inputCurrencyShortName: String { get { return interactor.inputCurrencyShortName } } var outputCurrencyShortName: String { get { return interactor.outputCurrencyShortName } } 

VIPERに関するコメントの中で、プレゼンターは特別なことは何もせず、View Controllerからインタラクターへ、またはその逆にデータを単純に転送するという意見に出会いました。 上記のコードから、プレゼンターはインタラクターにデータを要求して「そのまま」提供するだけでなく、データを必要な形式で準備およびフォーマットすることが明らかになります。 プレゼンターは、View Controllerに転送されるデータの種類と形式について責任を負います。 View Controllerはフォーマットを気にする必要がなくなり、必要なUIコンポーネントにのみ割り当てます。

プレゼンターはUIKitについて何も知らず、 UIButton 、 UILabelおよびその他のビジュアルコンポーネントについても知りません。 これは非常に重要です。 UIKitのすべての動作は、View Controllerおよび他のViewコンポーネントで発生します。 また、ボタンが押されたとき、 UIButtonパラメーターを渡すことはできません;プレゼンターはこれを知らないはずです。 したがって、ボタンを押して入力フィールドにテキストを入力すると、View Controllerで次のように処理されます。

 @IBAction func inputCurrencyButtonClicked(_ sender: UIButton) { presenter.inputCurrencyButtonClicked() } @IBAction func outputCurrencyButtonClicked(_ sender: UIButton) { presenter.outputCurrencyButtonClicked() } func textFieldDidBeginEditing(_ textField: UITextField) { presenter.textFieldDidBeginEditing() } func textField(_ textField: UITextField, shouldChangeCharactersIn range: NSRange, replacementString string: String) -> Bool { if textField == inputTextField { if textField.availableAdding(string: string) { textField.addString(string) self.presenter.inputValueChanged(to: textField.text ?? "") } return false } return true } func textFieldShouldClear(_ textField: UITextField) -> Bool { if textField == inputTextField { textField.clear() self.presenter.inputValueCleared() return false } return true } 

カスタムUI要素を記述するか、完成した要素に拡張機能を追加する必要があるとしましょう。 たとえば、メインモジュールのUITextFieldを考えます。 コンポーネントには、それだけに関する独自の内部ロジックを含めることができます。 たとえば、通貨の入力フィールドは小数ですが、先頭に2つのゼロを入力することはできず（「00」） 、複数のポイントを入力することはできません（「0.11.2」） 、カンマはポイントに変換され、数字のみを入力できます。キーボードなど この場合、このロジックを要素自体に入れることができます。 結局のところ、このロジックはアプリケーションの他のコンポーネントのロジックには影響せず、適用されるだけです。 たとえば、次のように：

 extension UITextField { func availableAdding(string: String) -> Bool { switch string { case "": return self.text != "" case "0"..."9": return self.text != "0" case ".", ",": return self.text!.count > 0 && self.text!.range(of: ".") == nil && self.text!.range(of: ",") == nil default: return false } } func addString(_ string: String) { var newValue: String = self.text ?? "" var addingString = string if addingString == "", newValue.count > 0 { newValue.removeLast() } else if addingString != "" { if addingString == "," { addingString = "." } newValue.append(addingString) } self.text = newValue } func clear() { self.text = "" } func addDoneOnKeyboard() { let keyboardToolbar = UIToolbar() keyboardToolbar.sizeToFit() let flexBarButton = UIBarButtonItem(barButtonSystemItem: .flexibleSpace, target: nil, action: nil) let doneBarButton = UIBarButtonItem(barButtonSystemItem: .done, target: self, action: #selector(dismissKeyboard)) keyboardToolbar.items = [flexBarButton, doneBarButton] self.inputAccessoryView = keyboardToolbar } @objc func dismissKeyboard() { self.resignFirstResponder() } } 

別のことは、そのようなロジックが外部データ、たとえば登録中のユーザーのログインの可用性に影響を与える可能性がある場合です。 サーバーまたはデータベースへの要求があります。 または、パスワードのリプレイ。これは別のコンポーネントにすでに影響するためです。 一般に、UIコンポーネントにのみ適用されるロジックをUIコンポーネントに追加できます。 いくつかのためにそれは議論の余地があるように見えるかもしれませんが。

サーバーから通貨のデータを受信する方法を検討してください。 プレゼンターでは、 getAllCurrencies（）メソッドの呼び出しが発生しました。 次に何をすべきか、発表者は知りません。 インタラクターにはさらにロジックが書き込まれ、必要に応じて、必要なコマンドがプレゼンターに送信されます。 実装は次のとおりです。

 func getAllCurrencies() { presenter.showHUD() serverService.getAllCurrencies { (dict, error) in if let error = error { self.presenter.hideHUD() self.presenter.showLoadCurrenciesButton() self.presenter.showAlertView(with: error.localizedDescription) return } if let dictResponse = dict { self.currencyService.saveAllCurrencies(with: dictResponse, completion: { (error) in if let error = error { self.presenter.hideHUD() self.presenter.showAlertView(with: error.localizedDesc) return } self.currencyService.sortAndUpdateCurrentCurrencies() self.getOutputCurrencyRatio(newCurrency: nil) }) } } } 

このインタラクターには既に2つのサービスが含まれています。 通貨の操作を担当するCurrencyServiceと、サーバーの操作を担当する既知のServerServiceです。 もちろん、 ServerServiceをいくつかのサービスクラスに分割して、特定のサーバーではなく、すべてのサーバーで作業する方法を再利用する方が適切です。 ただし、すべてを100万のクラスに単純化するために、ここでは1つのクラスに限定しました。これにより、VIPERモジュールのアーキテクチャが損なわれることはありません。

サービスについては、 SOLIDの原則の1つである依存性反転の原則に従って、特定のクラスに結び付けられないようにプロトコルを作成して、それらを処理することも非常に望ましいです。

CurrencyServiceは、 Currencyなどのデータ構造の操作に役立ちます。 彼は、利用可能なすべての通貨、通貨に現在入力されている値、通貨の種類を提供し、2つの通貨に対するレートを保存、ソート、受信することができます。 彼のプロトコルは次のようになります。

 protocol CurrencyServiceProtocol: class { var currencies: [Currency] { set get } var currencyNames: [String] { set get } var inputValue: Double { set get } var outputValue: Double { get } var inputCurrency: Currency { set get } var outputCurrency: Currency { set get } func saveAllCurrencies(with dict: [String: Any], completion: @escaping (CurrencyError?) -> Swift.Void) func sortAndUpdateCurrentCurrencies() func saveOutputCurrencyRatio(with dict: [String: Any], completion: @escaping (CurrencyError?) -> Swift.Void) } 

CurrencyServiceサービスは、 UserDefaultsにデータを保存する別のStorageServiceサービスにデータを要求します。 インタラクターは、データの保存方法は言うまでもなく、データが保存されていることを疑いさえしません。 CurrencyServiceヘルパーサービスはすべての作業を行い 、 インタラクターにデータを提供するだけなので、 インタラクターはStorageServiceサービスがあることすら知りません。

メインモジュールのインタラクターは、主に抽象化とサービスプロトコルメソッドの呼び出しで構成されているため、次のようなレイヤーのユニットテストを書くのは非常に簡単です。 モキとスタブを作成するのは難しくありません。 特定のクラスへのバインドはありません。

各メソッドと残りのクラスの各行を詳細に調べ続けるつもりはありません。 アーキテクチャの一般的な本質と各層の役割はすでに明確になっているはずです。 最後に言いたいのは、 セグエを介した別の画面への移行です。

Appleはこの機能をView Controller向けに設計したため、このアプローチから進む必要があり、 navigationController？.PushViewController（vc、animated：true）を通過する必要はありません。 「情報」ボタンをクリックすると、 「アプリケーションについて」画面が開きます。 したがって、プレゼンターはボタンを押すイベントをルーターに送信し、次のメソッドを呼び出します。

 func showAboutScene() { viewController.performSegue(withIdentifier: viewController.selfToAboutSegueName, sender: nil) } 

View Controllerは、システム準備（セグエ...）を呼び出し、すでにこのイベントをルーターに直接渡します。

 override func prepare(for segue: UIStoryboardSegue, sender: Any?) { presenter.router.prepare(for: segue, sender: sender) } 

この場合、発表者は終了しました。 誰かがこの違反を気に入らない場合は、メソッドをプレゼンターに渡すか、UI要素をパラメーターとして渡す必要がありますが、これも違反になります。 または、他の何かを考え出します。 私自身はまだ良い選択肢を見つけていません。 prepare（for：segue、sender：sender）のデリゲートを設定できれば、もちろんルーターになります。

おわりに

示されたアーキテクチャは理想的ではありません。 記事の冒頭で、誰もが自分のVIPERを持っていると言ったのも不思議ではありません。 何人、とても多くの意見。 複数のモジュールが同じユーザーストーリー内でグループ化され、複数のモジュールに対して1つのルーターを作成したときにオプションに出会いました。 または、別の実施形態では、いくつかのモジュールに対する1つのインタラクター。 多くは古典的なWireframeを使用しますが、他のものは何か他のものを思いつきます。 誰かがEntity View Controllerに渡します。 もちろん、後者は間違っています。

恐ろしく書かれたアプリケーションを持っている場合でも、VIPERを使用すると、すべてを徐々に書き換えることができます。 View Controller用のView Controller。 これはプレゼンテーション層であり、各モジュールは他のモジュールのアーキテクチャおよび実装に依存しません。 サービスへのロジックの移植を徐々に開始します。 View Controllerをアンロードします。 さらにコードをサポートすることで、このようなレイヤーによる分離は何回も成果を上げます。

この記事では、例えばTyphoonなど、iOS用のモジュールでの依存性注入については触れませんでした。 そして、開発を促進する追加の有用なものの多くの内部告発者 。 モジュールの一般的な動作は、抽象クラスとプロトコルに取り込まれ、それらから継承されます。 一般に、プロジェクトとコードは無期限に改善できますが、それでも完全ではありません。

あなたのVIPERが何であれ、レイヤー間の責任の明確な分割に従い、抽象化（プロトコル）を扱うことが重要です。 VIPERモジュールのテストを書くことはもう考えられませんが、そのようなコードの場合、テストを書くのははるかに簡単です。

この記事はおそらく少し面倒でボリュームがありましたが、そのために自分で理解できるようにすべてのソースコードを提供しました。建設的な批判と議論を歓迎します。何か間違ったことを書いたのかもしれません。コメントを書いてください。


リポジトリへのリンク。