読者です 読者をやめる 読者になる 読者になる

病みつきエンジニアブログ

機械学習、iPhoneアプリ、Javascript,Ruby on Railsなどなど。

iOSのアプリケーションをどう設計するか

いくつかソースを見てきたのですが、
時と場合による
としか言いようがない感がすごいですね。

ただ、当たり前ですが、
基本的にはMVCに則って作っていくのが良いです。
そして、Modelをちゃんと切り分けるというのが、テストをする上で非常に大事になってくるかと思います(一番テストしやすく、一番テストするべき)。結局テストを書かないにしても、テストしやすいコードは正義です。

さて、どうやって切り分けるかですが、ここが難しいです。
M,V,CとおまけのDelegateを、他の設計やソースを引き合いに出しながら、印象などを語っていきます。

Model

Modelに関してですが、

  • Modelに通信機能を持たせる
  • 通信を管理するClientが存在する

という、2つのやり方がありそうです。
前者はBackbone.jsであったり(ModelやCollectionがfetchする)、Railsであったり(Active Recordがfindする)に着想を得ました。これを実装するのであれば、NetworkModel 的な抽象クラスを作って、適当に継承して使うことになりそうです。
後者は、TDD的にiOSアプリケーション開発してみる - yaakaito's diaryにて紹介されています。これは確かに綺麗です。「Twitterという外部APIを使う」という前提があるから、このようになっている気はします(思い込み?)。他に、乱暴な例としてはLast.fmのLastFMService.mが該当します。これの場合はSingletonなどを使っていて、死んだ魚のような目をしている方もいらっしゃるかと思いますが、実装の一つとしては全然ありかと思います。
継承厨な僕としては、前者の方が好きです。真面目な話、
時と場合による
前者は、モデルに基づかないAPIが出てきたら瓦解していく気がしますし、後者のLast.fm式はAPIが増えてきたら面倒くさくなりそうです。

View

Viewに関してですが、Storyboard世代なためにxibファイルなるものをあまりよく知らないのですが、あまりHogeHogeViewみたいなViewクラスをガシガシ作ったりはしないようです。っていうかその必要がないんでしょうね。
しかしViewを拡張orちょい替えしたい時はLast.fmのUITableViewCell+ProgressIndicator.mのような形でカテゴリ(参考)を使うか、継承するのがいいでしょう。
カテゴリは既存クラス自体を改変するので、「なんでこんなのも実装してねえんだよ糞Apple」という意味合いです。というか、カテゴリは本来そのためにできたものではないので、やり過ぎは禁物です。
逆に継承は「俺はこんなView作ってやったぜドヤァ」って感じです。ネイティブに備わっているべきではないときでしょうね。つまり、
時と場合による
(例として引き合いに出してるLast.fmも、使い分けています)

少しおもしろいなーと思ったのが(自分だけ?)、TableのCellもひとつのViewとして独立させています。
UITableViewの機能が足りないというのは、実はUITableViewCellの機能が足りないだけ、というのに感心。

Controller

最後にControllerです。ViewControllerと言ったほうが馴染み深いでしょうが。
ここでのControllerの立ち回りは、Backbone.jsのようなクライアントサイドMVCと立ち回りは似ているでしょう。Viewからのイベントを受け取り、Modelの状態をViewに反映させます。
画面を操作するためにはViewControllerが必要になるので、通常は一画面一コントローラーで対応するようです。
ViewControllerを作るときは、継承して作るのが普通です。
時と場合によらず、Controllerはスリムな方が良いと言われています(そこで割を食わせるべきはModelです)。

Delegate

おまけです。なかなかに御しがたいやつです。かなりいろいろな(適当な)使われ方をされてます。
Callback的な処理は、ブロックを使う方法と、Delegateを使う方法があります(これはBackbone.jsも同様でsuccessに関数直書きすることもできるし、Model.onでイベントに関数をバインドすることもできる)。さらにDelegateは、別ファイルに書いたりもしてます。
Delegateは結局はControllerの処理を委譲するので、デブちんControllerと同じノリで、あまり分厚くしないのが吉かとおもいます。

参考

さっき思い出しましたが、AFNetworkingの例とか参考にするといいかも知れません。

終わりに

以上、iPhoneアプリ1個しか作ったことないくせに男の勘で設計を語ってみました。あんまりObj-Cの設計語ってるの見かけないですしね。
この考えをベースにして、設計し、後々報告しようかと思います。

広告を非表示にする