オブジェクト指向プログラミング

質問

一般に、オブジェクト指向プログラミングといわれているプログラミングに関してですが、
「関数・手続きを使用するプログラミング」と
「クラスを作成してプログラミング」というのは
おおきな違いがあるのでしょうか？
（クラスを作成しなくても関数・手続きで、プログラミングすれば
一緒じゃないかなぁと思っていますので・・・。）
どなたか、これに関して、お返事をして頂けたら今後いろいろな面でかなり助かります。

回答No.1

Mizyu · ベストアンサー

オブジェクト指向というのは簡単に説明するとデータ定義と処理を一体化させたオブジェクトを作成し、
そのオブジェクトを組み合わせることによってひとつのプログラムを作り上げるものです。

通常の手続き型言語との大きな違いは大規模なプロジェクトを行う際、
作業の分担が楽であること、保守運用時に一部の機能を置き換えるだけで全機能に反映すること
UMLによる設計によって仕様が把握しやすいことなど利点があげられます。
また、同様の機能で別プログラムを組む際にもオブジェクトの再利用ができて
後々の工数削減に役立ちます。

また、弱点としては、同じオブジェクトを多数再利用しているため、
若干な改修が入った場合に影響範囲が大きくなること、
基本的にプログラム単体では動作しないため、処理が重くなることなどがあげられます。

おっしゃる通り、Javaや.Netなどを用いて手続き型風なコーディングを行った際はほとんど差異は見受けられません。
私の私見になってしまいますが、現在「Java」や「.Net」の利点をフルに活かしているのは本当に一部で、
ほとんどの企業は「新しいもの」のネームバリューに飛びついて、従来の言語となんら変わりの無い開発をしているという
イメージはあります。

お礼

ご回答ありがとうございます。
ずうずうしくて申し訳ございませんが、回答に対して、一つご質問があります。
Mizyuさんは、「大規模なプロジェクトを行う際」のことで述べられていましたが、
小規模なプロジェクトを行う際は、あまりメリットがない(逆にデメリットも少なくなる)と、考えてもよろしいでしょうか？
（うちの会社は、そんなにも大きいプロジェクトがあるわけではないので・・・。）

回答No.5

KENZOU

専門家や経験者に混じって素人の私がアドバイスするのもなんなのですが、昔、DELPHIで趣味のプログラミングをしていたとき、
＞「関数・手続きを使用するプログラミング」と
「クラスを作成してプログラミング」というのは
おおきな違いがあるのでしょうか？
と同じ疑問をもったことがありました。この疑問は、塚越一雄 (著)「ゲーム&&オブジェクト指向プログラミング」の本を読んで氷解しました。構造化プログラミングとＯＯＰの違い等、非常にわかりやすく書かれていたと思います。ご参考まで。

参考URL：

http://www.amazon.co.jp/exec/obidos/ASIN/4874085644/qid=1086773481/sr=1-29/ref=sr_1_0_29/250-9809596-2207418

お礼

ご回答ありがとうございます。
（ゲーム好きなので、）ぜひ一読してみたいですね。
会社で買うことができれば、買ってみたいと思います。

回答No.4

Mizyu

#1です。

> 小規模なプロジェクトを行う際は、あまりメリットがない(逆にデメリットも少なくなる)と、考えてもよろしいでしょうか？
小規模でもメリットはあります。
例えば、作成されるプログラムのバージョンアップ、カスタムバージョンなどが作られる場合、
部品（Object）の再利用をすることによって工数削減に繋がります。
また、UMLを用いた仕様書、設計書とコードレベルまで同価値で見ることができるため、
保守効率も高いです。
これらは大規模なプロジェクトほど効果は大きくなりますが、小規模プロジェクトでもそれなりの効果が見込めます。

また、デメリットもありますね。
本格的にオブジェクト指向を取り入れてメリットを全面的に出そうとすると
コンセプト設定や詳細設計にかなりの工数がかかってしまいます。
小規模の場合、ここで取られてしまう工数が痛手となり、長い目で見たとき
オブジェクト指向を取り入れない方がコストがかからないケースがあることは事実です。

お礼

お返事ありがとうございます。
総合的に考えて、オブジェクト指向を取り入れるのか
入れないのかを決めた方がよさそうですね。

回答No.3

yoneda_16

オブジェクト指向プログラミングは必ずしもクラス指向ではないのですが、それはさておき。

関数や手続きでプログラミングできていて、それで不自由しないのであれば、必ずしもオブジェクト指向を採用する必要はないのではありませんか。

個人的には、規模が大きかったり、概念が複雑だったりという理由から、関数や手続きに直接分解することが困難なプログラミングをうまく整理する手法の一つがオブジェクト指向だと考えています。

手続き指向でプログラミングする際には頭の中で無意識に行われている、現実世界の事象を手続きに翻訳する作業を、クラスとオブジェクトという図式を利用して明示的に翻訳し整理しましょう…ということでしょう。

オブジェクト指向プログラミングでも、結局は手続きを書く必要はあるわけですしね。

ちなみに、下記は私がもっとも気に入ったオブジェクト指向の本です。もう絶版なのですが、幸い作者の手で全文がインターネット上で公開されています。お暇な時にどうぞ。

参考URL：

http://www.sra.co.jp/people/aoki/IntroductionToOOAOOD/index.htm

お礼

ご回答ありがとうございます。
読むのにすごい量・・・、時間がかかりそう(第一印象です)。
せっかく教えて頂きましたので、時間があるときに、
ゆっくりみていきたいと思います。

回答No.2

popesyu

そんな肩をはって考えなくてもこんなもんだという理解で十分だと思いますよ。まぁ資格をとったりとか目的がそちらの方なら厳密に語句を切り分ける必要があると思いますが。

昔からプログラマの頭の中ではオブジェクト志向でプログラムは書かれていました。
ただそれは従来の言語上ではそれが表現できなかったので、関数名を工夫するとか、ドキュメントに示すとかしていただけのことで、オブジェクト指向と呼ばれる言語はそれがプログラムの中で定義できるようになったというだけのこと。
きれいにまとめられた関数・手続きはクラスと何ら変わりはありません。ただし殆どの場合、最初はきれいでもじょじょに約束事が崩れだしていってｗ　結局非効率的になってしまうのですが。クラスの場合は、言語の中で表現しているので約束違反が発生しにくくなっている訳です。

会社で例えれば、
営業部一つだけで、経理から企画から何から何まで業務を処理していくことも可能です。例えば書類一つの管理にしてもこれは経理用の書類ということで、書式のルールやら管理方法も徹底しておけばそれで混乱も少なくなる訳で。特に小さい会社であれば、無理に部署を分けてもおそらくメリットは殆どないでしょう。
ただやはり規模が大きい会社を考えた場合、最初から営業部・経理部・企画部で分けて管理させた方が効率的だし楽だよねというだけの話なのです。

お礼

ご回答ありがとうございます。
なるほど・・・、「クラスを作成してプログラミング」の登場によって、
違った表現でソースが書けるようになった
(これによりソースの見栄えがよくなった？)
という風にとらえてよろしい訳ですね。