cocoa - Cocoa MVCは本当にMVPではありませんか？

Question

繰り返しになりますが、MVC関連の質問です。数日前、AppleがMVCの実装について説明しているAppleのCocoaFundamentalsGuideを読み始めました。

複合デザインパターンとしてのMVCの章（リンク）では、2つのMVCバージョンを比較しています。

• 古い/従来のSmallTalkバージョン：

• 現在のApple定義バージョン：

彼らはこの現在のモデルを次のように説明しています。

この複合デザインパターンのコントローラーオブジェクトには、メディエーターパターンとストラテジーパターンが組み込まれています。モデルオブジェクトとビューオブジェクト間の両方向のデータフローを仲介します。モデルの状態の変化は、アプリケーションのコントローラーオブジェクトを介してビューオブジェクトに伝達され ます。

従来のパターンはMVCのように見えますが、何も問題はありません。しかし、彼らの現在のパターンの名前は私を混乱させます。私の知る限り、コントローラーは常にビューとモデルの間を仲介しているように見えるため、これは単純なMVPと見なすことができます。

私は完全に間違っていますか？MVCまたはMVPを誤解していますか？それとも、Appleはこのパターンに間違った名前を使用しただけですか？そしてさらに重要なのは、なぜこの現在のパターンがMVCと呼ばれるのですか？

Answer 1

あなたは間違っていませんが、Appleのドキュメントの作者でもありません。

MVCの歴史は長く複雑になっています。特に、多くのシステムが、コントローラーをモデルに混乱させたり、コントローラーをビューに混合したりする3つの部分からなる分離を提唱しているためです。非常に初期のSmalltalk実装から、モデル情報をビューから除外することは非常に良いことであり、これはかなり簡単に実行できることが明らかになりました。

一方、コントローラーとビューの責任を明確に分離することは、はるかに簡単ではありません。ボタンやテキストフィールドなど、多くのビューを再利用したいと考えています。コントローラの再利用可能な部分も再利用したいと考えています。ただし、テキストフィールドを押したり、ボタンを太字にしたりしないでください。ボタンの動作の多くは、ビューと非常に密接に関連しています。同時に、ビジネスルールがモデルに属しているのか、コントローラーに属しているのかを確認するのは難しい場合があります。

さらに、この（非常に優れた）Appleドキュメントは、The One True Wayを説明するのではなく、哲学的なデザインのアイデアを捉えようとしています。多くのCocoaコントローラーサブシステムは、従来のMVCによく似ています。従来のココアはコントローラーを重視していなかったため、このドキュメントは、本質的に、（再利用可能な）ビューと（再利用可能な）モデルの間の仲介者としての場所を提供することを主張しています。

多くのCocoa実装者は、ビューとモデルを分離するためのファサードとして本質的に機能するシンコントローラーを好みます。

Answer 2

MVPはMVCのサブセットであるため、MVCシステムでMVPを見つけるのは当然のことです。はい、その2番目の図はMVPパターンを示しています。

Appleはそれを仲介コントローラーと呼んでいます。これは私が合成したもので、MVPの単なる別名です。

率直に言って、MVPという用語が理解されるべきかどうかはわかりません。これは、まったく異なるパターンであることを意味し、プレゼンターはUIに焦点を合わせているように見えますが、モデルとコントローラーの関係にすぎない場合もあります。仲介コントローラーは、その違いを非常に簡単に説明します。

私はあなたが何を求めているのかを知るためにもMVPを調べなければなりませんでした。この用語は1996年の論文で使用されました。OSXがリリースされたとき、それはまだ新しいものでした。