返信ありがとうございます。player_tは1つしか無いなら外部公開の必然が無いですね。全部、隠して良いでしょう。敵の時には公開を考慮する必要有りですけどね。敵に関する事は何一つやっておりませんが、敵の方が大変そうですね。STGは完成させておきたいので、頑張ります。返信ありがとうございます。1;}みたくしてインスタンスに画像を指定する形を取るとかすると思う.自分としては、引数が長くなるのが嫌なので今迄はそのような方法をとっていませんでした。本当にそれだけの理由です。質問ですが、インスタンスに画像を指定する形のメリットとデメリットを教えて頂きたいです。返信ありがとうございます。それも方針ですが、Dixqさんと私の方式だとクラス内でハンドルを得てますね。リソース管理をどうするかの設計の問題なので、どちらが良いとは言えませんが、自身のリソース確保を外部に委ねる気がするので私は外部から受け取るのはちょっと避けたいです。リソース確保を外部に委ねることを避けたいのですか?初心者のちょっとした質問です。6年前リソースを自分で管理するのは、利用する全部のリソースを見渡しやすいから(可読性・メンテナンス性)です。重複する画像リソースなど問題は、画像管理マネージャに管理を一存して画像ファイル名を引数に画像管理マネージャから画像ハンドルを貰う方法があります。言うか大抵そうします。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。6年前あと移動方向をusaoさんの言うように外部から受け渡すにはメリットとデメリットがあります。メリットは、usaoさんの言うとおりですが、デメリットとしてキー操作に対する処理がプレーヤーのオブジェクトに無いのは直感を裏切る可能性が高いと思います。どこのオブジェクトにあるべきかと言うのは重要問題で、上位のマネージャ・オブジェクトが細かい処理まで受け持つのはオブジェクトの特性を無視することになりかねません。言うことで私はplayerオブジェクト内部派です。違う意見が2つの話が出てきて混乱すると思いますが、まぁ現場でもよく有ることです。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。6年前>重複する画像リソースなど問題は、画像管理マネージャに管理を一存して画像ファイル名を引数に画像管理マネージャから画像ハンドルを貰う方法があります。言うか大抵そうします。返信ありがとうございます。//こっちが可能になる.ということです.(ch_tがどんな変数を抱えているかとかを知らなくていい場所にはそういう情報を公開せずに済む.)おお!こんなことが出来るなんて!感動しました。今まで知らずにやってきたのが恥ずかしくなりました。今すぐにでもソースを修正したいですが、今日の分の課題が終わらないので明日修正します。話これはまぁ好きな方法でやればいいのかな.各オブジェクトが内部で自分が使うのをロードする方式だと・同じリソースを複数個所で共有するとかしたくなった場合(わかりやすいとこだと,同じ種類の敵が複数出てくるとか)をどういう風に扱うのか・いろんなタイミングで「画像がロードできない」のようなエラーが発生し得るのがうざいといった点に適切な対応さえすれば,わかりやすい方式だとは思います.なるほど。自分はこのやり方では一度もやってなかったので、参考になります。返信ありがとうございます。リソースを自分で管理するのは、利用する全部のリソースを見渡しやすいから(可読性・メンテナンス性)です。重複する画像リソースなど問題は、画像管理マネージャに管理を一存して画像ファイル名を引数に画像管理マネージャから画像ハンドルを貰う方法があります。言うか大抵そうします。うーん、難しそうです...自分の力で出来そうならそのようにやりますが、今の実力で出来るとは思いません...しかし、出来るようにプログラムの勉強をします。返信ありがとうございます。>重複する画像リソースなど問題は、画像管理マネージャに管理を一存して画像ファイル名を引数に画像管理マネージャから画像ハンドルを貰う方法があります。言うか大抵そうします。...}キーの処理も内部ですか......オブジェクトにどこまでの責任を持たせるか?という思想の違いなんでしょうね.とにかく質問者様はご自身がやりやすい(わかりやすい&コーディングしやすい?)方法を選択されればよいと思います.自分は、多少長くなってもわかりやすいように書きたいと思います。今日、プログラムを書いていて思ったのですが、player.hに構造体を書いてありますよね。今日、プログラムを書いていて思ったのですが、player.hに構造体を書いてありますよね。player.hをmain.cppでincludeしているので隠蔽できてないのではないでしょうか?あと、それ以外はちゃんと隠蔽できていますか?はい。私とusaoさんが前方宣言の話をしていました。前方宣言を上手く使うことで構造体の構造を隠蔽できます。私のRPG講座が例になります。他は相互作用がないので、今のところ問題ないです。今後相互作用を追加していく時にカプセル化を守れるかが課題です。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。