TDDで電卓アプリを実装する日記#2

はじめに

ちょっとTimberbornにハマり過ぎて1日分の遅れが出ています。コツコツと時間のマイナスは返済していかないと。

現状のToDoリストは下のリンクの通り。次は数値の9桁の制限を設けるところから。

swing_calc_for_education/calc_todo.md at 473b2ddde9a5b89a6bd67cd49d195a194569c05e · mickie895/swing_calc_for_education

テストの作成

まずはテストを作成…したのだが、テストを作成していたときのコミットを作り忘れていたことが発覚。

記憶を頼りに復元したのがこちら。(15の数値になるテストから継続)

		assertEquals(formula.GetResult(), 15);
		// 更に0を10回押したら150000000になる(9桁制限)
		for (int i = 0; i < 10; i++) {
			
			formula = formula.AddKey(Key.GetFromString("0"));
		}
		
		assertEquals(formula.GetResult(), 15 * (100000000)));

まずは桁数制限をどうにかしてコードに落とし込もう。

実装

桁数制限を行うようにしたとき、次の2点の処理が追加される。

桁数を追加できるかの判断
追加できない場合の通知

通知には例外、戻り値、イベントの3つがぱっと思いつく(イベントは実装時は思いつかなかった)。

例外のメリット
・ その場で処理を止められる(戻り値に影響はない)
・ Javaの標準的な機能であり、ライブラリに左右されない
例外のデメリット
・ 結構負荷が増える
・ 今まで追加した箇所(テスト等)にも影響がある

戻り値のメリット
・ 負荷が少ない
・ ライブラリに左右されない
戻り値のデメリット
・ 引数を変更する必要がある
・ 追加の情報を返したいときは、戻り値のオブジェクトが必要になる

イベントのメリット
・ 通知先を自由に選べる
・ 今までの処理への影響がない
イベントのデメリット
・ 処理の流れが複雑になりそう
・ イベントを外部に公開することはAPIを増やすことと同じ

今回は例外を選択することにした。

テストを修正し、9桁制限が発生する前に例外が発生したらテストは失敗としておき、さらに桁数のミスをしていたことに気がついたのでテストも調整した。

また、Keyオブジェクトに桁数の概念を追加し、適宜更新するようにした。(副次的な効果で、「000」のようなキーを追加できるようになった。)

特定の桁数までの整数を入力できるようにした · mickie895/swing_calc_for_education@f23bbdc

他にも例外オブジェクトの処理も追加し、テストも通ることを確認してコミットした。

終了時のToDoリストはこんな感じ。次回四則演算実装完了…までは遠そうだなぁ。多分ToDoリストが足りていない。