回答編集履歴
10
表現の訂正
answer
CHANGED
|
@@ -95,7 +95,7 @@
|
|
|
95
95
|
|
|
96
96
|
データを保持する方法は人によって様々ですが、HPや攻撃力のステータスはシステムで静的に持つのではなく各々のオブジェクトに保持しておくのが良いと思います。
|
|
97
97
|
|
|
98
|
-
システムを管理させるデータというのはステータスなどの具体的な値ではなく、`Unit`オブジェクトではないでしょうか。
|
|
98
|
+
システムを管理させるデータというのはステータスなどの具体的な値ではなく、どちらかというと`Unit`オブジェクトだとか、何かしらのオブジェクトではないでしょうか。
|
|
99
99
|
|
|
100
100
|
2はよくわかりません。関数チックに定義しろということでしょうか。
|
|
101
101
|
|
9
誤字
answer
CHANGED
|
@@ -85,7 +85,7 @@
|
|
|
85
85
|
(4) 複雑になると予想される？システム部分の記述量を減らせる。
|
|
86
86
|
(5) オブジェクトの使い回しが容易（拡張性が高い？）
|
|
87
87
|
|
|
88
|
-
これ等５点を見て思うのは、オブジェクト指向っぽいというよりかは**継承という機能のメリットを説明している**ように見えます。
|
|
88
|
+
これ等５点を見て思うのは、オブジェクト指向っぽいというよりかは**継承という機能のメリットを説明している**ように見えます。なので、継承がオブジェクト指向の全てではないことは認識しておくと良いかもしれません。
|
|
89
89
|
|
|
90
90
|
> (1) わざわざクラスを用意してデータを保持せずとも、システムを管理するクラスに組み込むべきだ。
|
|
91
91
|
(2) これは普通のコードではない。
|
8
インタフェースにアクセス修飾子がついているので取った
answer
CHANGED
|
@@ -39,8 +39,8 @@
|
|
|
39
39
|
ゴブリンを表現するなら次のようになります
|
|
40
40
|
|
|
41
41
|
```Java
|
|
42
|
-
|
|
42
|
+
interface IAutoFightable{
|
|
43
|
-
|
|
43
|
+
void AutoFight();
|
|
44
44
|
}
|
|
45
45
|
|
|
46
46
|
public class Goblin extends BattleUnit implements IAutoFightable{
|
7
表現の訂正
answer
CHANGED
|
@@ -23,7 +23,7 @@
|
|
|
23
23
|
|
|
24
24
|
上の関係で違和感がないのはCAN-DOの方なので、NPCの「行動パターンを持つ」という概念はクラスではなくインタフェースで表現したほうが適切な気がします。
|
|
25
25
|
|
|
26
|
-
ただ、あくまで「個人的に」なので「ゴブリンは絶対NPC」という思想の元でクラス設計をされているのであれば、次に紹介する「気になった点を解決する」欄はスルーしても構いません。
|
|
26
|
+
ただ、あくまで「個人的に違和感を感じている」だけなので「ゴブリンは絶対NPC」という思想の元でクラス設計をされているのであれば、次に紹介する「気になった点を解決する」欄はスルーしても構いません。
|
|
27
27
|
|
|
28
28
|
### 気になった点を解決する
|
|
29
29
|
|
6
表現の訂正
answer
CHANGED
|
@@ -72,7 +72,7 @@
|
|
|
72
72
|
`Goblin`に`BattleNpcUnit`を継承させた場合は、上記の`Fight`メソッドの引数に渡すことができます。
|
|
73
73
|
`Goblin`クラスで`AutoFight`メソッドをオーバーライドした場合は、`Gobrin`独自の戦闘が行えます。（パーティー戦ならあるプレイヤーだけ一人狙いするとかがあるかもしれません）
|
|
74
74
|
|
|
75
|
-
そうすると`Fight`メソッドで**enemyの
|
|
75
|
+
そうすると`Fight`メソッドで**enemyに保持されているインスタンスの型を知らないで実装を作ることができる**ので作りやすくなります。
|
|
76
76
|
このように抽象クラスやインタフェースに対してプログラミングすることを「ポリモーフィズム」と言います。
|
|
77
77
|
|
|
78
78
|
もっとオブジェクト指向チックに設計したいのであれば、継承することだけにこだわらず抽象に対してプログラミングするという考え方があると良いと思います。
|
5
誤字
answer
CHANGED
|
@@ -18,7 +18,7 @@
|
|
|
18
18
|
- Goblin can be NPC
|
|
19
19
|
- Goblin can do fight automatically
|
|
20
20
|
|
|
21
|
-
継承はIS-A関係なので、文章にすると「Goblin is NPC」になります。
|
|
21
|
+
継承はIS-A関係なので、文章にすると「Goblin is a NPC」になります。
|
|
22
22
|
つまり「ゴブリンは絶対にNPC」という確固たる性質を持ってしまうわけなので、個人的に違和感があります。
|
|
23
23
|
|
|
24
24
|
上の関係で違和感がないのはCAN-DOの方なので、NPCの「行動パターンを持つ」という概念はクラスではなくインタフェースで表現したほうが適切な気がします。
|
4
スペルミス修正とマークダウンの修正
answer
CHANGED
|
@@ -12,7 +12,7 @@
|
|
|
12
12
|
|
|
13
13
|
クラス設計には日々悩んでるまだまだオブジェクト指向のアマチュアですが、2点。
|
|
14
14
|
|
|
15
|
-
1点目、UnitとNpcUnitとBattleNpcUnitは抽象クラスであったほうが良いと思います。
|
|
15
|
+
1点目、`Unit`と`NpcUnit`と`BattleNpcUnit`は抽象クラスであったほうが良いと思います。
|
|
16
16
|
|
|
17
17
|
2点目、Npcクラスは、独自の行動で戦闘ができるNPCとして振舞えるということなので、次のようにCAN-DO関係で表現できます。
|
|
18
18
|
- Goblin can be NPC
|
|
@@ -43,7 +43,7 @@
|
|
|
43
43
|
public void AutoFight();
|
|
44
44
|
}
|
|
45
45
|
|
|
46
|
-
public class
|
|
46
|
+
public class Goblin extends BattleUnit implements IAutoFightable{
|
|
47
47
|
public void AutoFight(){
|
|
48
48
|
//敵ゴブリンの戦闘パターンを定義
|
|
49
49
|
}
|
|
@@ -69,10 +69,10 @@
|
|
|
69
69
|
}
|
|
70
70
|
```
|
|
71
71
|
|
|
72
|
-
|
|
72
|
+
`Goblin`に`BattleNpcUnit`を継承させた場合は、上記の`Fight`メソッドの引数に渡すことができます。
|
|
73
|
-
|
|
73
|
+
`Goblin`クラスで`AutoFight`メソッドをオーバーライドした場合は、`Gobrin`独自の戦闘が行えます。（パーティー戦ならあるプレイヤーだけ一人狙いするとかがあるかもしれません）
|
|
74
74
|
|
|
75
|
-
そうするとFightメソッドで**enemyの具体的な型を知らないで実装を作ることができる**ので作りやすくなります。
|
|
75
|
+
そうすると`Fight`メソッドで**enemyの具体的な型を知らないで実装を作ることができる**ので作りやすくなります。
|
|
76
76
|
このように抽象クラスやインタフェースに対してプログラミングすることを「ポリモーフィズム」と言います。
|
|
77
77
|
|
|
78
78
|
もっとオブジェクト指向チックに設計したいのであれば、継承することだけにこだわらず抽象に対してプログラミングするという考え方があると良いと思います。
|
|
@@ -95,7 +95,7 @@
|
|
|
95
95
|
|
|
96
96
|
データを保持する方法は人によって様々ですが、HPや攻撃力のステータスはシステムで静的に持つのではなく各々のオブジェクトに保持しておくのが良いと思います。
|
|
97
97
|
|
|
98
|
-
システムを管理させるデータというのはステータスなどの具体的な値ではなく、Unitオブジェクトではないでしょうか。
|
|
98
|
+
システムを管理させるデータというのはステータスなどの具体的な値ではなく、`Unit`オブジェクトではないでしょうか。
|
|
99
99
|
|
|
100
100
|
2はよくわかりません。関数チックに定義しろということでしょうか。
|
|
101
101
|
|
3
誤字
answer
CHANGED
|
File without changes
|
2
誤字
answer
CHANGED
|
@@ -23,7 +23,7 @@
|
|
|
23
23
|
|
|
24
24
|
上の関係で違和感がないのはCAN-DOの方なので、NPCの「行動パターンを持つ」という概念はクラスではなくインタフェースで表現したほうが適切な気がします。
|
|
25
25
|
|
|
26
|
-
ただ、あくまで「個人的に」なので「ゴブリンは絶対NPC」という思想の元でクラス設計をされているのであれば、
|
|
26
|
+
ただ、あくまで「個人的に」なので「ゴブリンは絶対NPC」という思想の元でクラス設計をされているのであれば、次に紹介する「気になった点を解決する」欄はスルーしても構いません。
|
|
27
27
|
|
|
28
28
|
### 気になった点を解決する
|
|
29
29
|
|
1
抽象クラスであるべきクラスが一つ抜けていたので追加
answer
CHANGED
|
@@ -12,7 +12,7 @@
|
|
|
12
12
|
|
|
13
13
|
クラス設計には日々悩んでるまだまだオブジェクト指向のアマチュアですが、2点。
|
|
14
14
|
|
|
15
|
-
1点目、UnitとNpcUnitは抽象クラスであったほうが良いと思います。
|
|
15
|
+
1点目、UnitとNpcUnitとBattleNpcUnitは抽象クラスであったほうが良いと思います。
|
|
16
16
|
|
|
17
17
|
2点目、Npcクラスは、独自の行動で戦闘ができるNPCとして振舞えるということなので、次のようにCAN-DO関係で表現できます。
|
|
18
18
|
- Goblin can be NPC
|