投稿2017/06/28 14:12
編集2017/06/29 15:00よろしくお願いします。
凄く幼稚でバカな質問で恐縮ですがご回答ご教授いただければ幸いです。
デザインパターンにMVCモデルなどがありますが、MVCを守っていれば
自ずとオブジェクト指向になる、と考えても良いのでしょうか。
ある案件の担当者と話していると、MVCとオブジェクト指向は全く別物
なのでMVCを守ってるからと言ってオブジェクト指向になっているとは
言えない、という風なことを言われたのです。
確かにデザインパターンとシステムデザインは別物なのは分かっていますが
MVCを守ろうとすれば自ずとオブジェクト指向で書かざるを得なくなる
のでは？というのが私の見かた、考えです。
鉄と水を同じ単位で見てるようなものかもしれませんが、双方は
関係しあっていると思っているので、全く別ものとは思えないのです。
この私の見かた、考え方で、どの理解が足らないからダメなのか
どう理解すれば正しい理解になるのか。
凄く甘えた質問で恐縮ですが、ご教授いただければ幸いです。
よろしくお願いいたします。
【追記】
私としてはMVCとオブジェクト指向って１セットだと思っているところがあって、そこを相手に説明するにはどうしたらいいだろう？というのが今回の悩みです。
更に言うと、オブジェクト指向の上にMVCが成り立っていると考えているので、オブジェクト指向を知らずしてMVCで作る事なんて出来ないと思っているのです。
が、私の考え方は誤っているのでしょうか。
【追記２】
うまく表現できず申し訳ないですが、いろんなものが不足しているんだなと改めて痛感しました。
様々な方からご意見、ご教授ありがとうございました。
回答3件
0
ベストアンサー
MVCはオブジェクト指向言語でないとできないというわけではありません。
例えば、YesodはHaskellでできたMVCを採用したWebフレームワークです。Haskellは純粋関数型言語であり、オブジェクト指向とはまったくもって無縁の言語です。細かいところを触ったわけではありませんが、オブジェクト指向のオの時も出てくることはないでしょう。
そんなマイナーなものは知らないというのであれば、PhoenixというElixirでできたMVCなWebフレームワークがあります。ElixirはRubyっぽい文法ですが、中身はErlangの別表現です。Erlangこそが唯一のオブジェクト指向言語であるという意見もありますが、(オブジェクト指向の本質を知らない)ほとんどの人は、Erlang(つまりはElixirも)はオブジェクト指向から非常に離れた言語であると考えるでしょう。
オブジェクト指向言語ではないからオブジェクト指向では無いとは一概は言えません(非オブジェクト指向言語Cで作られたオブジェクト指向の実装としてGTK+のような例があります)が、多くの場合、非オブジェクト指向言語に対する無理なオブジェクト指向の採用はその言語の利点を潰してしまいます。上にあげたフレームワークも(細かい点まではみていないのですが)オブジェクト指向とは全く別の考えて作られています(たぶん)。
確かに、Ruby on RailsやPlay Frameworkなどを初めとした多くのMVCフレームワークでは、ScalaやRubyと言ったオブジェクト指向言語(と言われている言語)を用いて、オブジェクト指向の考えの上にMVCを構築しています。しかし、だからといってMVCの上にオブジェクト指向が必須というわけではありません。オブジェクト指向でMVCフレームワークを作る方法については数多くの実例や研究も進んでいるため、やりやすいという側面はあるかも知れませんが、必須とまでは言えないと思われます。
投稿2017/06/28 22:26
総合スコア21735
0
MVCを徹底したからといってオブジェクト指向にはなりません。
極端な話をします。
モデルクラス１つ・ビュークラス１つ・コントローラークラス１つという構成のプロジェクトはMVCと呼べますが、果たしてこれはオブジェクト指向でしょうか。
投稿2017/06/28 14:29
総合スコア18155
0
オブジェクト指向とは実現しようとしている機能を現実世界に即してアナライズし、モデル化してそれらの相互作用でシステムの動作を実現しようとする考え方です。
継承、ポリモーフィズム、カプセル化などは上記の考え方を実現しようとしたときに必須となったオブジェクト指向の「特徴」またはオブジェクト指向言語を実現するための「要件」です。
いっぽうＭＶＣとは、ユーザーインタフェースをもつ機能を実現する際の役割分担の方法です。WikiPediaからの転載ですが以下のような役割分担をします。
model: アプリケーションデータ、ビジネスルール、ロジック、関数
view: グラフや図などの任意の情報表現
controller: 入力を受け取りmodelとviewへの命令に変換する
両者はイコールではなく、どちらかを実現させたからといってもう一方を満たすことにはなりません。
以下に、同一の機能をＭＶＣで実現するときにオブジェクト指向設計をした場合としなかった場合の２パターンの設計例を示してみます。
■ＭＶＣ（オブジェクト指向設計無し）
給与/賞与を参照する画面
【クラス名：機能】
CommonView01：給与/賞与照会選択画面
SubView01：給与照会画面
SubView02：賞与照会画面
SubController01：給与照会画面のコントローラー
SubController02：賞与照会画面のコントローラー
SubModel01：給与照会画面の業務ロジック
SubModel02：賞与照会画面の業務ロジック
■ＭＶＣ（オブジェクト指向設計有り）
給与/賞与を参照する画面
【クラス名：機能】
modeSelectView：給与/賞与照会選択画面
salaryView：給与照会画面
vonusView：賞与照会画面
salaryManager：給与照会画面のコントローラー
vonusManager：賞与照会画面のコントローラー
salary：給与照会画面の業務ロジック
vonus：賞与照会画面の業務ロジック
ちょっと極端な例ですし、名前が変わっているだけですが、前者も後者もＭＶＣモデルで実現できます。
ただし後者のような考え方で設計したほうが各機能で必要な機能がイメージしやすく、役割分担の設計もやりやすい、後から見たときの各クラスの関係性も分かり易い、というのがオブジェクト指向の特徴です。
投稿2017/06/29 00:16
総合スコア1947
あなたの回答
tips
プレビュー
Q&A
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/06/29 14:53