回答編集履歴
2
refine
test
CHANGED
|
@@ -18,4 +18,28 @@
|
|
|
18
18
|
|
|
19
19
|
|
|
20
20
|
|
|
21
|
+
|
|
22
|
+
|
|
23
|
+
---
|
|
24
|
+
|
|
25
|
+
> ポインタで持つ場合の利点は、生成を遅らせることができる、
|
|
26
|
+
|
|
27
|
+
> デメリットとしてはnullチェックが必要であることだと思っております。
|
|
28
|
+
|
|
29
|
+
|
|
30
|
+
|
|
21
31
|
またnullチェックへの言及がありますが、設計上は「位置や当たり判定を持たない`BaseEntity`の存在を許すか」で判断すべきかと思います。答えがNOならばnullチェックはassert文で十分、つまりプログラムのバグ以外では気にする必要がありません。YESならば、`std::unique_ptr`などの(スマート)ポインタ型や、`std::optional<T>`といった無効/有効値を表すデータ型の利用を検討してみてください。
|
|
32
|
+
|
|
33
|
+
|
|
34
|
+
|
|
35
|
+
|
|
36
|
+
|
|
37
|
+
---
|
|
38
|
+
|
|
39
|
+
|
|
40
|
+
|
|
41
|
+
> デメリットとしてはヘッダのインクルードが増えてしまうこと、循環参照が起きる可能性があることだと思っております。
|
|
42
|
+
|
|
43
|
+
|
|
44
|
+
|
|
45
|
+
（あくまで推測ですが）`Vector3`や`BoundingCircle`などのクラスは、このアプリケーション（ゲーム）を構成するネジ・クギのような非常にプリミティブな共有部品のはずです。このような部品を宣言するヘッダで循環参照が起きるということは考えにくいですし、もし起きてしまうようならヘッダファイル構成を再考すべきでしょう。
|
1
refine
test
CHANGED
|
@@ -15,3 +15,7 @@
|
|
|
15
15
|
|
|
16
16
|
|
|
17
17
|
いずれにせよ位置情報や当たり判定情報をprivateメンバとして保持していますから、`BaseEntity`クラスの内部実装を後から変更する（実体で持つ→ポインタで持つ）ことは、同クラスの利用者にとっては影響がありません。何らかの理由で後からポインタで保持したいとなっても、そのときに内部実装を切り替えれば十分かと思います。
|
|
18
|
+
|
|
19
|
+
|
|
20
|
+
|
|
21
|
+
またnullチェックへの言及がありますが、設計上は「位置や当たり判定を持たない`BaseEntity`の存在を許すか」で判断すべきかと思います。答えがNOならばnullチェックはassert文で十分、つまりプログラムのバグ以外では気にする必要がありません。YESならば、`std::unique_ptr`などの(スマート)ポインタ型や、`std::optional<T>`といった無効/有効値を表すデータ型の利用を検討してみてください。
|