本当にオブジェクト指向プログラミングっていいのでしょうか？

質問

いつもお世話になっております。
VC++初心者です。

現在、VC++6.0、MFCのソース修正で四苦八苦しています。
（コーディングするよりも。ソースを追うので苦労してます。）
（初心者の私が言うのも難ですが、オブジェクト指向云々言う前に
　ソースのif文節が異常に長かったり、3重以上ループが出てくると
　とても嫌になります、、、）

一般的(?)に、プログラミングは
手続き型プログラミングよりオブジェクト指向プログラミングが
開発効率がよい、と重宝されているようですが、
どうも納得できていません。
（その手の書籍を2,3冊読みましたが消化不良に終わっています。）

個人的には、手続き型プログラミングの方が好きです。
というのも、慣れているからかもしれませんが、
ソースが追いやすいし、見やすいと思います。

逆にオブジェクト指向プログラミングでは、
・継承されすぎると、基本クラスまで追うのが一苦労。
・インスタンスをつくってから、関数を呼ぶのが面倒な気がする。
　（手続き型なら関数呼び出しのみで済みます。）
・インスタンスをdeleteし忘れて、メモリを圧迫する危険がある。
　（ガーベージコレクションというものもあるようですが、
　どこで何を消しているか不安です。）
・ソースを追いにくい（慣れの問題なのでしょうか、、、）

そこでですが、
「手続き型は～～で大変だけど、オブジェクト指向ならこんなにすばらしい」
というような対比的に具体例を挙げて説明されている
書籍、サイトの紹介、または、よい助言を頂けませんでしょうか。

また、上記に伴い、
・手続き型で組んで失敗した例（オブジェクト指向型にすれば良かった例）
・オブジェクト指向型で組んで失敗した例（手続き型にすれば良かった例）
も宜しければ教えて頂きたく、お願いします。
（成功例のみよりも、失敗からの成功例を教えて頂けると嬉しいです。）

長くなりましたが、宜しければご教授下さい。

回答No.10

bleis

またまた#1です。

* 多重継承について

多重継承については言及していないのですが・・・
とりあえず、多重継承について。
多重継承は、悪だとは言い切れません。
ただし、多重継承を語る上では、「機能(実装)の継承」と「型の継承」の区別ができている必要があります。
まずはこの2つの継承について理解する必要があります。

「実装の継承」とは、その名の通り、親クラスから子クラスへと実装を継承(コピー)することです。
この継承の形は、「差分プログラミング」とオブジェクト指向黎明期にはもてはやされましたが、
現在ではこの形での継承は積極的に利用するべきものではない、と言うのが一般的な認識です。

もう一方の「型の継承」は、イメージが掴みにくいかもしれません。
要は、共通のインターフェイスをくくり出すための仕組み、と言えばいいでしょうか。
「特徴」と言い換えてもいいかもしれません。
ここで言う型には実装が含まれないため、差分プログラミングにはなりません。
実装は子クラスで提供する必要が出てきます。

そして多重継承ですが、多重継承にも「実装の多重継承」と「型の多重継承」があります。
JavaやC#といった言語では、「型の多重継承」は可能ですが、「実装の多重継承」が禁止されています。
C++では、そもそも「実装の継承」も「型の継承」もシンタックス上の区別が希薄なため、どちらも可能となっています。

多重継承が即悪い設計、と言うわけではなく、「実装の継承」が悪い設計のサインとなっているため、
「実装の多重継承」も悪い設計のサインとなりますよね？
また、単一継承よりも多重継承の方が複雑であるため、「実装の多重継承」はより悪い設計である可能性が高いと言えます。

以上のことから、多重継承でも正しいOOPというのが成立する可能性があることはわかっていただけるかと思います。
ただし、そう言ったケースは稀な上、下手をすると簡単に悪い設計になってしまうため、
C++よりも新しい言語では(実装の)多重継承ができなくなっているものが多いのです。

また、多重継承の特殊な形として、Mix-inというものもあるのですが、それはまた別の話・・・

*OOPも非OOPでも面倒なのは同じなら、慣れている非OOPでもいいのかな、とも思ってしまいます

面倒、という観点から見ると、どちらも同じなのはわかっていただけたようで。
ただし、利点はそれだけではありません。
ポリモーフィズム(多態、ポリモフィズム)を使うことで、可変性(差違)をクラスに閉じ込めることができます。
詳しくは、オブジェクト指向のこころをどうぞ。

*クラス設計やクラス化という言葉について

ちょっと横道にそれて、クラス設計やクラス化という言葉について。
クラスベースのオブジェクト指向プログラミング言語なのだから、こういう言葉が出てくるのもある程度は仕方ないのですが・・・
少し、誤解を与える言葉だと考えています。
静的型付けのOOPLのほとんどの言語でinterfaceと言うものがありますよね？
C++には構文上はないですが、意味的には同じものを作ることができます(し、Javaを触ったことがあるようなので問題ないでしょう)。
本来ならば、こちら、interfaceを中心に考えるべきだと思うのです。
実際のクラスは、あとから出てくる(TDDで組むと、classからinterfaceをくくり出すため、逆ですが・・・それはまた別の話)。
ならば、クラス設計ではなく、インターフェイス設計と呼ぶか、せめてインターフェイス・クラス設計と呼ぶべきではないでしょうか。

クラス化についての違和感は更に強いものがあります。
(C++やJavaといった、静的型付けのクラスベースの)オブジェクト指向プログラミングでは、
複数のインターフェイス、複数のクラスが組み合わさって意味のある単位となっていることが普通です。
1つのクラスで完結するものの方が稀です。
ですが、クラス化という表現は、あくまで何らかのモノを1つのクラスへと落とし込むような、そんなニュアンスが感じられてしまうのです。

ちょっと結局何が言いたかったのか分かりにくくなっているような気もするのですが・・・
また、何かあれば書いていただければ反応します。

お礼

ご回答、ありがとうございます。
（本当に、返信遅くてすみません）

多重継承の件、分かりました。
（といっても70～80%くらいですが、、、
　あとは実践で理解していけると思います。）
初心者の私としては、多重継承しないように
コーディングしていきます。

>クラス設計ではなく、インターフェイス設計と呼ぶか、
>せめてインターフェイス・クラス設計と呼ぶべきではないでしょうか。
あぁ、なるほど、と思いました。
OOPが理解できないないので、インターフェイスの役割も正確に
理解はしておりませんが、簡単に対象(?)、機能(?)を切り替えられる
というふうに認識しております。
そうすると、
・インターフェイスにくっつくクラスはどれか？
・そのクラス達に共通するものはないか？
・共通したものを基本クラスとする
という思考で設計していけば、OOP設計に近づくことが出来るの
でしょうか。

もし、私の認識が間違っているようならば、ご指摘いただけると幸いです。