MVCがいまいち理解しきれず困っています


MVCというデザインパターンでコード分けすることになっているのですが、  
様々なサイトを見てみるもMVCがいまいち理解しきれません。

まず以下の考えは合っているでしょうか？

  * `Model`はUIに関係のないことをする
  * `View`は`Model`から情報を取得して表示する
  * `Controller`は`Model`と`View`の仲介役

また、`View`のイベントを処理して`Model`に何かさせるのが`Controller`かと思うのですが、  
`Controller`には例えば`View#setOnClickListener`などを記述すれば良いのでしょうか？  
それとも`View#setOnClickListener`自体は`View`に記述して  
`View#onClickListener`かその中身を`Controller`に記述するほうが良いでしょうか？

あと、Androidの`Activity`や`Fragment`は`View`と`Controller`どちらに当てはまるのでしょうか？  
それから、`Fragment`にはどこまでやらせるのがよいのでしょうか？  
現状はxmlからの`View`生成程度しかやらせておらず、その`View`にデータをセットしたりというのは別のクラスでやらせています。




> `Controller`は`Model`と`View`の仲介役

私の場合は、もっと単純に **入力** という言葉で片付けてしまっています。  
つまり **VC** はまとめて **出入力** 。  
**それ以外の** 、入出力インターフェースから切り離した、純粋な **内部ロジック** の部分が **Model** 。  
[Wikipediaの解説](https://ja.m.wikipedia.org/wiki/Model_View_Controller)によると

> このような **M-VC** となるような構造を **Document-View** と呼ぶ

そうです。 **V** と **C** の違いはわりとどうでもよくて、まずはともかくは **M** を他から切り離したい、というのが肝ではないかと思います。

一方、Androidの膨大なAPI群は **VC** がほとんどだろうと思うので、 **V** と **C**
の違いはかなり前面に出てくると思います。基本的にそのまんま、 **V** はAndroidでも`View`と呼ばれているので、迷う余地は少ないと思います。

**Activity** というのは **MVC**
とは完全に違う次元の捉え方なので、無理に混ぜて考えない方がいいと思います。イベントを中心にどう振る舞うかというようなものだと思うので。対して **MVC**
は単純に部品（ブツ）を分けているだけです。

>
> 現状Viewへの表示とViewのイベント処理を同じクラスでやらせてしまっていて、VC的にはそこを分けたほうが良いだろうけどどこで分けたら良いかわからない‌​状態です。

**V** と **C** の境界で悩まれているようですが、実は、 **M** さえ間に一枚挟めば、必然的に解消されてしまうことなのです。 **V** と
**C** の境界について考えるあまり、 **M** の存在がどこかに行ってしまってはいませんか？

**View** は **Model** から読み取って **受動的に** 表示するだけです（ **出力** ）。 **View**
へのイベントは、実は、「 **View** へ」と考えるのではなく、 **Model** へのイベントであり、 **Model**
の内部状態を変更するために受け取ります（ **入力** ）。

ですから、実際の Android プログラミング的には、`View`に`OnTouchListener`を implement するというのは、
**MVC** 的ではないと思います。外側から、`View`に対して、`OnTouchListener`を set することはあっても、callback
を受けとる主体が`View`なのではなく、そこはあくまで、 **Controller** と **Model** の間の関係であるべきです。

* * *

## Model について

**Model** は、簡単な例で言うと、オセロ（リバーシ）ゲームをプログラムするとして、8x8 の升目を 64 の int 配列で表現する（か、8x8 の
2 次元の int 配列で表現する）という部分が **Model** です。（int にするのは 0: 空; 1: 白; -1: 黒とでもするため）

**View** はこの配列を見て、どういう風に表示すればいいかだけを常に考えています。

**Controller** はユーザーからの操作や、何らかの外部的な要因によって、この配列に適宜変更を加える役割だけを考えています。

こうすることによって、必然的に、 **V** と **C** が直接触れあうことはなくなり、間に、「わざわざ」 **M**
という薄紙を一枚挟むことの利点が得られるわけです。

特に、 **C** → **M** → **V** という 3
段階の流れで考える必要はないと思います。手続指向ではないからです。（結果的にはそういう順番の手続で処理されますが）




> `Controller`は`Model`と`View`の仲介役

私の場合は、もっと単純に **入力** という言葉で片付けてしまっています。  
つまり **VC** はまとめて **出入力** 。  
**それ以外の** 、入出力インターフェースから切り離した、純粋な **内部ロジック** の部分が **Model** 。  
[Wikipediaの解説](https://ja.m.wikipedia.org/wiki/Model_View_Controller)によると

> このような **M-VC** となるような構造を **Document-View** と呼ぶ

そうです。 **V** と **C** の違いはわりとどうでもよくて、まずはともかくは **M** を他から切り離したい、というのが肝ではないかと思います。

一方、Androidの膨大なAPI群は **VC** がほとんどだろうと思うので、 **V** と **C**
の違いはかなり前面に出てくると思います。基本的にそのまんま、 **V** はAndroidでも`View`と呼ばれているので、迷う余地は少ないと思います。

**Activity** というのは **MVC**
とは完全に違う次元の捉え方なので、無理に混ぜて考えない方がいいと思います。イベントを中心にどう振る舞うかというようなものだと思うので。対して **MVC**
は単純に部品（ブツ）を分けているだけです。

>
> 現状Viewへの表示とViewのイベント処理を同じクラスでやらせてしまっていて、VC的にはそこを分けたほうが良いだろうけどどこで分けたら良いかわからない‌​状態です。

**V** と **C** の境界で悩まれているようですが、実は、 **M** さえ間に一枚挟めば、必然的に解消されてしまうことなのです。 **V** と
**C** の境界について考えるあまり、 **M** の存在がどこかに行ってしまってはいませんか？

**View** は **Model** から読み取って **受動的に** 表示するだけです（ **出力** ）。 **View**
へのイベントは、実は、「 **View** へ」と考えるのではなく、 **Model** へのイベントであり、 **Model**
の内部状態を変更するために受け取ります（ **入力** ）。

ですから、実際の Android プログラミング的には、`View`に`OnTouchListener`を implement するというのは、
**MVC** 的ではないと思います。外側から、`View`に対して、`OnTouchListener`を set することはあっても、callback
を受けとる主体が`View`なのではなく、そこはあくまで、 **Controller** と **Model** の間の関係であるべきです。

* * *

## Model について

**Model** は、簡単な例で言うと、オセロ（リバーシ）ゲームをプログラムするとして、8x8 の升目を 64 の int 配列で表現する（か、8x8 の
2 次元の int 配列で表現する）という部分が **Model** です。（int にするのは 0: 空; 1: 白; -1: 黒とでもするため）

**View** はこの配列を見て、どういう風に表示すればいいかだけを常に考えています。

**Controller** はユーザーからの操作や、何らかの外部的な要因によって、この配列に適宜変更を加える役割だけを考えています。

こうすることによって、必然的に、 **V** と **C** が直接触れあうことはなくなり、間に、「わざわざ」 **M**
という薄紙を一枚挟むことの利点が得られるわけです。

特に、 **C** → **M** → **V** という 3
段階の流れで考える必要はないと思います。手続指向ではないからです。（結果的にはそういう順番の手続で処理されますが）

