回答編集履歴
2
refine
answer
CHANGED
|
@@ -8,4 +8,16 @@
|
|
|
8
8
|
|
|
9
9
|
いずれにせよ位置情報や当たり判定情報をprivateメンバとして保持していますから、`BaseEntity`クラスの内部実装を後から変更する（実体で持つ→ポインタで持つ）ことは、同クラスの利用者にとっては影響がありません。何らかの理由で後からポインタで保持したいとなっても、そのときに内部実装を切り替えれば十分かと思います。
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
|
|
12
|
+
---
|
|
13
|
+
> ポインタで持つ場合の利点は、生成を遅らせることができる、
|
|
14
|
+
> デメリットとしてはnullチェックが必要であることだと思っております。
|
|
15
|
+
|
|
16
|
+
またnullチェックへの言及がありますが、設計上は「位置や当たり判定を持たない`BaseEntity`の存在を許すか」で判断すべきかと思います。答えがNOならばnullチェックはassert文で十分、つまりプログラムのバグ以外では気にする必要がありません。YESならば、`std::unique_ptr`などの(スマート)ポインタ型や、`std::optional<T>`といった無効/有効値を表すデータ型の利用を検討してみてください。
|
|
17
|
+
|
|
18
|
+
|
|
19
|
+
---
|
|
20
|
+
|
|
21
|
+
> デメリットとしてはヘッダのインクルードが増えてしまうこと、循環参照が起きる可能性があることだと思っております。
|
|
22
|
+
|
|
23
|
+
（あくまで推測ですが）`Vector3`や`BoundingCircle`などのクラスは、このアプリケーション（ゲーム）を構成するネジ・クギのような非常にプリミティブな共有部品のはずです。このような部品を宣言するヘッダで循環参照が起きるということは考えにくいですし、もし起きてしまうようならヘッダファイル構成を再考すべきでしょう。
|
1
refine
answer
CHANGED
|
@@ -6,4 +6,6 @@
|
|
|
6
6
|
|
|
7
7
|
**実装の観点：** 名前と説明文からの推測ですが、`Vector3`や`BoundingCircle`は2~3個の数値型から構成される小さなクラス(構造体)と予想されます。このようなデータ構造を保持する場合、動的確保＋ポインタ構造ではメモリ空間を浪費し、ポインタを介した変数アクセス・コストが相対的に大きくなってしまます。実体として`BaseEntity`クラスに内包してしまえば、このようなオーバーヘッドは全て解消します。
|
|
8
8
|
|
|
9
|
-
いずれにせよ位置情報や当たり判定情報をprivateメンバとして保持していますから、`BaseEntity`クラスの内部実装を後から変更する（実体で持つ→ポインタで持つ）ことは、同クラスの利用者にとっては影響がありません。何らかの理由で後からポインタで保持したいとなっても、そのときに内部実装を切り替えれば十分かと思います。
|
|
9
|
+
いずれにせよ位置情報や当たり判定情報をprivateメンバとして保持していますから、`BaseEntity`クラスの内部実装を後から変更する（実体で持つ→ポインタで持つ）ことは、同クラスの利用者にとっては影響がありません。何らかの理由で後からポインタで保持したいとなっても、そのときに内部実装を切り替えれば十分かと思います。
|
|
10
|
+
|
|
11
|
+
またnullチェックへの言及がありますが、設計上は「位置や当たり判定を持たない`BaseEntity`の存在を許すか」で判断すべきかと思います。答えがNOならばnullチェックはassert文で十分、つまりプログラムのバグ以外では気にする必要がありません。YESならば、`std::unique_ptr`などの(スマート)ポインタ型や、`std::optional<T>`といった無効/有効値を表すデータ型の利用を検討してみてください。
|