アプリ開発日記　#159 テーブル周りの実装の続きとオブジェクト指向

新しく作るアプリ

いつも期限前日に焦ってしまう人のためのスケジュール管理アプリを作ろうと考えています。

今日の作業

引き続きテーブル周りの実装を行いました。

とりあえず今日は2テーブル分のインメモリでのデータの永続化と、SQLiteでのデータの永続化の処理を追加しました。
この辺りは、やることは大体同じなのですので、後はどのようなデータが必要なのかを考えながら実装していけば、すんなり作業が進む気がしています。

ただ、テーブル数がそれなりに多いので、全部作るのはまあまあ時間がかかりそうです。

また今日は、下記の本を読んでいました。

現場で役立つシステム設計の原則〜変更を楽で安全にするオブジェクト指向の実践技法

作者:増田亨
発売日: 2017/07/05
メディア: Kindle版

そして本の中で、オブジェクト指向で作るならデータクラスを実装するのはよくないという記載を見ました。
さらに残念なことに、自分が作っているアプリでは2か所でデータクラスを実装していました。

1つは画面とモデルのデータの受け渡しです。
こちらは、画面側でモデルに実装したメソッドが実行できるのが嫌だったため、実装していました。

そしてもう1つがテーブルクラスです。
テーブルクラスはXamarinでSQLiteを使う場合に必要なクラスです。

このテーブルクラスがデータクラスの形式となっていました。
そして、InsertやUpdateを行うためのデータをデータクラスの外で設定するようにしていました。

そのため、今回はこのテーブルクラスを少し見直すことにしました。
まあ、やったことは単純で、ドメインモデルのオブジェクトをコンストラクタに渡すことで、コンストラクタ内でテーブルクラスの各プロパティーに値を設定できるようにしました。

結果として、InsertやUpdateを行うための処理がとてもすっきりしました。

画面とモデルのデータ受け渡しのほうもデータクラスから画面とモデルのデータの変換を役割とするクラスへ直したいなあ。。。
まあ、画面を作るときでいいかな。

明日以降の作業

テーブル周りの実装を続ける
UnitTestを組む

今後の課題

<<大量の設計書がなくても、過不足なく使用を説明できるようにしたい>>

アプリが複雑になると設計書の量が増えてしまいます。
しかし、すべての設計書の整合性を取りながら、アプリを修正することは結構大変だと思います。

今回も、複数の設計書の間で不整合が起きていたことで、バグを作りこむところでした。

そのため、仕様を説明するためのドキュメントについて、もっといい感じでまとめられるようにしたいです。<>
アプリケーションサービスや、ドメインモデル、ドメインサービスのそれぞれの役割を明確に定義できていなかった、そして十分に理解できていなかったため、実装時に実装するレイヤーが違うものがいくつか表れてしまいました。

そのため、改めてアプリケーションサービスや、ドメインモデル、ドメインサービスのそれぞれの役割を明確に定義できるようにしたいと思います。