フロントエンドに共通した設計パターンを確立する

この記事はフロントエンドを設計する際に共通したアーキテクチャ設計を作成することを目的としています。

アーキテクチャの構成

以下の5つの層にレイヤーを分割
Controller層
Interaction層
Model層
View層
Infra層

Controller層の役割

View層のアクションを管理するためのクラス。アクションとは、画面へ表示するデータを取得し、表示するための機能。
アクション内のロジックは、Interaction層のメソッドの呼び出し、メソッドの返却値の取得などを行う、
アクションはURLによって動作が変更される。よって、アクションのクラスはアクションの種類ごとに生成される必要があるが、クラス内のロジックはURLごとに分岐されなければならない。

Interaction層の役割

Model層とController層の調整を行う層。画面で実現したい要求を記載するロジックのため、機能単位でクラスを作成する。
基本的なプログラムの流れは以下の通りとなる
バックエンドAPIのデータが必要な場合
・バックエンドAPIとの通信
・ Model層のクラスのインスタンス生成
・返却された通信結果をModel層のクラスに設定
・Controller層へ結果を返却

バックエンドAPIのデータが必要でない場合
・Model層のメソッドを実行
・Controller層へ結果を返却

Model層の役割

画面へ表示するオブジェクトの値を格納するクラス。
オブジェクトをベースとして画面設計などが行われるため、フロントエンド側で優先的に設計、開発を行うクラス。
オブジェクトはリスト型を基本するため、リストデータのフィルタリング、リスト内データの該当データの取得、getterメソッド提供などをメインの機能とする。

View層の役割

画面へ表示するModel層のオブジェクトを組み合わせて、画面を作成する。
画面はPC、スマートフォンごとに表示される内容が異なるため、テンプレートはPC用、スマートフォン用と別々に分けて作成する。
アクセスするデバイス、ブラウザの種類はInteraction層で判断し、判断結果に応じたレイアウトを出力する。

Infra層の役割

ライブラリを使用した機能を提供する。主にバックエンドのAPIとの通信を実施する。
チャット機能や地図の表示機能などはライブラリを通して、Infra層へ実装する。

インターフェースを使用して多様性(ポリモーフィズム)を実現
バックエンドが複雑なプログラミングをメインに担当しているが、フロントエンドはデータ表示というシンプルなプログラムを担当している。
アルゴリズムがシンプルかつデータ構造と密接に繋がりを持っているプログラムは、インターフェースを使用して多様性を実現する手法が非常に有効である。
データの表示のアルゴリズムは、処理内容がシンプルなので以下のように抽象化することができる
1.フロントエンド側のAPIと通信を行うかチェック
2.フロントエンド側のAPIと通信
3.フロントエンド側のAPIの戻り値をデータモデルに設定
4.データモデルに設定された値を使用して、画面に表示するデータ構造の文字列を作成
プログラムのメインロジックを抽象化したインターフェースメソッドのみで作成し、インターフェースを実装したクラスにメソッドの実ロジックを記載する。
メインロジックをインターフェースで記述することでポリモーフィズムを実現し、記述するプログラムソースの量を大幅に削減することができる。
運用術の構造にて、詳しい内部構造について記載する。

各レイヤーの詳細

View層

画面を以下のパーツ・コンポーネント単位で定義していく。
Material
Monitor
Function
Template

1.Material

View層の最小単位。画面に表示する画像、背景、BGMなどクリエイティブな作業工程が必要なデータを配置。

2.Monitor

Material、UI、ラベル、などを組み合わせて、画面に表示する内容を決定する。
Model層から取得したデータはすべてここに設定する。
Monitorには以下の2種類のデータが存在
静的なデータ・・・ナビゲーション、サイトマップなどリンクが固定されているデータ
動的なデータ・・・Model層から取得したデータ

3.Function

ユーザーの目的を達成するために設計されたデザイン。Templateのエリア内に表示する。
Monitorの組み合わせで構成されている。
<例>
ナビゲーション、サイトマップ、広告

4.Template

最終的に画面に表示されるレイアウト。画面のエリアの設定とエリア内に表示するFunctionによって構成されている。Templateは神秘的なシンボルによって、レイアウトの配置が決定される。
<例>Holy Grail Layout

Controller層

以下のパッケージ単位で定義していく。
Action
Converter

1.Action

画面のUIから呼び出されるメソッドのメインロジックを記載する。
OOUIの設計思想に沿って、従来の画面単位ではなく、UIとUI内に所属するアクションの種類ごとにクラスを作成していく。
<例>
クラス名：タッチパネル
メソッド：スクロール検知
以下の順番でロジックを記載する。
1.UIのアクションを検知
2.呼び出し画面のチェック
3.Converterクラスメソッドを呼び出す
4.Converterクラスメソッドの戻り値で画面のView層のデータ構造を書き換える

2.Converter

画面のUIの引数情報をInteraction層に渡すためのクラス。
Interaction層のロジックはインターフェースを使用して記述するため、
インターフェースクラスに画面のUIの引数情報を渡す。
以下の順番でロジックを記載する。
1.インターフェースのインスタンス生成
2.インスタンス生成時に画面のUIの引数情報を渡す
3.Interaction層のメソッドにインターフェースを引き渡す
4.Interaction層のメソッドの実行結果を戻り値として返却

Interaction層

以下のパッケージ単位で定義していく。
MetaInterface
Interaction

1.MetaInterface

インターフェースを定義するためのクラス。
インターフェースでロジックを記述する際に、フロントエンドのメインロジックのカテゴライズ化とインターフェースで実行するメソッドを決定する必要がある。
フロントエンドのメインロジックを以下のような種類に分類する。
<例>
Search・・・検索処理を実施するインターフェース。
Insert・・・DB登録処理を実施するインターフェース。
Delete・・・DB削除処理を実施するインターフェース。
Upadate・・・DB更新処理を実施するインターフェース。

インターフェースを以下のようなメソッドを実装する。
<例>
constructor・・・画面のUIの引数情報をModel層のフィールド変数に設定
isTranfer・・・バックエンドのApiと通信するか判定を行う
tranfer・・・バックエンドのApiと通信し、通信結果をModel層のクラスにマッピング
create・・・Model層に設定した値を使用して、View層の構造を書き換える文字列を生成する

2.Interaction

フロントエンドのメインロジックを記載するFacadeクラス。
インターフェースに実装されたメソッドを呼び出してロジックを記載する。
画面の要求を実現するためのクラスなので、ユースケース単位でクラスを記述する。

以下の順番でインターフェースロジックを呼び出す。
1.constructor
2.isTranfer
3.tranfer
4.create

Model層

以下のパッケージ単位で定義していく。
DataModel

1.DataModel

画面に表示するデータを管理するクラス。
DataModelはInteraction層のインターフェースを実装するため、画面に表示する値 + インターフェースで定義したメソッドを実装する。

Infra層
以下のパッケージ単位で定義していく。
interface
liblary

1.interface
liblaryのインターフェースを定義するためのクラス。
DI(依存性注入)の考え方でライブラリのメソッドを提供する。

2.liblary
チャット機能やビデオ通話機能などをアプリ追加する際のライブラリを管理するためのクラス