構成について ViewとController編
引き続き構成について考えてみます。
例えばページ遷移とかで考えてみる要求の流れ。
ページに三つのボタンがあって、遷移先が違うパターンとか考えてみる場合。
描画されてるのは最低限ボタン三つですね。
で、適当にボタンを押す。
すると画面遷移する。
純粋な遷移動作としてはそれだけです。
その場合、まずクリックという操作がある。
操作をControllerが受け取り、Viewにどの位置……というかどのボタンがクリックされたか、もしくはどのボタンでもない場所がクリックされたか問い合わせる。
ボタン外なら動作なしという動作になって動作が終了する。
ボタン内ならどのボタンがクリックされたかを投げ返す。
ここで例えばボタンAをクリックされたことが確定する。
ココ。
重要なんでもう一度、ココ。
この『ボタンAがクリックされた』という操作は一番はじめのControllerに通知する必要があるのか？ というところ。
もし通知してはじめのControllerに画面遷移動作を突っ込むとすると別の画面遷移も全部そこに入ることになりますよね、と。
これ、画面追加する時に死ぬんじゃねぇの、と。
というか特定ページが持ってる三つの遷移先のページ情報をそんなControllerが知る必要はあるのか？ と。
そういう考え方をすると、完全にないんですよね。
だから、一番はじめにくるのはControllerじゃなくてInterfaceであるべきなんです。
Interfaceではクリックされた位置とか入力されたキーボードのキーとかキー入りっぱなしになってるかどうかとかそういう操作と、操作の通知先だけを管理するべきなんです。
そうしないと死にます。
主に、ページ追加した時とかに。
じゃあどこでページ遷移動作を作るのか、と考えると、Viewに対応したControllerですべきなんです。
Interfaceは、そのViewのControllerに対して操作を通知するだけじゃないとダメなんです。
ということでView用のControllerを作りそこからページ遷移します。
そこで新しいView作って自分で管理するとInterfaceの二の舞になるんで、次のView用Controllerを作って動作を引き継ぎます。
その時にInterfaceにどのページが表示されてるか通知しないと操作が通知できなくなるので注意が必要です。
次のControllerを作って、そちらのViewが準備できたタイミングで引き継ぎます。
引き継ぎの際に忘れずにInterfaceに表示されてるViewのControllerが変わったことを通知します。
次に、もしかしてコレってページ戻ったりできるの？ とか考えた場合。
もしページを戻る度に描画が変わるならViewを削除して前のControllerも消せば良い。
もし描画が変わらないならもう一度作り直す手間が無駄になることを考えて、どこかで保持すれば良い。
でも、Interfaceでやったらダメです。
Interfaceはそんなデータの管理を期待されているクラスじゃないから。
もしやるなら、ページ順を保持する配列とページ情報を保持したModelクラスを作ってそちらでやりましょう。
多分Pagerとかそういう名前のクラスになると思います。
私が考える構成、ViewとControllerの基本的な考え方としてはこんな感じですね。
次回はModelとController編。
実際にはButtonクラス等が標準装備されている言語が多く、View(UserInterface)からControllerに通知するというのが一般的です。
というか最近の主流な言語なら全て標準装備されてます。
おとなしくそちらから通知を受け取りましょう。
下手に手を入れないほうが良い。
ちなみにその場合のInterfaceの役割はOSからの通知を管理することになってきますね。
起動要求があった場合にはじめのControllerを生成、描画要求を投げるところとか。
スマホだとホームに戻った時にどうするのかとか、アプリに戻ったときにどういう要求をすればいいのか、とか。
なんにしても、そこに通知先としてのControllerの方法以外のものを持つのはよろしくないな、と。
下手なものを乗せるとそこが拡張されていって膨大なコードを抱える不良債権になりかねないですから。
そうなると、バグの温床です。
