はじめに
MVPは
Model
View（View,ViewController）
Presenter
の3つで構成されています。MVCではViewとViewControllerは分けて考えられていましたが、MVPにおいてはViewとして扱われます。
なぜMVPなのか
MVCではViewControllerの責務が大きくなってしまうため、テストの容易性や作業分担のしやすさといった問題があります。それを解決するためのアプローチがMVPです。以下では、MVPにおける役割分担をMVCと交えながら確認していきます。（なお今回はMVPの中でもPassiveViewパターンを取り扱います。）
MVC
Model
・ビジネスロジックを担当
View
・画面の描画処理
Controller
・Viewの入力に対し処理を行う( Controller はViewに依存 ）
・Modelに処理を依頼する（ Controller は Modelに依存 ）
・Modelの情報を取得するためにAPI等に問い合わせる（ ControllerはUtilityに依存）
以上のようにMVCにおいてControllerは多くのロジックが詰め込まれているおり、抱える責務が多くなってしまいます。またはControllerは、View、Model、Utilityに依存している為、作業分担やテストの容易性といった点で問題があります。
MVP
Model
・MVCと同じくビジネスロジックを担当
View（ View, ViewController ）
・Presenterに処理を依頼（protocolを介して依頼する為、任せる相手は知らない→疎結合)
Presenter
・Modelに処理を依頼（Presenter は Modelに依存）
・Modelの情報を取得するためにAPI等へ問い合わせる(Controller は Utilityに依存）
・outputに処理を依頼（protocolを介して依頼する為、任せる相手は知らない→疎結合）
一方でMVPにおけるController（View）の役割は、外部からのアクション（CellやButtonのタップなど）をPresenterに伝えるだけです。一見、ControllerとPresenter間に依存関係があるように見えますが、Protocolで関係を持たせているため疎結合の状態です。つまり、依頼を受けたPreseterも処理を伝える相手が誰であるかは分かりません。このようにプレゼンテーションロジックが切り離されている為、デザイナーさんの作業が押してしまっていても作業を進めることが可能です。
終わりに
以上です。次はMVVMについてまとめようと思います！