設計とは、楽しく開発し、価値のあるサービスを提供するために欠かせない技術です。
プログラマの貴重な時間が不具合修正に費やされないように、設計技術を身につけてスマートに仕事をこなしましょう。
2つの価値観を共存させる
Web系の開発では、フロントエンドとバックエンドで職種として別れる程分業が進んでいますが、アプリ開発でも同様の概念が存在します。
有名なものにはMVCがありますが、アーキテクチャと呼ばれるものがこれらの概念を分離するためのものです。多くのアーキテクチャが存在しますが、大まかな思想はどれも変わらないので、Fowlerさんが提唱したPresentation Domain Separationというシンプルな分離手法で解説します。プレゼンテーション層（UI制御）とドメイン層（それ以外）で分離します。
各開発環境でのプレゼンテーション層は、下記を基底クラスに持つクラス1が該当します。
| iOS | Android | Unity |
|---|---|---|
| UIViewController | Activity/Fragment | MonoBehaviour |
| UIView | View | - |
プレゼンテーション層が、Webのフロントエンドに当たりますね。
プレゼンテーション層を分離する2つの利点
1. 見た目を変え易くするため
デザイナーの気持ちを代弁しますが、最適なUIデザインを動作する前に考えつくことは困難です。プロトタイピングツールを使うことである程度緩和できますが、それでもリリース後にやっぱりイケてなかった・・なんて思うことは多々あります。
そして、プログラマにとってのプレゼンテーション層の設計は、開発スピードが命です。このレイヤでは複雑なクラス設計は行わず、デザイナーの意思を素早く反映するためにGUIツールも駆使しながら、極力構造化しない開発を行います。少し「福笑い」をするようなイメージが近いと思います。パーツを上に乗せるだけで簡単に変化しますね。
また、UI仕様が変わることは予め想定しておくのが開発のセオリーです。デザイン仕様が急に変わってボヤくのは、設計に問題があることが多いです。
2. 品質に直結するドメイン層を守るため
アプリのコアとなるクラス設計はドメイン層で構築します。業務系アプリではビジネスロジックを書くレイヤですし、ゲーム開発でも見た目に直結しないコアな仕様はこちらのレイヤに分離するのが良い選択です。
ドメイン層はプレゼンテーション層と異なり、ライフサイクルを持たないプレーンな型を使って設計します。ライフサイクルを持つクラスは、ランタイム時にしか動作しないので、ユニットテストができないからです。
ソフトウェアの世界で品質を維持するための主な手段は、ユニットテストを書くことです。これは10年以上変わらない、設計をする上で重要な観点です。
良い設計はテスト可能であり、テスト可能でない設計は悪い設計である、ということは常に真実です。2
設計の学習方法
設計の重要性は手を動かしてみないとなかなか理解し難いものです。
そして、設計の大部分はテストが主導しているという事実があります。私はテスト駆動開発（TDD）3にチャレンジしてみることをお薦めします。テストを行う難しさが自然とアーキテクチャの理解に繋がります。
参考プロジェクト
- iOS: GitHub/housebalance-ios
MVVMアーキテクチャを採用し、テスト可能なプレゼンテーション層(Presentation/ViewModels参照)を実現している。