オブジェクト指向の本当の便利な点。

オブジェクト指向の特徴は、ある程度分かりました。
が、個人で小さなソフトを作り、できるだけ自分でプログラムを作りたいため、オブジェクト指向の利点が今ひとつ分かりません。
ＰＨＰでは、構造化でできるだけグローバル変数を減らし、関数内でも関数名＋変数名という変数名にしていたので、変数の名前が重複すると言ったこともなかったし。
関数名＋でない場合も、関数内では不必要な変数は値を解放していたし。
過去の資産も関数を再利用する事もよくありましたし、継承のような事もしていました。
オブジェクト指向の便利さは分かるのですが、どうも実感できないというか、その便利さを持て余しているというか。
構造化プログラミングでも、さほど問題ないし。
delphiなので、JAVAのようにオブジェクト指向(クラス)が必須という訳でもないし。
逆にクラスを作ってしまうと、メモリーから解放しないといけないので、それが少し怖いです。

で、オブジェクト指向の利点をあげるとしたら何ですか？
可能なら、上位から３つくらいを詳しく書いてください。

ソフトは大規模か小規模か、制作者は大勢か少数・個人か、それは構造化プログラミングでは無理な事なのか？
オブジェクト指向の利点や特徴は、分かるのですがピンとこないというか、実感できないというか・・・。

No.8 ベストアンサー 回答者： galluda 回答日時： 2006/08/29 11:57

がるです。

> マルチプルインスタンスは、ようはクラスというカプセルにいろいろなデータを入れるということですよね。
む、ごめんなさい。ちょっと説明が足りなかったかな。
おっしゃっている中ですと「シュミレーションのような個の情報をもち、多くの同じカプセルで別のデータが存在する場合」がそれに近いと思うのですが。
物凄く大雑把に言うと「インスタンスの配列」です。
まぁ構造化的には「データ格納用の構造体」作って「その構造体のポインタぶん回してあちこちの関数」callすれば概ね実装可能なのですが。
ここに「似たような、だけど違う、継承クラスの配列」を実現したいなぁとか思ったりすると、とたんに難易度があがります。というのも、継承によって「同一関数名(正しくはメソッド名)だけど処理内容を変える」事ができるので、構造化系だと、最低限「ifでその型を確認して…」っていう手間が増えてしまうので。

カプセル化は、変数名の衝突というよりは「隠蔽」に重きがあると、個人的には考えております。つまり「いらんものは隠す ＆ 触らせない」と。

保守は………実際にやってみないと、だと思います(苦笑
実際、クラスの切り方まちがえれば、やってても体感できないものなので。まぁ言い換えると「保守がしんどいならそれはクラス切り間違えてる」のですが。

オブジェクトは…多分「よい現場に行く」のが一番よいのだろうと思うのですが。
…ちょいと以前にかいた、オブジェクト指向の実用講座があるのですが(コンセプトは「美しい理論背景はこの際棚の奥のほうに鎮座していただいて、現場からの本音を中心に「どこが便利なの？」ってあたりから、オブジェクト指向を少し切り込んでみたい」って感じです)。
ここの規約に引っかかるので、URLとかが記述できなくて(苦笑
もしどこかで偶然にでも見つけられましたら、ご覧いただければ、と思います。

あと。継承の話ですと…私の講座だと、買い物籠を例題に出してますね。まぁ、マルチプルインスタンスもここで使うのですが。
とりあえず大雑把に
商品クラス {
メソッド：
get(商品ID); // どこかから１商品のデータを一通り取ってくる

// 以下、ゲッター
get_商品ID();
　get_商品名();
　get_商品値段();

変数：
　商品ID_;
　商品名_;
　商品値段_;
}
って作ってみます。で、これは「商品１つ」をあらわすだけなので、ユーザさんの籠を作りまして。
かごクラス {
メソッド：
　// セッター
　set_ユーザID(ユーザID);
　push_商品オブジェクト(商品オブジェクト, 数量);

// ゲッター
　get_商品IDのList();
　get_商品オブジェクト(商品ID);
　get_商品数(商品ID);

// 削除系
　del_商品(商品ID); // 単品の削除
　init(); // かご全体の初期化(全品削除)

変数：
　ユーザID_;
　商品オブジェクト配列_;
　商品数配列_;
}
最後に、キャッシャーを作ってみたりするのですが。
キャッシャークラス {
メソッド：
　// セッター
　set(かごオブジェクト);

// ゲッター
get_合計金額();

変数：
　かごオブジェクト_;
}
たとえば。ここまで作って、或いは上述が基本コンポーネントなのに、ある我侭なユーザから「ねぇねぇ。商品に画像と説明をつけたいんだけど」とか言われてしまったときに。
OOPの手法を使うと、
商品クラス改 継承 商品クラス {
メソッド：
// 以下、ゲッター
　get_商品画像Path();
　get_商品説明();

変数：
　商品画像Path_;
　商品説明_;
}
と書くだけで、「商品クラスの全部を享受しぃつつ」画像系の情報が追加できます。
この辺の「楽に変更できる」のが、一つのメリットなのかなぁ、と。

以上、なにかの参考にでもなれば幸いです。

この回答へのお礼

＞「似たような、だけど違う、継承クラスの配列」
というのは、分かっていたつもりです。
・・・が、ピンとこなくって。

買い物籠の話も・・・分かるんですが、分かるんですが、何か分かっているのか、ピンときていないのか・・・。＾＾；
継承も、いろいろなラッピングでくるむことで、似ているけど違うものができるというのは、、、分かるんですが。
やはり、長いプログラムを書いていないことが、それぞれカスタマイズすればいいじゃん。という甘い考えになっているのかもしれません。＾＾；

お礼日時：2006/08/31 14:50

No.9 回答者： dekopa- 回答日時： 2006/08/29 21:13

＞個人で小さなソフトを作り、できるだけ自分でプログラムを作りたい

こういう場合恩恵は少ないです。特にC/Pascal系の型指向の強い、構造化＋OOPなハイブリッド言語では特に。
「メソッド呼び出し」ではなく「メッセージ送信」の便利さを実感するには、型が動的なSmalltalkやrubyを使ってみるしかないです。これは、言葉では今ひとつ便利さを説明しきれません。
#型から開放されると、物凄くコードがコンパクトになるのが実感できます。

設計をとばして、Delphiでの利点、つまりOOPレベルの利点を探っても、今更な話です。VCLが使える、それ以上の利点があるでしょうか？
プログラミングする上でのオブジェクト指向言語の利点は、既存のライブラリの拡張が構造化手法に比べて容易な事です。（これは経験として、すでに理解されていると思います）

カプセル化によって、影響範囲を限定しやすい。
継承によって（あるいは委譲によって）追加しなければいけないコード量が少なくてすむ。
といったあたりが、OOPの利点ではないでしょうか。

>構造化プログラミングでも、さほど問題ない
なら、無理にオブジェクト指向を使う必要はありません。所詮、適材適所です。

この回答へのお礼

実際、３つ小さなソフトを作りましたが、構造化でとくに問題ありません。
オブジェクト指向を勉強しようと思ったのは、その方が便利そう、と言うだけなので、短いプログラムではメリットはそれほどない、と言うのならしばらくは構造化のまま進もうかと思います。
時間があるときは、時々また勉強しようかとも思います。
いずれはVCLも使ってみたいですし。
ありがとうございます。

お礼日時：2006/08/31 14:55

No.7 回答者： elmclose 回答日時： 2006/08/29 06:52

#5(=#1)です。

>インスタンス化させたら、その都度解放しないとダメなの？
動的に割当てたメモリを都度解放するか終了時にまとめて解放するかというのは、オブジェクト指向とするか非オブジェクト指向とするかということとは独立のことですよね。もし、都度解放するとして、オブジェクト指向言語で書くならば、#5で書いたように行なう方法があるという意味で書きました。
なお、都度メモリを解放するからプログラムが「汚く」なるというわけではないと思います。都度解放するという設計方針の下、いかに綺麗に書くかを考えればよいかと。
また、インスタンスに必要なメモリの管理を処理系側で行なう場合もあり（そっちのほうが多いかも）、その場合にはユーザコードで明示的に解放を行なう必要はありません。


>線を引くクラスを作り、色を付けるクラスで継承させるのと。
>線を引くサブルーチンを作り、色の変数を渡すのとで、なにが違うのか？と。
その範囲においては、どちらの方法でも同じ結果が得られます。
例えば、「線」というクラスと「色つきの線」というサブクラスがあったときに、それら両クラスのコードに全く手を入れることなく、かつ既存のクラスを利用して、「矢印つきの線」という新たなクラスを書くことが、オブジェクト指向では可能です。

この回答へのお礼

＞非オブジェクト指向とするかということとは独立
ですが、delphiはインスタンスを作ると解放、サブルーチン（関数）ならそうしなくてもいいようなので。
＞汚いと
と感じるのは、とりあえず私は不必要なものは書きたくないです。
ポーモフィズムも不必要そうなものなら、書きたくない。
これを安全ととるか、不必要ととるかはその人の美的感覚によるのかもしれません。
プログラマーなら、安全をとるとは思いますが。

たとえで、ちょっと分かりました。
私はある程度予測を立てた、そのソフトにあった関数を作りたいと思っています。
「矢印つきの線」と要望がでそうなら(あくまで自分のためのソフトしか作ってこなかったので)、それを含めて、関数と引数の設定をつけようと念頭に入れて関数をつくります。
それが、コンピュータにとって負荷が少ないと思うので。
ただ最近は、コンピュータ自体が高性能になり、その辺の事を気にせずに、最小公倍数を作ることによって、開発速度をあげ、また不具合が会った場合に、直しやすくするためなのかな？とも思いました。
それは私にも利点はありますし。

お礼日時：2006/08/29 22:11

No.6 回答者： sha-girl 回答日時： 2006/08/28 22:52

>delphiは、JAVAのようにガーベージコレクションがないので、オブジェクトを明示的に開放しないと、メモリー上に残るとの事。

別にメモリー開放を忘れても問題はありません。単にメモリーを食うだけです。(もちろん限度はありますが、、)
Windowsの仕組上、プロセス終了時にそのプロセスが使っていたメモリーは自動で開放されます。
逆にサーバーデーモンのような長時間起動しつづけるようなアプリケーションはメモリリークを気にする必要がありますが
Javaのガベージコレクションも完全というわけではなく、やはりメモリリークに注意を払う必要があります。
http://www-06.ibm.com/jp/developerworks/java/051 …

>たとえば、奇数か偶数かを判断するクラスを作成します。これが大元です。
うーん。その例だと便利だと感じませんね・・・
私はゲームの開発者なのでシューティングゲームを例にいうと
CCharaというベースクラスがあって、それを継承して
CEnemy(敵),CMyself(自機)という風に継承します。
CCharaには描画ルーチンや位置情報や当たり判定の情報等、
共通なものを持たせます。
後はnew CEnemyとインスタンスを作成するだけでどんどん敵が出現できるとすれば
便利だと感じませんか？
二人同時プレイにしたければ同じくCMyselfを２つ作成すればいいのです。

オブジェクト指向も良いことばかりではありません。デメリットもあります。
例えばC++でオブジェクト指向でプログラミングした場合、
C流で書いたプログラムに比べれば若干速度は落ちます。
C++の設計者自身それは認めていますし速度ロスを5%以内に抑えるという目標も掲げていました。
継承すればする分、その回数コンストラクタが呼ばれますし仮想関数をもてば
Vテーブルを持つことになるのでその分オーバーヘッドになります。

この回答へのお礼

オブジェクト指向のデメリットも見ました。
インスタンス化する際にメモリーを使うのと、その時の負荷が高くなると。（私は詳しくはわかりませんが。）
ゲームのたとえは、私がインベーダーゲームに毛が生えたようなシンプルなものしか想像できないため、サブルーチンと変数でもいいのかな？と。
継承が使えるので、オブジェクト指向の方が、便利というのはわかるのですが。
やはり、地道に構造化の場合と、オブジェクト指向で作ってみようかと思います。

お礼日時：2006/08/29 22:00

No.5 回答者： elmclose 回答日時： 2006/08/28 22:38

#1です。

>逆に、継承の方が圧倒的に作りやすいものをあげていただければ・・・。

作りやすい典型例といえるかどうかはわかりませんが、私が読んだそのOSの中で、特に感心したのは、ユーザインタフェースの部分（ウィンドウシステム）でした。
まだ、MS-Windowsが世の中に無い時代でしたが、様々な種類のウィンドウとその構成要素が見事に差分プログラミングされており、クラスとはこう使うものなのか、と感心しました。

>ガーベージコレクションがないので、オブジェクトを明示的に開放しないと、メモリー上に残るとの事。

それならばやはり、インスタンスの終了時に自動的に実行されるメソッドのひとつとしてメモリを解放するコードを書いて、そのメソッドを最上位のクラスに所属させておくのが、最も良い（というか普通の）やりかただと思います。

この回答へのお礼

＞最も良い（というか普通の）やりかただと思います。
というのは、初心者本には、全く書いてありませんでした。＾＾；
考えれば分かることなんでしょうが、私にはとりあえず分かりませんでした。
インスタンス化させたら、その都度解放しないとダメなの？
そんなことしてたら、プログラムが汚くなるじゃん、と。
デフォルトで、ソフトの終了時に解放してくれれば、便利なのにと。

私の中でまだ、”継承”とサブルーチンの変数渡しがうまく分離できていないようです。
線を引くクラスを作り、色を付けるクラスで継承させるのと。
線を引くサブルーチンを作り、色の変数を渡すのとで、なにが違うのか？と。

お礼日時：2006/08/29 01:02

No.4 回答者： gungnir7 回答日時： 2006/08/28 19:30

オブジェクト指向の利点は設計の段階の問題です。

どうしても最初はプログラミングの方に目が向いてしまいがちですが、
オブジェクト指向は設計までを含んだ概念（思想）なのです。

それでオブジェクト指向が登場してきた背景には
ソフトウェアの大規模化が第一位に挙げられます。

それまでのウォータフォールモデルではコストがかかり過ぎる事例が
幾つも発生してしまいました。

つまりウォータフォールモデルではある程度揃ってからでないと
次の段階へ進めないのです。
そして、そこには必ずフィードバックが生じます。
これらのことがシステム規模が大きくなると大きな足枷になるのです。

ウォータフォールモデルではシステム規模の２乗に比例して
開発コストが増えていくという試算を出した人もいます。

勿論、ウォータフォールはこれでいいところもあるのです。
何といっても各行程の進捗管理が容易なのです。
だから、小規模システムでは全然問題ありません。
ましてや個人の方が趣味で開発されるのでしたら構造化言語でも十分です。

>構造化プログラミングでは無理な事なのか？

無理というか、時間さえかければ可能なことです。
事実、1990年代はそれでシステム開発が主流なのでしたし。

この回答へのお礼

やはりオブジェクト指向というのは、その背景として
＞ソフトウェアの大規模化　と言う物があるのですね。
個人でつかっても、便利は便利なんだろうけど。
隠蔽やカプセル化なんかは、そうかな？とは思っていたのですが。
ありがとうございました。

お礼日時：2006/08/29 00:54

No.3 回答者： foreach 回答日時： 2006/08/28 18:09

＞たとえば、奇数か偶数かを判断するクラスを作成します。

＞これは関数・サブルーチンでもできると思います。
＞継承の方が圧倒的に作りやすいものをあげていただければ・・・。

Delphiを使ってるということなのでDelphiに限って言いますが、
Delphiにおいて継承のほうが圧倒的に作りやすいのは、まさしく「コンポーネント」でしょう。


例えば、この奇数偶数判定クラスを合計１００箇所のEditで使う必要があったとします。
Editに数値を入力し、フォーカスが抜けたら判定結果をラベルに表示という仕様にします。
判定部分のみをクラス化して１００箇所から呼び出すのであれば、おっしゃる通りサブルーチンで事足りるでしょう。


・・ですが、Delphiで”効率よく”やるとなるとちょっと話が変わります。

具体的には、TEditを継承して新しいコンポーネントを作ります。
その新しいコンポーネントは継承した段階で１行もコードを書かなくてもTEditと同等品になります（オブジェクト指向の継承）。
プロパティやイベント・メソッドに至るTEditの全機能を保有していることになります。
そのコンポのソースに”フォーカスを抜けたら入力値が奇数か偶数かを判定させるルーチン”を書き足します。
新しいプロパティを追加してフォーカスが抜けたら判定結果を反映させるようにします。
余裕があれば数値のみ許容する等も欲しいところですかね。

そのコンポーネントを１００箇所に貼り付けます。
もちろん、複数のフォーム、あるいは複数のプロジェクトにまたがっても構いません。

さて、このコンポにバグが発覚したとします。
例えば奇数と偶数を間違えて逆に判定してたとかですね。
当然バグは修正しなければなりませんが、コンポ化したのであれば、コンポのソースだけを修正します。
修正が終わったら、使ってるプロジェクトをDelphiで開いてリコンパイルするだけです。確認も使っている箇所を１、２箇所で問題ありません。

また、この新しいコンポの継承元のコンポにバグがあったとします。
この話しで言えばTEditになるわけですが、この場合、TEditを修正したらTEditを使っている部分も全て修正されるのは当然として、TEditを継承している今回のコンポも”同時に修正”されます。

まあ、オブジェクト指向で言えば当然なわけですが、Delphiは他の開発環境と比較して、非常に美しいオブジェクト階層が最初から用意されているため、特に継承の恩恵によるものが大きい環境とも言えます。
だからこそ、雄志によるフリーのコンポーネントもネット上に多数公開されてるのも、これが理由だったりするわけです。

ただし、コンポーネントの開発はDelphi初心者には敷居が高いでしょう。
オブジェクト指向を理解した中級者以上になればバリバリ自作できるようになれるはずです。


＞オブジェクトを明示的に開放しないと、メモリー上に残るとの事。

確かにDelphi（Win32）にはガベコレが無いので明示的にFreeしないとリークしますね。
ですが、私はいつ解放されるかよく分からないガベコレよりも明示的に解放するほうが好みですね。
使った事がないですが、解放忘れをチェックするソフトもあるらしいですよ。

この回答へのお礼

＞解放忘れをチェックするソフト
は、便利そうですが、特定の条件だけインスタンス化する場合は、どこで開放し忘れたか・・・があいまいになるので。
この条件の場合のみ、開放せずにループが抜ける。なんて間抜けな事態がおこりそうで。
プログラムを扱っている割には、見た目で見えたものしか、信用できないたちなので。＾＾；

＞TEditを継承して新しいコンポーネント
たしかに、delphiだと、知らない間に継承していることがありますね。
私も、とりあえず一つプログラムを構造化ですが、作ったのですが、あ、これも継承か、と思える事もしばしば。
それと雄志のつくったコンポーネントの利用という面は、確かに便利です。
一人で全部作りたいのですが、面倒な所や今の自分の技術では一から勉強しないといけないようなものが、それを意識しないで使えるのはいいことかもしれません。
なるほど、確かに参考になりました。

お礼日時：2006/08/29 00:49

No.2 回答者： galluda 回答日時： 2006/08/28 09:08

がると申します。

んっと…オブジェクト指向「プログラミング」(OOP)について言及するのであれば。

1:マルチプルインスタンス(multiple instance)
「一つのクラスで複数のインスタンスを切る」処理です。
必要な状況において、これを「構造化プログラミング＋構造体」だけでやろうとすると結構面倒なので。
OOPにとってはごく当然な機能ではあるのですが、実はとても便利で大切な機能だったりします。

2:カプセル化(encapsulation)
これは「直感的」であるというところでしょうか？
後は「隠蔽がしやすい」。

3:保守の容易性
きちんと設計したクラスなら、かなり無茶な仕様変更でも対応が楽にできたりします。

OOPに限定するのであれば。
本質的に、オブジェクト指向でかかれたものは全て構造化プログラミングに変換が可能です。
ですので「オブジェクトで書かなくても構造化で書けるじゃん」という発言は、正しいです。
ただポイントは「オブジェクトの技術使ったほうが楽に書けたり楽にメンテナンスできたりする」のがポイントなんだろうと思っております。
楽にできるっていうのは、そのまんま工数に響いてきますので。

後はむしろOOSEとかが便利なのだろうと思っているのですが。設計をオブジェクト、コーディングは構造化、ってのも実際ありますし(メモリ資源などの問題から、OOPに適さない業務ってのは実際に存在します)。
このあたりは、きちんとした書籍で学ばれると色々と見えてくるかと思います。
個人的に、日本語で読める「まっとうな」「唯一の」お勧めできる書籍は下記のものになります。

［復刻版］「オブジェクト指向ソフトウェア工学OOSE――use-caseによるアプローチ――」
http://katsu.watanabe.name/oose/

かなり歯ごたえに富んだ本ですが、値段以上の価値があると思っております。

ちなみに継承については、最近は「可能な限り継承は"しない"」という方向性も増えております。
利点ではあるのですが、同時に「乱用すると最悪の欠点」にもなりえるので。

あと、補足＆御礼の文章から少し。
> 奇数か偶数かを判断するクラスを作成
私なら多分作りません(苦笑
あるいは、作るとしても、utilという「なんでもお便利な関数が入ってる」だけのクラスとか、せいぜいがmath_util(数字関連のお便利クラス)とかにいれて終わりです。
実際、処理的には

if (判定したい値 論理積 1) {
奇数
} else {
偶数
}

程度でもとまってしまいますし。これをクラス化する意味はあんまりないと思います。

そうですねぇ…「ファクトリーメソッド使って目的に沿ったDBアクセスクラス使う」とかってのは割合にオブジェクトの便利な１側面ではないでしょうか？
上述をうまく設計すると「設定ファイル一箇所に変更をかけるだけで、DBMSが変ってもプログラムには一切の変更を与えずにすむ」です(一応補足。私は「SQL文生成」にもクラスを用いてますので、完全互換が可能です)。

クラスは、こういった「面倒なものを簡単にする」モノなので。簡単なものを基準に考えるとどうしても「いいじゃん構造で」って話になると思います。

以上、何かの参考にでもなれば幸いです。

この回答へのお礼

お名前だけは、前から知っていました。
1:マルチプルインスタンスは、ようはクラスというカプセルにいろいろなデータを入れるということですよね。
これも、私はサブルーチンのイメージの方が強いです。
ただ、シュミレーションのような個の情報をもち、多くの同じカプセルで別のデータが存在する場合は、サブルーチンでは無理があるのかとも思えますが、やはりサブルーチンでも問題ないのかな？と思ってしまいます。
あまり宜しくありませんが、forループの中に関数を入れたり、、、と。

2:カプセル化(encapsulation)
独立性に関しても、変数名のつけ方や、グローバル変数を最小限にすれば、特に問題ない・・・のかな？と。
この辺は、私個人でプログラムを作っているので、他人との衝突を意識しないためかもしれません。

3:保守の容易性
この辺は、きれいなオブジェクト指向のプログラムを見たことがないので、日曜プログラマには、分かりづらい点です。。

＞「オブジェクトの技術使ったほうが楽に書けたり楽にメンテナンスできたりする」
の意見はわかります。
PerlとPHPはだいたい同じ事ができますが、いまさらPerlを使いたいとは私は思いません。データーベースとか、画像のアップロードとかが大変なので。
後発が有利で便利なのは、分かるのですが、その便利さ加減がピンときてなくって。
逆に欠点の方が強いです。
修得の問題と、重箱の隅ですがメモリーの問題。
解放するという点(delphiだけかな？)と、ポリモーフィズムで本来プログラムに使わないものを書く点。
これは大変便利なのですが、オブジェクトする際にメモリーの使用量が大きくなってしまうので、なんとなくいやです。
これはPerlの事から思っていたのですが、サーバのメモリーがギガ単位になる時代ですが、なんとなく気にはなっていました。

> 奇数か偶数かを判断するクラスを作成
私もたぶん作りません。(苦笑
たしかdelphiには、奇数偶数を判断する関数がすでに用意されていたような。
ただ、初心者向けの本を読むと、わざわざオブジェクトにしなくても、構造化で十分だし、その方がわかりやすいサンプルばかりで。
オブジェクト指向を勉強したい気持ちはあるのですが。
ただ「SQL文生成」、「面倒なものを簡単にする」と言うのは、わかりやすいです。
私の中でvectorの超ミニソフトのイメージで納得できました。＾＾

お礼日時：2006/08/29 00:38

No.1 回答者： elmclose 回答日時： 2006/08/28 00:24

オブジェクト指向か、非オブジェクト指向（の構造化プログラミング）か、というのは、思想の違いのようなところがありますので単純に優劣を比較するのは難しいのですが、あえて回答しますと・・・

オブジェクト指向の利点は、

１）最大の利点は継承を利用できること
クラス設計を適切に行なうと、概念的に似ていて詳細な振る舞いの違うクラスを、ほぼ差分だけで記述していけること。特に、大規模なソフトウェアをインクリメンタルに開発していく場合や、ソフトウェアの保守を行なう際に便利です。もし、継承を使わないとすると、既存のモジュールに手を入れたり（パラメータの追加や条件分岐の追加など）したらテストをいちから行なわないと信頼性が得られないですし、継承なしのモジュールの追加を行なう場合には既存モジュールとのコードの重複が多く出てきて保守性を下げます。

２）プログラムの可読性
適切にクラス設計がされていると、非オブジェクト指向の場合よりは、ソースコードが読みやすいです。

なお、オブジェクト指向のメリットがより大きく発揮されるのは、小規模ソフトよりも大規模ソフトのほうだと思います。そして、それは、コードを書く人が大勢か少数化によらずにいえることだと思います。

私は、以前に、オブジェクト指向言語で書かれたOSのコードを一通りざっと読んだことがあり、それが大規模なオブジェクト指向プログラムに接した最初の機会だったのですが、当時の感想は、非オブジェクト指向言語で書かれたソフトに比べると、まるで芸術作品を読んでいるような錯覚に陥るようなエレガントなものでした。

なお、delphiをよく知らないので「メモリーから解放しないといけないので、それが少し怖い」というのがよくわからないのですが、もしメモリを解放しなければならないのでしたら、そういう解放のコードを一箇所だけに書いて、必要な全てのクラスでそれを継承させるということも可能であると思うのですが、どうでしょうか。

この回答への補足

＞継承の利点は、(表面的な？)わかります。

たとえば、奇数か偶数かを判断するクラスを作成します。
これが大元です。
で、奇数な場合、素数かどうかを判断させる場合は大本のクラスを継承させて、素数かどうかを判断させればいいのですが、これは関数・サブルーチンでもできると思います。

やはり大規模で難しい事に挑戦しないと、継承の便利さもわかりづらいのかも・・・、私は頭が良いほうではないしなー。＾＾；

逆に、継承の方が圧倒的に作りやすいものをあげていただければ・・・。

補足日時：2006/08/28 08:37

この回答へのお礼

＞大規模なソフトウェアをインクリメンタルに開発していく場合
小規模で作りっぱなし(もしくは、すぐに検索する事が可能)な場合は、オブジェクト指向の利点は大規模より少ない・・・納得です。

継承の便利さはわかるのですが、サブルーチンから出た結果を別のサブルーチンで処理すれば、継承のようなことができると思うのですが。
これはＰＨＰの話です。
delphiは変数の型に厳しいので、ポリモーフィズムは便利だと思うのですが。(この辺が日曜プログラマーなので、構造化のままでいいか、オブジェクト指向に乗り換えるか、が微妙なところです。＾＾；)

＞プログラムの可読性
は、まだオブジェクト指向の書き方になれていないので、まだなんとも言えません。
圧倒的に、構造化で書かれたものしかみていないので(主にＰＨＰ、Ｐｅｒｌ)、オブジェクト指向で書かれたプログラムをそれほど見ていないのも原因かもしれません。
私も、芸術的なプログラムを見てみたいものです。

delphiは、JAVAのようにガーベージコレクションがないので、オブジェクトを明示的に開放しないと、メモリー上に残るとの事。
これを忘れてはいないかが、心配になってしまいます。
バグが予想される原因は、できるだけ避けたいので。
（まだ、初心者なので、語彙が違うこともあるとおもいますが。）
大本を作りそれに継承させて、まとめて開放するのも手ですね。
大変参考になりました。

お礼日時：2006/08/28 08:33