新しく作るアプリ
いつも期限前日に焦ってしまう人のためのスケジュール管理アプリを作ろうと考えています。
今日の作業
モデルの再実装が一段落したため、またUnitTestの組み込みと実施を開始しました。
UnitTestは、設計を見直す前にも組んでいたのですが、プログラムの構成を大きく変えてしまったため、ほぼ初めから実装することとなりました。
ただ、もともと作成していた箇所について、一部使用できる箇所があったため、その部分は再利用しました。
そのため、もともとUnitTestを作成していた箇所については、最初の時より短い時間でUnitTestの実装と、テストの実施ができました。
そして、テストを行っている中で、値オブジェクトにstaticなメソッドでデフォルト値を返せるようにしておくとよかったと感じる箇所がありました。
たとえば、値オブジェクトがnullの場合に画面にデフォルト値を表示させたい時などです。
今回は実装する予定はないですが、今度アプリを作るときに値オブジェクトにデフォルト値を実装してみたいなと思いました。<<イメージ>>
public class Average
{
int bunshi = 0;
int bunbo = 0;
public Average(int bunshi, int bunbo)
{
// 省略
}
public double GetAverage()
{
return (bunbo == 0) ? 0 : (bunshi / bunbo)
}
public static double DefaultValue()
{
return 0;
}
}
public class Test
{
TextView txetView;
public void TestMethod(Average avg)
{
// Averageがnullの場合は、Average 値オブジェクトのデフォルト値を表示する
txetView.Text = avg.GetAverage() ?? Average .DefaultValue();
}
}
明日以降の作業
UnitTestを組む
今後の課題
<<大量の設計書がなくても、過不足なく使用を説明できるようにしたい>>
アプリが複雑になると設計書の量が増えてしまいます。
しかし、すべての設計書の整合性を取りながら、アプリを修正することは結構大変だと思います。
今回も、複数の設計書の間で不整合が起きていたことで、バグを作りこむところでした。
そのため、仕様を説明するためのドキュメントについて、もっといい感じでまとめられるようにしたいです。<
アプリケーションサービスや、ドメインモデル、ドメインサービスのそれぞれの役割を明確に定義できていなかった、そして十分に理解できていなかったため、実装時に実装するレイヤーが違うものがいくつか表れてしまいました。
そのため、改めてアプリケーションサービスや、ドメインモデル、ドメインサービスのそれぞれの役割を明確に定義できるようにしたいと思います。