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

質問

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

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

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

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

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

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

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

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

回答No.16

shu-tec

オブジェクト指向を学ぶ上で引っかかりそうな謎などについて、ちらほら書いてみました。
質問者さんもいい加減食傷気味だろうなとは思いつつ、結局長文になってしまいました。
申し訳ありませんが、参考になれば幸いです。

■「オブジェクト指向」の説明が収束しないわけ
一口にオブジェクト指向といっても、いくつか流派があります。
この辺、以下のサイトが参考になります。
オブジェクト指向の概念の発明者は誰ですか？
http://d.hatena.ne.jp/sumim/20040525/p1

このサイトを参考にしつつ至った私の結論では、オブジェクト指向の流派は大雑把にC++派、SmallTalk派、JavaScript派の３つに分かれます。
C++派代表はもちろんC++、SmallTalk派では、Macプログラミング界でメジャーなObjective Cがあります。
Javaは、C++をベースにしつつ、ちょっとSmallTalk側に傾いた印象で、C#も基本はJavaを踏襲しています。
JavaScript派はかなり特異なので、あまり混乱することはないと思いますが、C#2.0は若干JavaScriptっぽくなったというウワサです。
参考：
http://www.atmarkit.co.jp/fdotnet/csharp20/csharp20_01/csharp20_01_01.html

それぞれの流派では、中心に据える概念が違います。
C++派ではオブジェクトが中心ですが、SmallTalk派ではオブジェクト間の通信である「メッセージ」が中心です。
また、使う言葉も結構違います。（フィールドとかメソッドとかいうのは、主にSmallTalk流。仮想関数とかメンバとかはC++流）

このため、どの流派に軸足を置くかで、オブジェクト指向の説明（というか解釈）がまず大きく変わります。
さらに、多くの人は、それぞれの流派の概念を混ぜ合わせたり、いいとこ取りをしたり、経験的に有効な手法を組み合わせて身につけていたりするので、その配合割合によっても解釈が変わり得ます。
さらにさらに、ちゃんと理解できてなさそうな著者が書いたような書籍も世に溢れています。
そんな本を読んで、それすらちゃんと理解できないままに、分かったつもりになっている人も大勢います。
カオスもここに極まれり、です。

■本の読み方
そんなわけなので、書籍で学ぶ上での勧めの指針をいくつか。

１．できればC++で説明している本を選ぶ。
最初の頃は、複数の用語が出てくると混乱の元だと思います。
C++で説明している本に絞れば、用語がかなり統一されますので、混乱が減るのではと思います。
また、Javaのオブジェクト指向は比較的C++に近いので、それでもいいかもしれません。
Objective CとかSmallTalkの本は、「自分の中のオブジェクト指向像」が出来ていない間はお勧めしません。
この段階では、とりあえず「メッセージ」を強調した本は避けておくのが吉だと思います。

２．オブジェクト指向に限定せずに読む。
やや回り道ながら個人的にお勧めの方法は、C++設計技法を紹介した本の乱読です。
その中には、オブジェクト指向を生かしたテクニックもあるし、C++特有のものもあるし、Ｃ時代から変わらないテクニックも、時代の先端を行き過ぎた変態テクニックもあります。
そんなのをたくさん読んでいくうちに、「あ、こーいうのがC++によるプログラムの組み方なのかなー」と分かってくると思います。
そんな中で、C++によるオブジェクト指向というのも見えてくると思います。
それがおぼろげに見えた段階でオブジェクト指向の良書を読むと、目からうろこがぽろぽろと、面白いほどよく落ちるでしょう。

３．たくさん読む。
「オブジェクト指向」の解釈は無数にあるので、どれが正しいかは自分の目で見極める必要があります。
そのためには、いろんな解釈をみて、それぞれの利点、欠点、矛盾点などを、自分の経験に照らして考えなければなりません。

４．最後に、いろんなオブジェクト指向の本を読む。
Javaの本とか、Objective Cの本とか、SmallTalkの本とか、C++ではない本を読むと、オブジェクト指向の世界が広がります。
中には、C++の主張と全く逆の主張もあったりして、「結局どっちが正しいの？」と言いたくなる事もあります。
結局どっちが正しいのかは自分で考えて判断するしかなく、そのためにはある程度「自分で考える基盤」が必要なので、これはある程度オブジェクト指向が分かってきてからのほうがいいでしょう。

■お勧めの書籍
○Effective C++ (Scott Meyers)
　C++設計技法の決定版。これを読まずしてC++は語れない！
○C++ Coding Standards (Herb Sutter, Andrei Alexandrescu)
　Effective C++並に使える本です。
○C++プログラミングの処方箋 (Stepehn C. Dewhurst)
　内容はそこそこ高度ですが、読みにくくはありません。
　オブジェクト指向に関するトピックがわりと多いです。
○デザインパターンとともに学ぶオブジェクト指向のこころ
　(アラン・シャロウェイ, ジェームズ・Ｒ・トロット)
　私の目からうろこを落とした本です。
　ある程度「オブジェクト指向」のイメージができてから読むといいかもしれません。
・Effective STL (Scott Meyers)
　Effective C++と同じ作者による、STL（C++標準ライブラリの一部）を使用する上でのガイドライン。
　ちなみにSTLは非常に有用なクラスライブラリですが、オブジェクト指向ではありません。
・More Effective C++ (Scott Meyers)
　Effective ３部作でもっとも内容が高度な上、奇妙な翻訳も多い。
　内容はいいのですが、読みにくさはピカイチです。
・Exceptional C++ (Harb Sutter）
　C++やオブジェクト指向の設計について、クイズ形式で問題点と解決法を紹介。
　Effective C++よりやや上級？
・Modern C++ Design (Andrei Alexandrescu)
　「いい言葉に力を与えるには悪い言葉も知らなきゃいけないって、でも決して使うなって。」
　そんなバルスな感じの変態テクニックが満載です。
・オブジェクト指向における再利用のためのデザインパターン
　(Erich Gamma, Ralph Johnson, Richard Helm, John Vlissides)
　通称GoF本。その偉大さはGoogle先生に聞いてみてください。
・リファクタリング (Martin Fowler)
　通称リファクタ本。オブジェクト指向に関する名著の一つです。
・パターン指向リファクタリング入門 (ジョシュア・ケリーエブスキー)
　GoF本、リファクタ本と合わせて３部作なイメージです。セットでどうぞ。

○をつけたのが特にお勧め、・をつけたのは、その後で読んでみるといいかもです。
アジャイル関連の本は、SmallTalkの息がかかっていることが多いように思うので、最初のうちはあまりお勧めしません。
もちろん、わかって読めば非常に有用ですが、オブジェクト指向の初学者には混乱を招く要素が多い気がします。
なお、『C++プログラミングの処方箋』の「全宇宙的なクラス階層」という項目では、他のオブジェクト指向言語では常識である「Objectクラスを頂点とするクラス階層」を完全否定しています。
こういう矛盾に気付いて行き詰まったら、とりあえず深く考えずに次へ進むことをお勧めします。
その後数冊読んだ後で再び読み返してみると、すんなり分かるってことも多いものです。
ちなみに、全宇宙的なクラス階層に関する見解の相違については、C++がオブジェクト指向【専用】言語ではないと分かれば納得できます。

■お勧めできない書籍
『憂鬱なプログラマのためのオブジェクト指向開発講座』
通称憂鬱本。ツッコミどころ満載です。逆にお勧めです！
ただ、悪書も悪書で読んでみてもいいかもしれません。
良書or悪書と人が言ったから、というのではなく、自分で判断できるようになるために、清濁併せ呑み皿まで食らって、自分の頭で考える、というのが、迂遠ながらもやっぱり通るべき道かな、と思います。

■手続き型は大変だけど、オブジェクト指向はすばらしい例
オブジェクト指向の本では、たまにこういう比較をしているものがありますが、その手の本には正直眉をひそめたくなるものが多いです。
よくあるのは、非オブジェクト指向の設計を極端に貶めている例。そして、オブジェクト指向を過度に賛美している例。
とりあえず憂鬱本の作者はＣ言語に謝れと言いたい。
多分、これらを平等に比較するのはかなり難しいんだと思います。
『オブジェクト指向のこころ』では、（あくまで主観ですが）あまり不自然でない形で機能分割、従来のオブジェクト指向、正しいオブジェクト指向の３つの設計を比較しています。

■そもそもオブジェクト指向の利点とは？
私の理解では、オブジェクト指向というのは「変更に強いプログラムの作り方」です。
だから、オブジェクト指向設計が成功したかどうかは、実際に仕様変更の波に晒してみないと分かりません。
オブジェクト指向では、「変更がなさそうな部分」と「変更がありそうな部分」を分析し、変更がありそうな部分に対して、ありうる変更を施しやすいように設計します。その読みが外れていれば、いかにオブジェクト指向で作ろうが、ダメ設計になります。
しかし、上手く設計すれば、機能分割による設計よりも変更箇所を局所化できます。
つまり、出来上がったプログラムに対して仕様変更要求が発生したときに、オブジェクト指向は真価を発揮します。
言い換えれば、仕様変更がないものや、変更するより作り直したほうが早いような小さなプログラムでは、特に利点はありません。

なお、オブジェクト指向に限らず「複雑な設計を整理して、単純化するための仕組み」というのは、それ自体も若干複雑なものです。
それによって増える複雑さよりも、単純化による効能の方が大きい場合に、それは価値を発揮します。
逆に、元々が非常に単純な設計であれば、「複雑さを緩和する仕組み」そのものの複雑さが単に加わることになります。
小さなプログラムで逆に面倒に感じるのは、そういう問題もあるのかもしれません。

■多重継承について
実装を含む多重継承の好例は、C++標準ライブラリのstd::iostreamクラスです。
このクラスの設計に対する不満はあまり聞かないので、よい例に数えられているのだと思います。
（標準ライブラリの中にも「悪い設計」と評判のものがいくつかあるので要注意です！）
ただし、このような多重継承を【正しく】使うには、仮想継承や基底クラスメンバのusing、仮想基底クラスの初期化に関する制約、オブジェクトのメモリレイアウト、static_castやdynamic_castが裏でやっていることこと、等々、相当マニアックな事柄を完全に把握しなければなりません。
さらに、多重継承を【効果的に】使うには、多重継承による効果とそれがもたらす決して小さくない制約を比較して、それが一番いいと判断できる、非常に高い設計能力が必要です。
普通人には無理、ということでファイナルアンサーにしていいと思います。

ちなみに、実装を含まないクラスであれば、多重継承してもあまり問題を引き起こさないということがわかっています。
実装を含まないクラスとは、メンバ変数を持たず、メンバ関数の実装も持たない、つまり純粋仮想関数のみから成るクラスです。
JavaやC#ではそういうクラスを明確に区別するために、実装を含まないクラスを「interface」と名付け、「class」は実装を含むクラスだけを指すようにしました。
そして、classは一つしか継承したらダメけど、interfaceはいくつ継承（というか実装）してもいい、というルールにしたのです。
C++の自由かつ危険な部分にフタをして、安全設計にしているわけですね。

■インターフェイスとクラスの設計
＞・インターフェイスにくっつくクラスはどれか？
＞・そのクラス達に共通するものはないか？
＞・共通したものを基本クラスとする
＞という思考で設計していけば、OOP設計に近づくことが出来るのでしょうか。

その中で、「インターフェイス」を設計するところに一番重点を置くと、OOP設計に近づきそうな気がします。
それ以外の、インターフェイスにくっつくクラスを作ったり、共通部分を基本クラスにまとめたりするのは、あくまでインターフェイスの後ろでコソコソやればいい「実装」に過ぎません。
主役はインターフェイスです。

・【それ】は何ができるべきか？　どんな情報を持つべきか？
・【それ】の機能や情報に、他のオブジェクトからどうやってアクセスするか？
・【それ】が持つ機能や特徴へのアクセス手段を、インターフェイスとしてまとめる。
・機能を実現し、特徴を保持するための実装を考える。

という思考の方が、よりＯＯＰに近いと思います。

＞簡単に対象、機能を切り替えられる
ようにするには、インターフェイスを「実装を持たないクラス」として作成し、実装はすべてその派生クラスに置くようにします。
クラスを使うときは、インターフェイスとなっている「実装を持たないクラス」だけにアクセスし、派生クラスは存在しないものとして扱います。
異なる実装を持つ新しい派生クラスを作って、もとの実装と入れ替えれば、クラスを使う側は一切変更しないままに「簡単に機能を切り替えられる」わけです。

ところで、「共通したものを基本クラスとする」というのは、#1さんが言う「実装の継承」なので、「悪い設計のサイン」に当たりそうです。
基本クラスにまとめるのではなく、別クラスにまとめてそれをメンバ変数として保持するというのが、一般に継承を使うよりもいい方法だといわれています。
class Base {};
class Class1 : public Base {};
class Class2 : public Base {};
ではなく、
class Common {};
class Class1 { private: Common m_common; };
class Class2 { private: Common m_common; };
とするわけです。
こうしたほうがいい理由は、『Effective C++』に詳しく書いてあります。

参考URL：

http://d.hatena.ne.jp/sumim/20040525/p1