継承は何回までのほうがいいのでしょうか？

[軍曹]

はじめての投稿となりますので
お手柔らかにお願いします。

現在キャラクターを作るときに

Object(基本クラス)
↑
Character
↑
Enemy(このクラスはﾏﾈｰｼﾞｬｰでEnemyを配列で管理)
↑
シャア専用ゲルググ

みたいな感じで
シャア専用ゲルググを作るのに派生を３回しています。

派生は極力２回ぐらいまでに抑えないと
スパゲッティ状態(ややこしい)のプログラムになると
聞いたのですがこの作り方はいけないでしょうか?

[beatle]

具体的な回数を考えるのは意味がありません。
2回というのも確かな根拠はないのでは？

継承は差分プログラミングをするのに便利ですが、やりすぎると「シャア専用ゲルググ」を理解するために沢山のクラスを横断的に見なければならなくなります。
1つのクラスを読むだけで理解できたほうが、プログラム理解は楽になるでしょう。
要は、継承によるメリットとデメリットのバランスを考えましょうということです。

.NET Frameworkなどを見ると、継承の数がかなり多くなっているクラスもあります。それこそ3回なんていうのは少ない方ですね。
継承は深いですが、綺麗な継承関係なので扱いやすいです。

軍曹さんの考えた継承関係は、それなりに意味のある継承だと思います。
軍曹さん自身の手に負えなくなるのなら継承を控えたほうがいいかもしれませんが、そのくらいの継承ならばOKなのではと思います。

継承（is-a関係）ではなく、必要な機能を持つクラスをメンバ変数として保持するやり方（has-a関係）もあります。
継承を浅く保ちつつ、差分プログラミングをする方法として使いやすいと思いますのでご参考まで。

[軍曹]

beatleさん解答ありがとうございます。

とても参考になりました＾＾
現在クラス図にしても頭の中で理解できる
範囲内なのでこのままいこうと思います。
beatleさんのいうとうり継承によってだんだん
わけがわからなくなってきたら色々方法を
考えていきます。
すっきりしましたありがとうございます!

[salsaww]

　すでに解決済みの様ですが・・・・・・。

　シャア専用ゲルググ　のようなものを作りたい場合には、
それ用のclassを作る事よりも、Strategy　Patternなどを用いて、
Enemy　classを適時、その振る舞いを変える様にすることの方が重要かと思います。


programming上でのclassとゲームなどでのクラスや種類などは混同しがちですが、
多くの場合、programming上のclassは基本的に処理の違いや根本的な性質の違いによって別けるべきです。

戦闘プログラムなどの場合は、勇者と魔法使いの区別はおろか、
場合によっては敵と見方を別のクラスにする必要すら無いことが多いです。
大雑把に言えば、敵であろうと勇者であろうと、あるキャラクターが[攻撃する]、[死亡する]、[回復する]と言った処理は共通で
違いがそもそDataとしてのHPやMPが”１９”/”１８０”などと値の違いはあっても本質が同じで、
名前や見た目も同様に”敵”/”勇者”として違いがあっても本質が同じであるからです。

同様に、ゲーム上では単一の勇者というクラスもprogramming上では、その場面毎に
shop処理では、Buyer classであったり、battle処理では　Character classであったり、
fild処理では、Piece classであったり、と必要に応じて別のclassを呼び出す事が良いでしょう。

これらの事は、一見するとヤヤコシイかもしれませんが、
これらにより、
　・　同じコードをだらだらと書き過ぎて、一カ所のバグはとったのに別の所では残っている　とか
　・　全然関係ない部分で、おかしなバグが入り込んでいて、再現性の低いバグが現れる　とか
　・　各classの処理が複雑化しすぎて、こっちをいじると、あっちでバグる　とか
の問題を低減させることが可能になります。
詳しくはオブジェクト指向の本（特に、Pattern languageを扱う物）を読まれると良いでしょう。

あと、基本的に現在の風潮として継承よりも集約が好まれます。