アプリ界隈で「設計」の話をするときに MVC / MVP / MVVM のような「設計パターン」だけが語られるようになった気がする。

往々にして、「アプリの規模によってどれを採択すべきかは変わる」みたいなお茶を濁すような結論で終わることが多い。

私的な結論

以下、思うところのメモ。

MVC は Model をどう構築するかについてとくに規定していない。

MVC への批判をするときに、FatVC が持ち出されることが多いのですが、FatVC を実装してしまうのは単に実装者の能力不足だと考えていて、MVVM を採用しても FatVM を作るだけだと思っている。

また、比較的新しめの Flux アーキテクチャは、良く言えば MVC を詳細化したもの、悪く言えば MVC の再発見とみなすことができる。

VC や Activity をクリーンにすることは重要なものの、そこに熱中しすぎるのはよくないと考えている。

VC や Activity は単一の View における状態の管理と、それらの View 同士の遷移の状態の管理を担っているため非常にやれることが多く、また、管理している状態も極めて複雑である。

これを上手く抽象化してパターンに当てはめるという試みが多数行われているものの、基本的にはトレードオフであり、正解はない。

もともと単体の VC や Activity で簡単にできたことがとてもとても複雑になってしまうというのはまだマシなほうで、インタラクティブ画面遷移のような「View の状態」と「遷移の状態」の両方を扱う操作は欠落してしまうようなケースもある。

GOD クラスの影響を低減させる試み自体は概ね好ましいものの、そこで消耗してもアプリの価値が劇的に向上することはないので、ほどほどに割り切って上手く付き合っていくのが良いと思っている。

MV* は実装フェーズ、それも GUI 実装のみに限定されたパターンの話でしかないはず。

対して、DDD はソフトウェア製造全体に対する巨視的な考え方をしているものだと思うし、Clean Architecture はアーキテクチャを構築する上での指針というか、設計パターンに対するメタな話だと解釈してるのですけれど、なんか同列で語られることが多いのが個人的にはもにょい。

あと DDD や Clean Architecture を独自解釈（というか、ネットの情報ベースで語っている？）ことについて思うところがないわけではないのですが、まだ原著完全に読めてないのでとりあえずノーコメント。

まともなデータバインディング機構がないにも関わらず、MVVM が採用されるパターンが多い。自分もやる。

必ずしも悪いわけではないものの、以下のような副作用は散見される。

「設計」をやるときに GUI をどういうパターンで組むのか？から入るのは、ぶっちゃけよほど簡単で先の見通しがはっきりしている状況でもない限りは、悪手だと思う。

どういう要件があり、どういった機能を実現する必要があるのか？にまず興味を向けるべきで、ビジネスロジック・ドメイン層と言われる領域をうまく抽象化し、UI や DB などと隔離されたかたちで実装できるか？というところがもっとも肝要で、それこそが本来やるべき「設計」じゃないのかなぁと思っている。

設計パターンやアンチパターンの根底には大体プログラミングの原則の考え方が根付いている。

「BaseVC はアンチパターンだからダメ」みたいなのは単なる思考停止なのであまり好きではない。

たとえば「開放閉鎖原則の観点から、この実装では変更に対する柔軟性を失っており好ましくない BaseVC である」という指摘が入ると、具体的な問題箇所が明らかになり、どうやって修正するか？という建設的な議論に入ることができる。

最終的に GUI を作る以上は MVC や MVVM や MVP などの GUI の設計パターンを採用することになる。

このとき、人や本を権威にして「MVC はダメ」「MVVM は実はこんなデメリットが」みたいに流されるだけではなく、自分で手を動かして実装するなり、コードリーディングはしなければならないと考えている。

というのも、作ったことも触ったこともないものに対して、どれが最適かなどという判断を下すことなど不可能なので。

ひとつの設計パターンに成功体験を持ってしまうと、その設計パターンがあらゆる状況で通用するものだと勘違いしてしまいがちだったり、その逆にも注意をする必要があると思う。