回答編集履歴
4
追記
test
CHANGED
|
@@ -21,6 +21,7 @@
|
|
|
21
21
|
foreach を複数回やる話については，
|
|
22
22
|
「敵ってのがものすごい個体数なのでループを数回やること自体がやばい」とかいう事態に直面しているのでもないならば，別にいいんじゃない？と思う．
|
|
23
23
|
「特殊なタイミング」の種類が10も20もあるとかいう話なら，各 foreach で回す集合を同一のものとしなければよい．
|
|
24
|
+
（ある特殊なタイミングにおいて「全ての既存敵オブジェクトに関するループ」を回すのが嫌なら，例えば，各敵オブジェクトがMove()メソッド内で「今回，このタイミングで俺のメソッドを呼べ」って能動的に手を挙げるようにでもしとけばどうか）
|
|
24
25
|
|
|
25
26
|
ただ，
|
|
26
27
|
|
3
１文追加
test
CHANGED
|
@@ -20,6 +20,7 @@
|
|
|
20
20
|
|
|
21
21
|
foreach を複数回やる話については，
|
|
22
22
|
「敵ってのがものすごい個体数なのでループを数回やること自体がやばい」とかいう事態に直面しているのでもないならば，別にいいんじゃない？と思う．
|
|
23
|
+
「特殊なタイミング」の種類が10も20もあるとかいう話なら，各 foreach で回す集合を同一のものとしなければよい．
|
|
23
24
|
|
|
24
25
|
ただ，
|
|
25
26
|
|
2
追記
test
CHANGED
|
@@ -21,3 +21,10 @@
|
|
|
21
21
|
foreach を複数回やる話については，
|
|
22
22
|
「敵ってのがものすごい個体数なのでループを数回やること自体がやばい」とかいう事態に直面しているのでもないならば，別にいいんじゃない？と思う．
|
|
23
23
|
|
|
24
|
+
ただ，
|
|
25
|
+
|
|
26
|
+
> 全員行動終了後、8や9のような敵のために、再度 foreach で enemies を回して、各要素が IActionAfterMoveインターフェース を実装しているか調べて、trueなら ActionAfterMove()を処理する。
|
|
27
|
+
|
|
28
|
+
っていうのは何だかなぁ．
|
|
29
|
+
「インタフェースを実装しているかどうか」なんて判断が要るとは思えない．
|
|
30
|
+
（簡単には `ActionAfterMove()` は IEnemy 側に移し，何もしない奴は「中身が空」な形の実装としておけばいいだけでは．）
|
1
追記
test
CHANGED
|
@@ -6,3 +6,18 @@
|
|
|
6
6
|
前者だって同じハズ．
|
|
7
7
|
「フィールドとして 移動 とか 行動 っていう処理を持たせるだけで，クラスは同じで良くね？」っていう．
|
|
8
8
|
|
|
9
|
+
|
|
10
|
+
> if (enemyType == HOGE) { // HOGE特有処理 }
|
|
11
|
+
|
|
12
|
+
っていう実装が可なのであれば，同様に
|
|
13
|
+
`if (MoveType == XXX) { /* XXX特有処理 */ }`
|
|
14
|
+
っていう実装も考えられるわけだ．
|
|
15
|
+
|
|
16
|
+
もちろん，処理分岐の具体的な実装方法は if や switch 以外にも色々あり得るけども，それはそれ．
|
|
17
|
+
「何かしらをコンストラクタあたりで与えてしまえばあとはそれを使って処理分岐してればいいよね」と考えてみては．
|
|
18
|
+
|
|
19
|
+
---
|
|
20
|
+
|
|
21
|
+
foreach を複数回やる話については，
|
|
22
|
+
「敵ってのがものすごい個体数なのでループを数回やること自体がやばい」とかいう事態に直面しているのでもないならば，別にいいんじゃない？と思う．
|
|
23
|
+
|