1つの画面に複数のユースケースが対応してもいいのでは?

アプリ開発での失敗

個人開発でアプリを作成する際にユースケースが画面単位となるように設計していました。
しかし、画面単位でユースケースを考えていたら、ユースケースクラスへ渡す値が多くなってしまいました。

そして、ユースケースクラスへ渡す値が多くなってしまったために、ユースケースクラスのメソッドへ渡す値を増やす必要が出てきました。
しかし、メソッドの引数が多いとソースコードがわかりにくくなるように感じました。

そのため、ユースケースクラスへ渡す値のためのクラスを作成し、クラスを渡すことで対応することにしました。
しかし、値を渡すためのクラスを作成することは、少し冗長なクラス構成に感じました。

ユースケースを分割する

今回の個人開発では、ユースケース画面の項目を登録するとしていました。
しかし、画面項目を登録するとしていた場合、画面項目が多くなってくるとユースケースで扱う値が増えてしまい、1つのユースケースが複雑になってしまいます。

そのため、ユースケースをもう少し小さな単位で分割することで1つのユースケースが扱う値を減らし、1つのユースケースをシンプルにしたほうがいいと感じました。

ユースケースとインターフェース

ユースケースを細かく分類することで、ユースケースを定義するクラスへ渡す値を少なくすることができます。
そのため、ユースケースを細かく定義することで、1つ1つのクラスがより簡単な構造にできるように思われます。

例えば、社員を登録する機能の場合、ユースケース社員を登録するとした場合に、社員に関するすべての情報を社員を登録するのユースケースで処理することになります。このばあい、社員に関する情報が多い場合ユースケースへ渡す値が多くなり、ユースケースクラスが煩雑になる可能性があります。

しかし、社員を登録するユースケース社員の個人情報を登録する社員の所属を登録するなどに分けておくことでそれぞれのユースケースで扱う値が減るため、ユースケースクラスで扱う値が少なくなり、シンプルなクラスになります。

結果として、メソッドに渡す引数の数も減らせ、わざわざユースケースクラスへ渡すためだけのデータクラスを作成する必要もなくなる可能性があります。

設計の本

システム設計のセオリー --ユーザー要求を正しく実装へつなぐ

システム設計のセオリー --ユーザー要求を正しく実装へつなぐ

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

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