回答編集履歴
3
主題を追加
test
CHANGED
|
@@ -1,6 +1,8 @@
|
|
|
1
|
-
拝読させていただいたところ、真っ先に浮かんだのは
|
|
1
|
+
拝読させていただいたところ、真っ先に浮かんだのはCheckAble関数の修正です。
|
|
2
2
|
|
|
3
3
|
|
|
4
|
+
|
|
5
|
+
まずは、条件分岐について。
|
|
4
6
|
|
|
5
7
|
「参照先は壁か」「参照先は空か」「参照先には自分の石があるか」という条件は、このアルゴリズムにおいて頻出し、かつ重要なものです。
|
|
6
8
|
|
|
@@ -36,10 +38,8 @@
|
|
|
36
38
|
|
|
37
39
|
今回のように、一つのメソッドに複数の作業を混在させ、かつ同一のデータ（ここではfield[n][m]）を各作業で利用すると、分岐条件や石をひっくり返すロジックに修正が生じた場合、互いに影響を与えてしまう恐れがあります。すると、修正範囲が広がったり、バグの原因が特定しにくくなったりします。
|
|
38
40
|
|
|
39
|
-
（結構面倒そうなので）ここでは省略させて頂きますが、実際にはcheckAbleを二つの関数に分け、
|
|
41
|
+
（結構面倒そうなので）ここでは省略させて頂きますが、実際にはcheckAbleを二つの関数に分けてみると、各処理毎に影響範囲を限定できます。挑戦してみてください。
|
|
40
42
|
|
|
41
43
|
例)
|
|
42
44
|
|
|
43
45
|
checkAble → isReversibleとreverseに分割
|
|
44
|
-
|
|
45
|
-
isReversibleを満たす時にreverseを読みだすstartOthero関数を導入
|
2
脱字修正
test
CHANGED
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
|
|
5
5
|
「参照先は壁か」「参照先は空か」「参照先には自分の石があるか」という条件は、このアルゴリズムにおいて頻出し、かつ重要なものです。
|
|
6
6
|
|
|
7
|
-
なので、これらを全て関数にて共通化し、かつ名前を付けて分かりやすくしてみましょう。
|
|
7
|
+
なので、これらを全て関数にして共通化し、かつ名前を付けて分かりやすくしてみましょう。
|
|
8
8
|
|
|
9
9
|
「参照先は壁か」→isWall
|
|
10
10
|
|
1
表現を修正
test
CHANGED
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
|
|
5
5
|
「参照先は壁か」「参照先は空か」「参照先には自分の石があるか」という条件は、このアルゴリズムにおいて頻出し、かつ重要なものです。
|
|
6
6
|
|
|
7
|
-
なので、これらを全て関数に
|
|
7
|
+
なので、これらを全て関数にて共通化し、かつ名前を付けて分かりやすくしてみましょう。
|
|
8
8
|
|
|
9
9
|
「参照先は壁か」→isWall
|
|
10
10
|
|