回答編集履歴
2
追記
answer
CHANGED
|
@@ -9,4 +9,10 @@
|
|
|
9
9
|
そうではなくて、Type-1, Type-2, Type-3がたまたまその３つの状況の場合であり、今後増えていく可能性があるのであれば、getTypeName()のような感じにするだろうと思います。
|
|
10
10
|
文字列は比較する時にタイプミスしてもエラー・チェックが働かないので、enum型を返却したくなることが少なくないです。なので、その時困らないようにNameやStringを付けることも多いです。
|
|
11
11
|
|
|
12
|
-
checkType()がboolean返却というイメージには同意です。
|
|
12
|
+
checkType()がboolean返却というイメージには同意です。
|
|
13
|
+
|
|
14
|
+
---
|
|
15
|
+
【質問の編集を踏まえて】
|
|
16
|
+
私なら、getType()ですね。
|
|
17
|
+
そして、その戻り値をプログラムで判定して分岐するでしょうから、enum型を返却すると思います。
|
|
18
|
+
enum型なら分類の拡張にも対応できますし、その分岐時に例えば"Type-1"を"Tyep-1"などとタイプミスしてもコンパイラが検出してくれますし。
|
1
typo
answer
CHANGED
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
実装を外部から隠すことは、好ましい場合が多いですので。
|
|
5
5
|
とは言え、max()やmin()とか、equal()的なものはそういう訳にもいかないので、ケースバイケースですが。
|
|
6
6
|
|
|
7
|
-
今回の場合、もし、a<b, b>a, a==bの３つのパターンに分類することが目的の関数なら、私なら
|
|
7
|
+
今回の場合、もし、a<b, b>a, a==bの３つのパターンに分類することが目的の関数なら、私ならcompare()を選びそうです。戻り値は-1, 1, 0とか、enum型で3つを判別等ですね。
|
|
8
8
|
|
|
9
9
|
そうではなくて、Type-1, Type-2, Type-3がたまたまその３つの状況の場合であり、今後増えていく可能性があるのであれば、getTypeName()のような感じにするだろうと思います。
|
|
10
10
|
文字列は比較する時にタイプミスしてもエラー・チェックが働かないので、enum型を返却したくなることが少なくないです。なので、その時困らないようにNameやStringを付けることも多いです。
|