プログラミング MVPパターン ~理論編②~

どうも、はかせです。
今回はMVPパターンのメリットについてです。
どういうものなのかは前回の記事をご覧ください。
hakase0274.hatenablog.com

MVPパターンでは
計算
中継
描画
といった風に機能ごとにレイヤーが分かれています。

そして中継レイヤーがあるため計算と描画レイヤーは完全に分離されます。
中継レイヤーも結果を受け取る・渡すだけなので
それぞれのレイヤーの中身を知ることがありません。

各レイヤーは結果でのみつながっているため
処理を変えても他のレイヤーに影響を与えません。

これはさっきの疎結合に作りやすいというメリットによって
発生するメリットです。

各レイヤーは結果でのみつながっていると書きました。
つまり目的の結果を渡す・受け取れるならどのような実装をしてようが問題ないのです。

よくあるリモコンの例えでもしてみましょうか。
リモコンの電源ボタンを押すと対応する機械の電源がつきます。

人間はリモコンがどうやって信号を送ってるかなんて知りませんし
リモコンは機械が信号受けてからどんな処理してるかなんて知りませんし
機械は誰がどうやって自分に信号を送信してるかなんて知りません。

人間はリモコンの電源ボタンを押したら
電源を付ける信号が送られるという結果だけ知っていますし、
リモコンは電源ボタンが押されたら
対応する信号を対応機器に送るという処理をするだけですし、
機械は信号が来たら電源を付けるという処理を行うだけです。

つまり機械の動作には
誰がなんのリモコンで操作したかなんて関係ないのです。
だから誰でも使えるし
スマートリモコンなんかでリモコンを変えても問題なく動くわけですね。

これが拡張性が高いということですね。
前後の処理が何であれ
決められた入力に対して決められた出力を返すだけの処理ならば
前後の処理の中身を変えても入力が変わらなければ出力も変わらないので
前後の処理を修正したり、まるっと変えても問題ないよねってことです。

今回は理論編②ということでMVPパターンのメリットについて書きました。
ちなみにメリットとして○○やすいという書き方をしました。
良く見聞きするものとしては○○になるみたいな断言的な言い方をすることが多いです。

今回私が少し濁したような書き方をしたのはMVPパターンを採用しただけでは
疎結合にもならないし拡張性も高くならないからです。

デザインパターンやらアセットやらはちゃんと使い方や概念を理解して初めてメリットが生まれます。
MVPパターンだって3つの機能レイヤーに分けても
それぞれのレイヤーが他の機能と絡んでいたら
疎結合とはいえないでしょうし、
疎結合でないなら拡張性もあまり高くない可能性が高いです。

まぁ長々と話しましたが、
要はちゃんと使い方を理解してから
用法用量守って正しく使って下さいってことですね。

それでは今回はこの辺でノシ

はかせのラボ