質問: 目的に対して適切な手段を取るのが正解との事で、ModelとViewに分ける目的をある程度はっきりとさせておきます。 後にコンソールで動く将棋ソフトを作る際、Model部分を変更させずに再利用できる様にすると言う事が目的です。
回答: こんにちは。 面白い問題ですね。Stateパターンを使って駒の描画を切り替えたいけど、それではモデル側に描画処理が入ってしまいMVCから逸脱するので、何か良い案はないか?ってことですね。 スキンを切り替えた時、駒のデザインも切り替えたいような場合に実際に発生しそうな問題です。 駒のデザイン切り替えをサポートする場合、モデルがビューに依存しない構造はたいへん好ましい設計と思います。となると、2.はモデルがビューに依存するため、1.をベースに考えざる得ないと思います。 なので、そこにstateパターンを適用できないか考えるべきでしょう。 例えば、モデル側の駒クラス経由で駒オブジェクトを受け取り、駒画像を返却するような機能を持つビュー側駒クラスを考えることは可能ですね。 そして、そのビュー側駒クラスはデザイン毎に派生クラスを作りStateパターンを適用すると、デザインの拡張に対応しやすいです。 問題はその中身が駒の種類毎にifかswitchによる分岐が発生するので、当初の問題を解決できていないことです。 デザインは通常 駒にインデックス番号などを振って駒画像をテーブルで管理すると思います。駒画像のメンテナンスもそうしておかないと辛いですし。 であれば、駒オブジェクトからインデックス番号などを受け取って、そのテーブルを引いて画像を返却する構造にすれば、駒の種類が増えてもテーブルの要素を増やすだけで済み、分岐コードの改造は不要ですのでStateパターンのメリットと同様なメリットを享受できます。表の追加の方がクラス追加より手間は少ないです。そして、これはデザイン切り替えしない時にも適用できます。 しかし、このアイデアはオブジェクト指向プログラミングかというと、微妙です。 少なくともStateパターンからは外れています。また、オブジェクト指向プログラミングは配列の取扱について特別な何かを提案している手法ではありませんので、配列(表)を使うことが「厳格で純粋なオブジェクト指向」に則っているかと言うと微妙です。 【余談ですが】 では、使うべきでなはいかと言うとそうではないです。 オブジェクト指向プログラミングを使うことでメリットがある時はたいへん多いのでどしどし使うべきですが、オブジェクト指向は万能ではないので使えない時まで無理して使うのは愚かと思います。(MVCも同様です。) オブジェクト指向プログラミングもMVCも、なんらかの目的(主にメンテナンス性や再利用性)を満たすための手段です。オブジェクト指向に拘ってメンテナンス性を劣化させては本末転倒です。「手段のために目的を選ばない」のは、学習や研究時だけに限定しておくことをお勧めします。 手段自体を学んだり研究したりすることが目的の時はもちろん手段重視でOKですし、今回のようなテーマはたいへん興味深いです。