クラスのこと

[meigin]

こんにちは

取りあえずクラスを使っています。

データーを保持するクラスＡをＢ，Ｃ，Ｄに継承します。
ＥクラスにＡのポインタを保持して、Ｂ，Ｃ，Ｄのアドレスを渡します。

この方法ではＢ，Ｃ，Ｄそれぞれにデーターが保持されてしまいます。

データーを１つにして、Ｂ，Ｃ，Ｄを入れ替える方法はないんでしょうか？

Ａは画像の管理です。

Ｂ，Ｃ，Ｄは表示のクラスです。
（マップチップの並べ方が違い、座標修正もここで行っています）

Ｅは、操作のクラスです。
（マウス等）

何か方法がありましたら教えて下さると嬉しいです。
お願いします。

[バグ]

ＡのメンバにＢ、Ｃ、Ｄのポインタを持たせてしまうのはマズイのでしょうか？
Ｅ.Ａー>Ｂ
Ｅ.Ａー>Ｃ
Ｅ.Ａー>Ｄ

これならデータは１つになるような気がしますが…

[Justy]

＠meiginさん
　継承は基本的に B is A のとき、Aを継承して Bを作るものです。
　Aと B～Dの関係を見る限り、このケースでは継承はふさわしくないでしょう。

　となると、B/C/Dに Aへのポインタを持たせるか、描画を行う抽象クラス Fを作って、Fが Aへのポインタを持ち、B/C/Dは Fを継承させて作る方法がいいのではないかと思います。
　で、Eは Fの持つ描画関数を使って描画する、と。


＠バグさん
＞ＡのメンバにＢ、Ｃ、Ｄのポインタを持たせてしまうのはマズイのでしょうか？
　設計上、ちょっとどうでしょう。
　今後、Ｂ／Ｃ／Ｄのお仲間が増えたときにＡにメンバ変数を増やさなければならない（ひょっとすると内部処理も）となるとＡの独立性が失われていきます。

　もし、この方法をとるのであればＡに１つの描画メンバ関数を追加します。このメンバ関数は引数にクラスＧへのポインタ（ないしは参照）をとり、このＧを使って描画を行います。
　クラスＧは描画の（Ａへのポインタないしは参照を引数にとる）純粋仮想関数を持つインターフェースクラスとし、Ｂ／Ｃ／ＤはＧを継承して描画の詳細を実装するようにすれば、今後お仲間が増えてもＡのクラスの変更は原則的に必要がなくなります。


　他にもテンプレートを使った手法とかいろいろありますが、実際どの方法がベストかは、まだちょっとこれだけの情報では判断しにくい、ってのが正直なところです・・・。

[meigin]

バクさん

ＡにＢのポインタを持たせると、
ＢはＡのデーターをどうやって使えばいいのか解らないので
それが出来ませんでした。


Justyさん

ソースを公開しているのですが、多すぎても返って解りづらいような。
Ｃ　Ｄに当たるクラスは入ってないです。
マップチップの並べ方が違い、６方向に対応しています。
マップが半分ずれて表示され、移動経路が６方向になります。

純仮想関数のクラスに継承しているのがＢに当たります。


設計ミスをしているので、作り直そうと思っているのです。
そこで、出来なかったことも聞いてみようかなとなったわけです。
多重継承している上、意味のない継承も……。


寝ますので、明日試してみます。
色々ありがとう御座います。

[バグ]

かなりゴチャゴチャになりそうだし、汎用性のないスマートなやり方ではないので、あまりオススメではありませんが…(;^_^A

BにAのデータを使わせるだけならば、Aの中にBを初期化するメンバ関数を追加してはどうでしょうか？

うーん、自分で書いておきながら、なんて苦し紛れな方法なんだろう…と思ってしまいましたよ(;´Д`)

[バグ]

今、読み返すとムチャクチャな事を書いてしまった…(;´Д`)
Justyさんの言われるように、B、C、DにAへのポインタを持たせるのがベストではないでしょうか？
１つ前の私の書き込みは無視しておいてください…m(__)m

[meigin]

Justyさん　バクさん

ありがとう御座います。
上手く行きました。

思っていたより簡単でした。
継承をポインタに変えるだけで上手く行きました。

問題点も解決出来て棚からぼた餅のような嬉しさです。


継承って、思っていたのと感じが違うんですね。
ＡのクラスのデーターをＢ→Ｃ→Ｄと渡していけるのかと思っていたのです。
Ｂ＝Ｃとしたら当然エラーでした。

あはは……。

[Justy]

＞ソースを公開しているのですが、多すぎても返って解りづらいような
　それほど複雑な構成という訳でもなさそうなので、doxygenでパースしつつちょっと見てみました。
　継承関係からするとＡは ClFightPlaceクラスで、Ｂは ClFourDirectionsクラスで、Ｃに相当するのがまだ見ぬ ClSixDirections（仮）ってところでしょうか。


＞上手く行きました
　それは何よりです。


＞継承って、思っていたのと感じが違うんですね
　継承と内包をどう使い分ければいいのか、内包も実体を持てばいいのかポインタで持てばいいのか。
　それがオブジェクト指向言語の最初の壁ですよね。

[meigin]

Justyさん

Ａに当たるのはもう一つ上です。
ClFightPlaceクラスは、抽象クラスのＦになりました。

名前空間を使って関数をまとめた方が楽な様な気がするのですが、
クラスの方が良いのかな？

オブジェクト指向って難しいですね。
継承って使い所があんまりない様な……。
内包は継承と殆ど同じですよね？
（メンバ変数になるだけですよね）

うーん。

[Justy]

＞Ａに当たるのはもう一つ上です
　あ、そうか。Ａは画像を扱うクラスでしたよね。


＞継承って使い所があんまりない様な……。
　んー、作る物によりけりですなところはあります。
　例えば今回の kageSだと、売り買いできる物として武器・防具・アイテムがありますよね？
　これらのクラス全てに価格というメンバ変数がありますが、「売り買い可能なものというクラス」を基底として名前とか価格をメンバ変数を入れておけば、将来お店クラスを作ったときに武器とか防具とかの生々しいクラスを個別に扱わなくても「売り買い可能なもの」クラスだけを相手にすれば売買できるようになります。

　その他インターフェースの為に継承したり、実装を引き継ぎたい為に継承したりと結構使いどころはあると思います。



＞内包は継承と殆ど同じですよね？
　内包という言い方がまずかったかもしれませんが、メンバ関数になるのと継承するのとでは全然違います。

　継承する場合（主に public継承）は、元のクラスの特殊版を作っていく感覚になります（特化）。
　例えばよくある例ですが、犬や猿や人は全てほ乳類であり、それらはほ乳類としての特徴を全て引き継いでいるので、ほ乳類を継承して犬や猿や人のクラスを作ることはそういう意味では正当です。

　では犬や猿や人が必ず持っている手足や頭は、というとこれはそれらが「所有」するものなので継承関係ではなく内包というか集約関係にあります。
　この場合はメンバ変数として実装するのが正当となります。


　継承の場合（public）、元のクラスの性能をそのまま引き継ぐので基底の publicメンバ関数は全て派生側でも使用できるようになります。
　もちろん継承を使わないでメンバ関数にしても、それを公開すれば同じメンバ関数を使用できるのですが、日本語で考えるといろいろ不自然さが目立ちます。
　
　例えばほ乳類は呼吸する、という動作を行う場合を想定し、ほ乳類クラスに呼吸するという関数があったとします。

　継承で作れば「人->呼吸する・・・人が呼吸する」で実行できます。
　が、集約で作ると「人->ほ乳類->呼吸する・・・人が持っているほ乳類が呼吸する」と何やら不自然さが目立ってきます。


　つたない説明ですが、こういう違いがあります。
　もっと詳しい＆正確なことはhttp://www.amazon.co.jp/dp/4881356194
の本を読むと、すごくよく判ると思います。

[meigin]

Justyさん

オブジェクトと言うのでブロックのようなイメージを持っていて、
単に繋げれば良いのかなと思っていました。

意味というか概念も考えて作らないといけないんですね。
もっと、本を読んで勉強します。

ありがとう御座います。