電子書籍の厳選無料作品が豊富!

どうもオブジェクト指向をかんがえると
どうもこんがらがる者です。
オブジェクト指向でRPGゲームを作成しようと思い立ちました。

そこでひとまず、マップとキャラクターの構成を下記のように
考えてみました。(フィールドやメソッドの説明は割愛します。)

※ 親<-子 ◇-集約を表す

<キャラクター関連>
キャラクタ <┬ ファイター <┬ 自キャラ
        │         └ 敵キャラ
        └ 町の人

<マップ関連>
フィールド ◇┬マップ(マップ配列を管理する)
         └町の人[ ]

この時に、自キャラクラスがフィールドクラス
(マップの情報を管理するクラス)をインスタンスとして保持する
ことを思いついたのですが(キャラクタの現在位置という意味で)
そう考えると、自キャラがフィールドを持つことで
町の人を持っている状態になり、おかしいような気がしました。

根本的に間違っているかもしれませんので
なんでもいいのでご意見お願いします

A 回答 (5件)

>自キャラがフィールドを持つことで町の人を持っている状態になり、おかしいような気がしました。


別に問題は無いと思います。(その方が都合の良い場合もあるでしょう。)
キャラaが持っているフィールドのインスタンスとキャラbが持っているフィールドのインスタンスが
同じならaとbは同じフィールド上に居ることになるでしょう。
ただキャラクラスが必ずしもフィールドのインスタンスを持つ必要はありません。

例えば描画するクラスは別に存在するとして
フィールドと町の人を描画する場合には引数としてフィールドのインスタンスを渡すだけで良いはずで
キャラクラスがフィールドのインスタンスを持っている必要はありません。
他にもキャラaとキャラbの距離を求めたいとするなら、フィールドクラスにそのメソッドを用意すれば良いのです。
その場合もキャラaとキャラbは座標を返すメソッドさえあれば良いはずです。

※その辺の設計は言語や環境にも依存する部分ですのでオブジェクト指向として
絶対的な答えがあるわけではありませんし好みの問題もあります。
・他の人がみてわかりやすい設計
・データが冗長的でない
・処理速度に問題がない
以上3点のバランスを考えて設計すれば問題ないと思います。

※マップの配列というのが意味がわかりませんでしたが森とか山とか海とかの属性を持つマスの配列という事ですよね?
    • good
    • 0
この回答へのお礼

ご回答ありがとうございました。
設計のアドバイスもしていただいてありがとうございます。
冗長関連でひとつ懸念事項を思いつきました。
自キャラが複数になる場合には、それぞれのキャラが
フィールドを持つのはおかしいですよね。
自キャラというクラスはパーティというクラスに変更して
ステータス用(HPなど)の各インスタンスを配列で持たせることで
解決するんですかね。
でもおっしゃるとおりキャラとフィールドを
分離させておくとそのような事も解決しますね。

お礼日時:2008/01/24 00:04

> 実装後でも修正が容易にできるということではないですよね??



「容易に」の捕らえ方には程度の差があると思いますが・・・
ちゃんとカプセル化されている場合は、通常、容易に修正できます。
(再コンパイルは必要ですが)

例えば、Javaで標準で提供されているクラス郡について考えて見ます。
StringやVectorなどよく使いますよね。

これらもJavaで書かれていますが、実装を昔から変更していないと思いますか?
(実際に変更されているかどうか知りませんが)

利用する立場で考えた場合、そのクラスにどういうインタフェース(つまりパブリックメソッド)
があるかが重要で、内部でどんな処理がなされているかは重要ではないのです。

「キャラクタ」に対して、何を求めるかですが、現在位置をX,Y座標で教えてほしいのであれば、
 「現在位置をX,Y座標で教えて」と聞けるパブリックメソッドがあればよくて、
「キャラクタ」クラスが、内部的にどんな形で保持していて、どう処理をしているかは知る必要がありません。

クラス間でどんなやり取りが生じるのか、という設計は後々変更が難しいですが、
クラスの内部でどんな処理をするのかは、そのクラス内部を修正すればよいだけですので
影響範囲は小さくて済みます。

カプセル化を強く意識して設計すると、再利用性の高いプログラムが出来ると思います。
それができるかどうかは、分析段階にかかっています。オブジェクト指向において、
分析段階がいい加減だと、メリットを一切享受できない最悪の結果を招くこともあります。
    • good
    • 0

オブジェクト指向には、


オブジェクト指向分析とオブジェクト指向設計があります。
質問者さんが行ったのは、前者のオブジェクト指向分析にあたります。

対象となる事柄を分析するのがオブジェクト指向分析で、それを踏まえてJavaでどう実装するか考える(設計する)わけですが、分析時の関連をそのままクラス実装にする必要はありません。
Javaもオブジェクト指向の理想を100%実現できるわけではないので、分析に登場しないクラスや関連を付け加えたり関連を除去したりしてプログラムを完成させるのが普通です。

質問者さんのアプローチは特に間違っていないと思いますが、「オブジェクト指向」を意識しすぎるので戸惑うのかもしれません。
    • good
    • 0
この回答へのお礼

ご回答ありがとうございます。
つまり分析の後、クラスの関連を考える段階が重要という事ですね。
そこで問題があるかどうかが分かると、そういう事ですね。

分析>設計>コーディングという手順を踏んだことがないのですが
設計の段階で重要な事はなんでしょうか?
クラス図もシーケンス図もきちっと書いたほうがいいのでしょうか?
自作APIのリファレンスとかも用意するもんなんでしょうか?

お礼日時:2008/01/24 00:25

ご質問は、キャラクタクラスの”プライベートで”保持する変数として、ということですよね。


プライベートで持つ以上、ほとんどの場合、答えは「どっちでもいい」となると
思います。

実装上の問題ですので、問題があれば実装を変更するだけでよいので。
これが、”パブリック”である場合は問題が異なります。

要は、カプセル化された中身の話はさほど重要ではないということです。
    • good
    • 0
この回答へのお礼

ご回答ありがとうございます。
はい。プライベートで保持するつもりです。

カプセル化された中身の話はさほど重要ではない
というのは実装前の変更には柔軟に対応できるという
認識でよろしいでしょうか?
実装後でも修正が容易にできるということではないですよね??

お礼日時:2008/01/24 00:18

ご自身がおっしゃるように「キャラクタの現在位置という意味で」、


自キャラクラスがフィールドクラスをインスタンスとして保持するのは、
問題ないかと思います。


僕としては、キャラクター関連の「ファイター」が気になります。
もし、職業であればキャラクターの属性にしちゃいますね。
そうすると、職業の変更とかも可能ですから。
    • good
    • 0
この回答へのお礼

ご回答ありがとうございます。
ファイターというのは・・・わかり難かったかもしれませんが
職業ではなく「戦う者」という意味です。
町の人クラスと違って、HPや攻撃力などのステータスも管理できるクラスの意味です。

職業のような属性をキャラクラスに持たせるのも面白いですね…
別の意味で参考になりました・・。

お礼日時:2008/01/24 00:10

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!