- 締切済み
WEBシステム作成でのオブジェクト指向の無駄について
データベースを使用したWEBシステムの作成に、オブジェクト指向は非効率なだけだと思います。 まず、クラスを使用しない方法（include文などは使用）で作成したPHPデータベースプログラムと 同じシステムを、オブジェクト指向で作ろうとすると、かなり分かりにくいコードになると思います。 さらに、作成をしたシステムの改良やデバックにかなりの時間がかかります。なぜなら、プログ ラム上の変数の動きが非常に把握しにくいからだと思います。 プログラムの再利用なら、よほどよく使う部分や、セキュリティ上必要なところを、include文などで 管理をすれば良いと思うのです。 C/Sシステムやゲーム等ならともかく、WEBシステムでは、すでに、一つ一つの動作にプログラム ファイルが必要なのに、それをさらにクラスに分けて、変数をあちらこちらに飛ばす作りは分かりず らいと思います。 複数人で作成をする時も、WEBシステムでは、オブジェクト指向よりも各ページファイルの動作 プログラムの部分をお互いに担当していった方が、効率的で、またエンジニアもやりがいが出る と思います。 ただ、複数人で作成をする時は、プログラムで使用した変数の用途や概要などの一覧表などは、 あった方が良いと思います。 WEBシステムの作成でオブジェクト指向ではない方が効率的に感じている人で、他にも意見があ る人は教えてください。
- みんなの回答 （7）
- 専門家の回答
みんなの回答
- us123
- ベストアンサー率26% (10/38)
Squeak（フリーなSmalltalk環境）を参考にしたら「オブジェクト指向」についての見方が広がると思います 参考 http://squeak.qp.land.to/wiki/index.php?FrontPage
- bnosuke-x
- ベストアンサー率39% (43/110)
PHPはほとんど素人で、Javaは人に教えることができるくらい知っている者です。 PHPの知識レベルとしては回答できるものではないのですが、質問者と回答者の間に認識の違いを感じましたのでちょっと口を挟ませていただきます。 質問者の方は、PHP4の不完全なクラス機構をベースに考えていて、 ＃１から＃５の回答者の方はJavaやRuby、PHP5等で実現されている（ほぼ）完全なオブジェクト指向を前提に回答されていると思います。 結論を言うと、PHP4の不完全なクラスの仕組みは確かに非効率で使わない方が良くて、PHP5から導入されたクラスの仕組みならどんどん導入していった方がいいです。 回答者のほとんどの方は、「オブジェクト指向は使えないと言うが、それは設計がまずいだけできちんと設計を行えば開発効率は累積的に向上する」とおっしゃっています。 それに対して、質問者の方は「ページごとにソースファイルがあるのに、更にその中でファイルを分割しては変数の把握が困難になり、もっと訳がわからなくなる」という事ですよね。 ここが誤解の元です。 PHP4のクラスの仕組みは、クラスの内部に対するアクセス制限ができないそうですね。 クラスの内部で宣言した変数は、どこからでもアクセスできる。 なるほど、これでは大変です。 変数名、メソッド名を全て把握していなくてはならない。 けど、オブジェクト指向ではそうはしないです。 変数もメソッドもなるべく隠して、外部とやりとりすべきものを最低限の範囲で露出する。 内部にアクセスしたいときは、極力メソッドを通してアクセスします。 メソッドを通すことで内部の変数名を意識する必要が無くなり、間違ったアクセスを排除することができます。 そもそも名前だって衝突しないから、よそでどういう名前を使っているかは全く意識せずにプログラムを組みます。 そもそもPHP4ではクラス間で名前が衝突するのですか？ クラス内の変数にアクセスするときは「インスタンス変数名->変数名」でアクセスするから、名前についてはクラス内だけ意識すればよいのではないでしょうか。 それとも他所と衝突してはいけないのでしょうか。 クラス間で名前が衝突するなら確かにその仕組みは不便です。 もっと言えば、変数名が簡単に衝突するPHPそのものが大変な弱点を抱えていて、大規模または共同作業での開発に向いていません。 これはご質問者自身の 「ただ、複数人で作成をする時は、プログラムで使用した変数の用途や概要などの一覧表などは、あった方が良いと思います。」 という記述にも現れていますよね。 CやJavaに慣れている人間にとって、目の前で宣言した変数の名前が他所でどう扱われているかを意識しなくてはならないなんて、とても考えられません。 「これから変数名の通用する範囲はプログラムの全体になります」なんて言われたら、「電気のない生活に戻りなさい」と言われるようなものです。 その上でクラス分割しろなんて言われたら、そりゃあ困ります。 けれど、PHP5からアクセス制限もできて、より分割での開発がしやすくなったようですね。 当然名前もぶつかりませんから、こちらなら納得です。 というわけで、まとまりが無くなってしまいましたが、オブジェクト指向には何ら関係ないお話なのでは無かったのでは無いでしょうか。
- lv4u
- ベストアンサー率27% (1862/6715)
No.2です。 >>クラスを使用いたしましたオブジェクト指向でのプログラムは、構想設計や作成はもちろん、改良やデバックにも大変な手間と時間がかかってしまうと思います。 No.4さんの回答にもありますが、ちゃんと設計・製造されたオブジェクト指向のプログラムならば、想定している範囲の改良が発生した場合、そうでない場合よりも、ずーと簡単に短期間でバグ無く完了します。 Ｃ＋＋のＳＴＬの使用例を見ると、通常ならば、うん百行規模の大規模改修も数行の修正でできています。 ただし、想定外の大幅な改修とか、ささいだけど、幅広いところに影響するパラメータ追加などがあると、再設計の手間が大きくなると思います。それでも、オブジェクト思考でやっていて良い点は、「再設計に時間がかかるかもしれない」けど、機能の検討とコードの集中化がされるため、ある程度安心して作業が進められるってところではないでしょうか？ つまり、「とりあえず修正して動くようになったけど、バグがあるかも？」って不安が少なくなるってことです。 多くの利用者に影響があるシステムの修正作業が、構造化プログラムだと１ヶ月だけど、オブジェクト指向だと３ヶ月必要になるとしても、作業が正確に確実にできるなら増えた２ヶ月分の工数なんて目じゃあないと思うんですけどね。 先日、スカパー！の歴史番組でやっていたのですが、弓矢と鉄砲のコスト計算では、弓矢のほうが高くつくというのです。なぜかというと、人件費を考えると、弓矢は射手を常勤にして訓練して技量を維持しないといけない。でも、鉄砲はある程度の初期訓練をやれば軍隊に必要な命中精度は維持できるから、常勤にしなくても良い。鉄砲や火薬が弓矢よりかなり高価でもトータルでは安くなるというのです。 鉄砲の製造と修理には、さまざまな分野の知識と高度な技量が必要になります。でも、鉄砲、特にライフル銃を使えば、平凡な兵士でも数百ｍ離れた敵を楽々殺せます。相手が鎧を着ていたら弓矢では、それを貫くのは無理ですが、鉄砲では楽に貫通します。 そして、オブジェクト指向は鉄砲に相当するのではないでしょうか？そのクラスの製造・修正をするのは、オブジェクト指向の技術に精通した経験２０年以上の「マスター」といわれる少数のプログラマが行う。そして彼は一子相伝とまではいわないが、少数の弟子を後継者として育て上げるのが仕事の一つとなる。そしてきちんとしたクラスの設計・製造ができるようになると「免許皆伝」となり門外不出とされるクラスの設計秘伝が授けられ、テンプレートの呪文が使えるようになる・・・。
お礼
お返事をありがとうございます。 ご意見をお聞きしまして、考えてみたのですが、オブジェクト指向は、やはり、WEBシステム以外での プログラムに対しましては、有効な一つの方法だと思います。 なにより、一つのプログラムファイルに何千行ものプログラムを入れる必要が出てきました時に、シス テム上の各処理のプログラムを分けて作成をしなければ、把握がしずらくなってしまいます。 だた、WEBシステムにおきましては、状況が違ってくると思います。 先ほどにも、お書きをしました様に、WEBシステムでは、すでに、一つ一つの動作にプログラムファイル が必要となっています。 このシステムでは、一つ一つの動作への把握は、基本的にプログラムファイル単位で行っていると 思います。 修正やデバックもホームページ上の各ページファイルを開いた時のプログラム結果（エラー結果など も含む）を基に対応をしていきます。 このようなシステムでは、あえてオブジェクト指向で行う必要がほとんどなく、また、かえって分 かりずらくなってしまいます。 ただ、便利だったり、よく使用します処理プログラムの部分などや、セキュリティ上の必要な部分など を別のファイルなどにいたしまして、モジュール化をしておきましたら、クラス関数を使用しなくて も、これも一つのオブジェクト指向の作りだと思います。 やはり、WEBシステムにおきましては、モジュールを作るにしましても、変数の動きが把握しず らいクラス関数は出来るだけ使用をせずに、分かりやすい作りを目指してまいりたいと思っています。 ところで、弓矢と鉄砲のお話は、興味深かったのですが、少し今回のお話には、あてはまらない様 な気がしますよ。 ただ、オブジェクト指向の思想の枠を、クラス関数の使用だけでなく、様々な方法も含めました、 プログラム設計構築上の概念的な思想に対しましてなら、少しだけは分からなくもない感じはい たしますけれども。 でも、一子相伝のお話は、面白かったですよ。ファンタジーの物語をいろいろ思い浮かべてしまいました。
- dyna_1550
- ベストアンサー率34% (122/353)
＞ オブジェクト指向の場合、実際のプログラムとの比較を考える時に、構想 ＞ がしずらくなりまして、結果的に時間もかかってしまうと思うのです。 オブジェクト指向のメリットに「工期短縮」とうたっている文献があるでしょうか？ あくまで一般論ですが、構造化プログラミングなどと比べ、オブジェクト指向で製作した場合は、 初回の工期（特に設計の工期が）は長くなります。 優秀な設計であれば、２回目以降の再構築や、機能拡張の工期は短縮されます。 つまり、オブジェクト指向で製作するときは設計に十分な時間をかける必要がある、 ということだと思います。 Viewを製作していて、バックエンドのDBを気にしている時点で、 抽象化が不十分な気がします。 画面の役割は、あくまで表示に特化しており、必要なデータを 誰からもらえばいいかを知っていればいいのです。 入力されたデータを、どうやってDBに格納しようか、と考えるのは モデルがやるべき手続きをViewやってしまっている、ということでは ないでしょうか。
お礼
ご返信をありがとうございます。 オブジェクト指向で制作を行うかどうかにおきましては、作成をするシステムの予定期間や 内容などによってエンジニアが柔軟に判断をしていけば良いという事なのですね。 ただ、よほど時間をかけて細かく設計をして、はじめて、オブジェクト指向を使わない構造 化プログラミング並の再構築や、機能拡張の使いかってになるのは、本当にどうなのでしょう・・・。 プログラムは無から有を作り、抽象化を具体化して、より便利に進化、改良をしてい くものだと思っておりますので、出来るだけ柔軟に改良への対応ができましたり、一から再 構築をいたしましても、出来るだけイメージを、具体化しやすい作りを目指したいですね。
- taketan_mydns_jp
- ベストアンサー率58% (450/773)
釣りだと思いつつ、どちらかと言うと、小プログラムを組み立てる事の方が多い趣味プログラマですが。。。。 質問者さんのおっしゃる事にもとても共感出来ます。が、しっかりとデバッグされたコンポーネントを組み立て、アレンジが簡単、と言うところにクラスの良いところがあると思います。 PEAR DBは頻繁に使いますが、このおかげでDBを変えると言う事もかなり簡単に出来ます。 当然、最初からクラスを作り込むのは大変な作業です。しかし、いったん出来上がってしまえば細かいデバッグをする必要がなくなるわけです。 Ruby on Railsの開発の速さからの影響でPHPにもいくつかのフレームワークが出来てきています。CakePHPの10分で作るCakePHPアプリ for Windowsあたりはちょっと感動的です。 http://p4life.jp/cake/ これを見ると、ああ、やっぱりクラス使った方が良いかも、なんて気になります。 参考まで。
お礼
お返事をありがとうございます。（あまり釣りという気持ちはなかったのですが） ただ、ちょっとしたプログラムで実験的な感じなら、よいかもしれないのですけれども、 DBを使用いたしましたシステムでは、構想から改良までを考えますと、 大変な感じがしております。 特に、改良の段階では、クラスの再利用などを考えて、構想を考えますと、柔軟な改良 への構想が大変になってしまうと思っております。
- lv4u
- ベストアンサー率27% (1862/6715)
No.1さんと同感です。「クラスを使った」とか「継承した」だけでは、オブジェクト指向のメリットを全然生かしていることにならないでしょう。かえってクラスを使うことで面倒なコードが増えるし、継承することで、ひとまとまりの処理が複数クラスに分散して解りにくいコードになると思えます。（このデメリットを質問者さんは大いに享受しているのかも？） 個人的には、オブジェクト指向のメリットは「クラスの型を利用した複数のインスタンス作成」「ダイナミックバインディングによりCase文的な処理が不要になること」そして「ＳＴＬやテンプレートによるジェネリックプログラミング」（これはＣ＋＋以外では利用できないが）だと思っています。 つまり、こういった技法を使わないならば、「わあい、オブジェクト指向でバグが減ってコーディングもメンテも凄く楽になったよ！」という感激は無いんじゃないかと・・・。 そして、ＤＢを使ったＷｅｂシステムだと、あまり知識が無い人でも気楽に構築・メンテ・修正ができる作りのほうが重要でしょうし、そういう点ではオブジェクト指向は難易度が上がって不向き（工数増大）に思えてしまいます。 なんにしても、生半可な知識でオブジェクト指向を使うと、全然使わないシステムよりも、もっと解りにくいシステムになるでしょうね。
お礼
お返事をありがとうございます。 クラスを使用いたしましたオブジェクト指向でのプログラムは、構想設計や作成はもちろん、改良やデバックにも大変な手間と時間が かかってしまうと思います。
- dyna_1550
- ベストアンサー率34% (122/353)
オブジェクト指向を擁護するつもりはないのですが、オブジェクト指向は 設計方法論であるので、「クラスを使った」とか「継承した」という だけではオブジェクト指向設計とはいえません。 上記の文章を読むと、「よほどよく使う部分や、セキュリティ上必要なところを、include文などで」という部分は 設計ができていて（もしくは、パターン化されていて）コンポーネント化されそうな 部分だと思います。 UIの部分はどうしても個別の設計にならざるを得ないと思うのですが、 ビジネスプロセスが十分オブジェクト指向分析／設計されて いるのであれば、「変数をあちらこちらに飛ばす」ということも 少なくなるのではないでしょうか。
お礼
お返事をありがとうございます。 ただWEB DBシステムの作成におきまして、設計段階での構想が、オブ ジェクト指向の場合、実際のプログラムとの比較を考える時に、構想 がしずらくなりまして、結果的に時間もかかってしまうと思うのです。 設計の最初の段階でオブジェクト指向の変数の動きを考えると、目的の 設計構想のそのものが、大変になってしまうと思うのです。 構想と実務プログラムを、わけて考えますと、さらに大変になると思います ので・・・。
お礼
お返事をありがとうございます。 ただ、私はPHPの良いところの一つに、作成システムのイメージを他の言語に比べ まして比較的早くにWEB上に具体化できる所があると思っています。 そして、作成を致しましたシステムを、より使い勝手などを、よくいたします為の 修正も、かなり柔軟に行いやすく出来ます。 しかし、オブジェクト指向での作成では、想定内の修正ならともかく、その想定か ら少しでも外れた修正や、デバックが発生を致しましたときに、想像以上に時間が 掛かってしまいます。 問題は作成をする時の考え方によると思います。 想定をしていない仕様の変更や、追加等の修正を行うことを前提に作成を考えます 場合と、想定外の仕様の変更や追加等の修正やデバックなどは、その時になって考 えるので、まずは目的のシステムを、分担をして完成をさせるという事だと思います。 勿論、この二極端ではなく、前者に近い作成と、後者に近い作成、又はその中間もあ ると思います。 多分、どちらの方法で作成をすれば良いかは、その時々の判断で柔軟に考えていく事 にはなるのかもしれませんね。 私は、WEBシステムの作成におきましては、出来るだけ一つのページファイルにそのページ 上の処理を行うプログラムを入れた方が、修正などに対します柔軟性が増すと思ってい ます。 また、最初に述べましたように、複数人で、各ページファイルの動作プログラムの部分を お互いに担当していった方が、効率的で、またエンジニアもやりがいが出ると思っています。 ただ、エンジニアの現時点での技術力などを考えての分担には、なるとは思いますが、 それは、普通のオブジェクト指向での作成も同じだとは思います。