🖥️

Cocoaアプリケーションで採用されていた、 MVCとはどのような概念なのか

2021/11/19に公開

iOS

0. はじめに

Swift UIが導入され、そろそろ3年が経ちます。
最近出番が少なくなりがちと思われるUIKitベースのアプリケーションではデフォルトのアーキテクチャとして MVCアーキテクチャが採用されていました。
このUIKitはCocoa Touchというフレームワークの上で動いています。
そして名前からわかるように、CocoaTouchはCocoaから派生しています。
このCocoaでよく使われるアーキテクチャはMVCというアーキテクチャで、UIKitがCocoaの派生であるため、UIKitベースのアプリケーションではMVCアーキテクチャがよく使われていました。

このMVCアーキテクチャは多くの文脈で否定されがちで、デメリットが多いアーキテクチャではありますが、Appleがデフォルトアーキテクチャとして採用したからには何かのメリットがあったはずだと考えて調べてみました。

1. AppleのMVCパターン

実はAppleがMVCパターンについて下記のようなドキュメントを公開しています。

MVCパターンの概念図(Appleドキュメントより引用)

AppleのMVCパターンは上記のような働きをします。
登場人物である、Model、View、Controllerについてはそれぞれ下記のように定義しています。

1.1 Model Object

Model Objectは下記のようなものと定義されています。

原文) Model objects encapsulate the data specific to an application and define the logic and computation that manipulate and process that data.
和文) モデルオブジェクトは、アプリケーションに固有のデータをカプセル化し、そのデータを操作および処理するロジックと計算を定義します。

1.2 View Object

View Objectは下記のようなものと定義されています

原文) A view object is an object in an application that users can see. A view object knows how to draw itself and can respond to user actions.
和文) ビューオブジェクトは、cです。ビューオブジェクトは、それ自体を描画する方法を知っており、ユーザーのアクションに応答できます。

1.3 Controller Object

Controller Objectは下記のようなものと定義されています

原文) A controller object acts as an intermediary between one or more of an application’s view objects and one or more of its model objects.
和文) コントローラオブジェクトは、1つ以上のアプリケーションのビューオブジェクトと1つ以上のモデルオブジェクトの間の仲介役として機能します。

2. 読んでみて思ったこと

上記の定義のとおりに実装できるのだとしたら、MVCパターン意外と悪くないんじゃないって思いました。

前述の通りModelには アプリケーションに固有のデータをカプセル化し、そのデータを操作および処理するロジックと計算 が定義されているため、Modelのデータを実際に操作する処理はModel自身が持つことになります。

またViewは ユーザーが表示できるアプリケーション内のオブジェクト のため、表示に関わる部分以外の責務は負いません。

このため、 ModelとViewオブジェクトはアプリケーション全体で再利用可能になります。

またControllerは 1つ以上のアプリケーションのビューオブジェクトと1つ以上のモデルオブジェクトの間の仲介役 のため、Controllerとしての振る舞いはViewによるInputを適切にModelに伝播させてあげることだけです。

上述のようにAppleのドキュメントどおりに開発した場合、MVCアーキテクチャだからといっていわゆる FatViewController になるわけではなく、むしろ責務が明確に分離されているので各Objectに記述されるコードの一貫性も保たれると考えています。

私はFatViewControllerが生まれてしまう大きな理由の一つには、本来Modelに切り出すべきロジックや計算をControllerに持たせてしまうこと があげられると考えています。

例えば、あるデータを取得するために必要なAPI通信だったり、表示中のModelの詳細な更新処理など をController側にもたせてしまうと、Controllerの責務が本来の責務の範囲を超えるためFatViewControllerになると思います。

そうしてその様になったコードは概して読みにくく、理解しにくく(主観)なり、その結果1つの修正を加えるのに大きな時間がかかるようになります。

3. まとめ

この問題について調べる前は個人的にMVCアーキテクチャはFatViewControllerを生み出す悪魔のアーキテクチャじゃないかと思っていました。
しかしながら、Appleのドキュメントを読むことによってAppleの考えるMVCパターンは適切に責務が分けられているので、意外といいアーキテクチャで、むしろControllerの肥大化が最小限に抑えられるというメリットが有ることがわかりました。

MVC意外と悪くないです。