モバイルアプリケーションのアーキテクチャ設計：パート2

システムのすべてのエネルギーを必要な方向に向けるには、このシステムをルールに制限する必要があります。


こんにちは、Habr！ モバイルアプリケーションのアーキテクチャ設計に関する一連の記事を続けます。 catの下で、UIレイヤーの設計について説明します。 ようこそ

進化するさまざまな種類の生物は、自らの生存を確保するために解決する必要がある基本的な課題に直面しました。

環境からエネルギーを吸収する必要がありますか？ -解決策：光合成。
遺伝子の多様性を確保する必要がありますか？ -決定：性別区分。
身体が複雑になればなるほど、より高度な課題を解決しなければなりませんでした。

時間が経ちました。 生存問題の優先度が著しく低下し、個体の資源が部分的に未使用である種が出現しました。
進化は新しいベクトルを取り入れました。 食物であるか、捕食者からの保護か、天候からの保護かなど、自然の問題の大部分は何らかの形で解決され、さらに発展する場所はどこにもないように見えましたが、ファンタジーがここで役割を果たしました。

さらなる進化はもはや生存を確保するという目標を追求しませんでしたが、新しいタスクのソースは意識であり、「文化」や「科学」などの開発ベクトルを生み出しました。 実際、教育と育成は、個人の生存を保証する直接的な要因ではなく、森林に住んでいる間にそれらなしで行うことは非常に可能です。

教育と育成は自然が設定した自然な目標ではなく、人間自身によって生まれたものです。

種のさらなる発展は、この種が自らのために発明した目標によって保証されています。

そして、これらの目標はそれぞれ制限事項です。

図書館では大声で話せません。 テーブルを丸atみすることはできません。 たくさんの訓練が必要です：ギターを書いて、描いて、印刷して、演奏します-なんの困難もなく、これは自分に対する暴力です。

開発するために、人は自分が発明した枠組みに身を置く。

ソフトウェアシステムを進化のピークにしたいですか？
製品を動的に成長させたいですか？
-リジッドフレームと拡張ベクトルを使用してプロジェクトを定義します。

プログラミング文化では、エンジニアは自分が望む方法で書くのではなく、ルールに準拠した方法で書くのです。

何言ってるの？

種の分離

主にモバイルアプリケーション（以下、MPと呼びます）のサービスレイヤーとトランスポートレイヤーのアーキテクチャ設計に焦点を当てた前回の記事では、UIレベルの設計の過程でどのような前提条件に従うべきかについてのヒントが与えられました。

以下は理論的な考慮事項と実際的な結論であり、おそらくあなたの作業を簡素化し、開発されたプロジェクトに一定量の構造を追加します。

NB高品質の製品でユーザーインターフェイスを構築するイデオロギーはアプリケーションプラットフォームに厳密に結び付けられており、ソリューションを選択する際にある種の「クロスプラットフォーム」を達成することは率直に言って愚かなことです。

Navigation DrawerがUITabBarと同じ機能を実行できる場合でも、それをそのまま使用して、元々異なるように設計されたシステムを同等にすることはできません。

現在の記事では、主にiOSプラットフォームに適用可能なソリューションに焦点を当てています。

ビルドUI

素晴らしいストーリーを語り続ける

前回、いわゆるユーザーストーリーになりました。これにより、プロジェクトを論理的な部分に分割して、ソースコードを簡単に維持できるようになると考えられます。

あなたのアプリケーションのデザインが狂ったオタクによって描かれたのではなく、「UX」の概念に精通し、モバイルデバイスの画面のチェーンにすべてのコントロールを便利かつ有機的にフィットさせることができる多かれ少なかれ適切なアーティストによって描かれたと仮定します。



銀行業務アプリケーションの例を使用して、インターフェースは次のような典型的なストーリーに分割されます。アプリケーションを表す複数のスライドで構成される「挨拶」。 ユーザー名、パスワード、電子メールなどのフィールドを持つ「認可」。 最後に、メイン画面は、いくつかの論理的な部分で構成されています：「ホー​​ム」（お金について）、「支払いと送金」、「ATMと支店のあるカード」など。

各ストーリーには、ユーザーが特定のアクションを実行できるいくつかの画面（または「ページ」）が含まれています。
「支払いと送金」：支払いのリストに移動します。 「モバイルコミュニケーション」セクションに移動します。 演算子を選択します。 電話番号と補充金額を入力し、お金のソースを選択してください-あなたのクレジットカード; 支払います。

サービスレベルには、UIに必要なデータを提供し、バックエンドで活用できるすべての必要なツールがあります。

エンティティへの分離には、従来のMVCではなく、MVPの変更を使用することをお勧めします。これにより、より抽象的なコントローラーを作成し、データモデルに関連付けられたコードをこのデータの直接「消費者」であるクラスに分散できます。

ユーザーストーリーごとに、3つの主要な種類のエンティティを区別できます。 これらは、 View 、 ViewController 、およびHelperです。

ViewController-インターフェースの個々の論理ユニットのコントローラーとして機能するクラス。 原則として、アプリケーションページは論理ユニットとして機能しますが、より複雑なレイアウトでは、ページ上の子コントローラーを選択してマザークラスをオフロードすると便利です。

ビューは、ストーリーボードで直接表されるクラスです：UIView、UITableViewCell、UILabel、UIButtonなどの継承。

ヘルパー -個別の職務または委任された職務を実行するユーティリティクラス。 これらには、文字列、UITableViewDataSourceおよびUITableViewDelegateプロトコルに準拠するクラスなどをフォーマットするためのユーティリティが含まれます。

詳細について話しましょう。

ViewController

競合他社から学ぶ

一般的に、iOS開発者はAndroidソフトウェアを作成する同僚から多くを学ぶ必要があります。

後者は、古典的なJavaエンジニアに固有のすべての剛性とアーキテクチャをある程度継承しているため、実際にクールなAndroidアプリケーションのアーキテクチャ設計は、クールなiOSアプリケーションのアーキテクチャ設計よりもはるかに調和しているように見えます。

Androidの同僚が最初に導入した制限は、コントローラー（アクティビティ）間で複雑なオブジェクトを転送できないことでした。このため、これらのオブジェクトのシリアル化を保証することがさらに必要です。

はい、今では誰もがすでにフラグメントを使用しており、このストーリー全体が忘却に沈んでいますが、元のメッセージは正しかったです。各コントローラーは可能な限り分離する必要があります。



コントローラ間でエンティティ全体を渡さないでください-それらの識別子を渡します。 各コントローラーがサービスレベル自体をノックし、そこからこのエンティティーの詳細情報を（その識別子を介して）受信します。これにより、命令型プログラミングに固有の最小限の副作用をアプリケーションに提供できます。

そしてもちろん、Android開発者が学ぶべき2番目の制限-SDKで「Adapter」をテーブルデリゲートとして使用します-これはプロトコルではなく、別個のクラスなので、View ControllerやUITableViewDelegate / UITableViewDataSourceなどをマージします-単に不可能。

NBクリアテキスト。 UITableViewControllerはSOLIDの原則に直接違反しているため、このクラスを発明したAppleのエンジニアは重大なミスを犯しました。

表示する

抽象化し、スタイルに分割する

上記でMVPの使用について既に説明しましたが、次にその理由を説明します。
そのため、セルにデータを入力するための2つのフラグメントがあります。

MVC：
RMREntity * entity = [self entityForIndexPath：indexPath];
cell.title = entity.name;
cell.subtitle = entity.shortDescription;

MVP：
RMREntity * entity = [self entityForIndexPath：indexPath];
[cell fillWithEntity：entity];

2番目のアプローチでは、UIの構造から抽象化して、コントローラーのすべてのロジックとヘルパーデータを処理済みのデータ型RMREntityに集中させます。

したがって、–fillWithEntity：インターフェイスの背後で、ダースのRMRTableViewCell子孫クラスを非表示にできます。各子クラスは、独自の方法でエンティティをレンダリングできます。 同時に、各UITableViewに対して同じ UITableViewDataSourceを使用するため、定型コードの記述を大幅に節約できます。

合計
まず、忘れないでください：ビューはSDKクラスからだけでなく、相互からも継承できます。

「アプリケーションのアーキテクチャ設計では、アプリケーションの種類について説明する必要があります。 図書館の設計図を見ると、それが図書館であることを正確に理解できます。読書室と本棚があります！”

アプリケーションにMessageデータ型がありますか？ その下に抽象MessageCellセルを作成し、そこから他のセルを継承します！ コードの各クラスは、その機能を決定論的に満たす必要があり、ロジックを含めることはできません。

二番目 。 UXに精通しているデザイナーについて言及したことを覚えていますか？

優れたデザイナーは、優れたプログラマーに少し似ています。
彼は、いずれかのニーズに適応できる典型的なテンプレートのセットを持っています。
優れたデザイナーは、まずカラーパレットを作成し、次にそれを一貫してプロジェクトのレンダリングに適用します。

色に加えて、優れたデザイナーは各プロジェクトの「スタイルシート」を常に持っています。

タイトル：Helvetica Bold、36pt。
字幕：Helvetica Medium、24ポイント。
金額：Helvetica Light、18ポイント、ライトブルー。
などなど。

適切な開発者として、このスタイルシートをコードに直接転送することを妨げるものはありません。

たとえば、初期化時に、フォントスタイルを返すファクトリメソッド-fontStyleを照会し、このスタイルを適用する抽象Labelクラスを作成できます。

相続人は、順番に、単に必要な執筆スタイルを返します。 したがって、HeaderLabel、SubheaderLabel、MoneyAmountLabel ...のクラスが手元にあります。 これらは、作成されたレイアウトに適用可能なInterface Builder内の「クラス」フィールドに単純に置き換えることができます。

ヘルパー

テスト設計

コントローラーがしてはならないことについてはすでに述べています。
だから誰がすべきですか？ -回答：ユーティリティ。

覚えて守るべき最も重要なことは、単純なルールです。功利主義のクラスは情報を運んではなりません。 それらはパブリックプロパティを持ってはならず、関数スタイルで記述しているように、すべてのロジックは最小限のvoidメソッドで「パススルー」する必要があります。メソッドは常に何かを返す必要があります。

ユーティリティのこの「状態の欠如」により、アプリケーションロジックの異なるレイヤーでアプリケーションレイヤーを使用することは非常に安全ですが、コントローラー、表現、ビジネスロジックなどのために個別のアシスタントを作成するのを怠らないでください。

ユーティリティクラス（またはヘプラー）は、テストエンティティの役割の最初の候補です。

日付のフォーマット、配列の並べ替え、他の画像からの画像の作成-これらはすべて、「配列、動作、アサート」のシーケンスに簡単に収まるアルゴリズムであり、自動テストに犠牲になる可能性があります。

おわりに

まとめ

この記事では、誰にも指示をしたくありませんでした。
それぞれが肩に独自の頭を持ち、それぞれが独自の結論を引き出すことができます。 または、まったく結論を出さないでください。

もちろん、プロジェクトの構造がどのように見えるべきか、ファイルやディレクトリをどこに置くべきか、リソースがどこにあるべきかといった、より詳細なことを書くこともできます。
クラスにメソッドを実装する順序、プロパティに名前を付ける方法。

しかし、私は意識的にこれをしませんでした：ソースコードが複雑である必要がないので 、材料は意図的に単純です。

一緒にいてください。