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

質問

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

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

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

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

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

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

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

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

回答No.15

bleis

#1 です。

> OOPを理解していると自負されている方は数多くいらっしゃることは
> 言うまでもなく、OOPについて説明している書籍はかなりあります。
> しかしながら、説明するキーワードは共通していても、
> 説明内容が各々で発散しすぎていると感じております。

これは仰るとおりです。
用語の揺れとしては、手前味噌ですが
http://d.hatena.ne.jp/bleis-tift/20090201/1233426011
の他にも、オブジェクト・クラス・インスタンスという用語にも人によって揺れがあります。

> （あくまで私の見解なのですが、もし、OOPを理解している人達が、
> ある同じ問題を各々でOOPでコーデングするれば、
> 限りなく一意に近いソースコードに成ると思いますが、
> どうなのでしょうか。
> なるのであれば、なぜ説明が収束しないのか不思議です。）

これはそれなりの規模で実験しないと分からないのですが、
似たようなグループはできるかもしれませんが、全てが同じようなものになることはないはずです。
なんというか、流派とでも言えばいいんでしょうか・・・
もしかすると、似たようなグループさえできず、
ちょっとずつ異なるものの連続になるかもしれませんが・・・

> コーディングする前に、必ずUMLで
> シーケンス図やクラス図を書いておりました。

スケッチとしての UML はいいのですが、
「UML を書く」という工程を入れてしまうのはどうかと思います。
これは、ER 図などにもいえることなのですが、
何らかの図を用いて設計するのではなく、思考を可視化してまとめる、または共通認識を得るために図に起こすのです。
ここを取り違えると、UML を書くことが設計だと勘違いしてしまいます。
なので UML が正しいかどうか、というのは実は全く問題ではありません。

少し厳しいことを言いますが、手続き型の方が考えやすい、と言うのは、
手続き型では「ただなんとなく」コーディングしてきただけなのではないでしょうか？
今まで行ってきた「手続き型言語での開発における設計」は、完全無欠に正しいものだったのですか？

> 初心者の私としては、多重継承しないように
> コーディングしていきます。

ある意味正しい方針、正しい制約かもしれません。
場数を踏む内にどういうことか分かってくると思いますし。

> インターフェイスの役割

これまた説明するのは難しいのですが、一言でいえば、
「何らかの抽象的側面を表すもの」
でしょうか。何言ってんだ、って感じですね(汗

簡単に実装を切り替えられるというのは、あくまでインターフェイスの特徴であって、役割ではありません。
・・・まぁあるコンテキストにおいて、ある interface が実装を切り替えることを目的としていることはあったりすのですが・・・
その場合でも切り替える実装の間には何らかの共通する抽象的側面があるはずです。

で、OOP のための設計の思考ですが・・・
あながち、間違いとは言い切れません。
共通性・可変性分析の、共通性のみに着目した考え方と言えるのではないでしょうか。
ですが、やはり可変性にも視点を向ける必要があると思います。

以下 #8 の人へ

クラス設計ですが、表現としては普通に使われてはいるのです。
ただ、その用語は本当に言いたいことを表しているの？と、個人的に疑問を持っているだけで・・・

で、ちょっと関係ないですが本について。
「Java デザインパターン徹底攻略」は自分も持っていたのですが、
問題も多かったように記憶しています。
もう手元にないのでどこに問題があったかは詳しく覚えていませんが、
一つ覚えているのが、マルチスレッドに対応した Singleton の項で、double checked locking イディオムを使用していたことです。
たしか 6 だか 5 だかで double checked locking イディオムが使えるように VM に変更が加えられたはずですが、
この本は確か 1.3 とか 1.4 時代に書かれています。
他にもいくつか問題があったように記憶していますので、あまり真に受けるべき本ではないかと・・・
Java に限定するなら、結城浩さんの「増補改訂版 Java 言語で学ぶデザインパターン入門」という本がおすすめです。
ただし、この本も 1.4 時代の本なので、ジェネリクスとか使ってないのがアレですが・・・

また、「デザインパターンとともに学ぶオブジェクト指向のこころ」、「アジャイルソフトウェア開発の奥義」という本もおすすめです。
これらの本を読んだ後、「パターン指向リファクタリング入門」という書籍もおすすめです。

次に、オブジェクト指向の 3 つの特徴について。
カプセル化、継承、ポリモーフィズムというのはよく言われることなのですが、
あくまでこれは「クラスベースのの OOPL」の特徴と言うべきものです。
メッセージパッシングに重きを置いた OOPL や、そこから派生したプロトタイプベースの OOPL には当てはまりません。
また、質問者さんへの回答でも述べたとおり、カプセル化という言葉は揺れが大きすぎ、
カプセル化と書いただけでは何も言っていないのとほとんど等しいというのが現状です。

最後ですが、回答中に挙げているサイトについて。
「デザインパターンを読み解く」については、Facade は Wrapper でもあるんじゃ？とか、いくつか「？」が付くだけですが、
「オブジェクト指向」は言いたいことがいくつもあります。

全部は挙げませんが、
open(door);
と
door.open();
という「書き方」を取り上げて、前者が手続き的で後者がオブジェクト指向的だという説明は間違っています。
対象を明示すると言う意味で door.open() の方が分かりやすい、という説明ならいいのですが、
それでも open(door) が手続き的かどうかは、open の実装によりますし、door.open() だったらオブジェクト指向的か、
と言われると、「それは違う」と答えます。
コンテキストを無視したコード片では、手続き的かオブジェクト指向的かという判断はできないと考えています。
書き方、形式の違いを例に出すのは、間違った OOP への第一歩です。OOP はそこまでミクロな視点のものではない。

メソッドの分類では、モジュールと言う考え方を無視しているため、違和感があります。
クラスの導入へのステップに飛躍がありすぎる、と言いましょうか・・・
また、クラスは「データにメソッドを付属させたもの」ではありませんし、
「メソッドの集まりに状態を保持させたもの」でもありません。
それはあくまで実装の話であって、それが直接メリットになるわけではないのです。
で、カプセル化については・・・もういいですね。

オブジェクト指向の 3 原則・・・ももういいですね。

それ以降は長くなるので省きますが、「機能とデータを併せ持ったモノ」という考え方では、よい設計は生まれません。
クラスをそのように取り違えているこの文書もまた、あまり参考にすべきではないかもしれません。

まぁそれを言ったら、この意見も「クラスは機能とデータを併せ持ったモノだ」という意見をもつ人から見れば、
あまり参考にすべきではないものでしょう。
要は「何を正しいとするか」なのでしょうけど、「クラス = データ + 手続き」という考え方からはよい設計が生まれないと言うことを
「デザインパターンとともに学ぶオブジェクト指向のこころ」により知ってしまったので、
自分の考え方はこの本が「基礎」になっています。