Primarily One constructor and one execution functionand an execution function.
A class that does not perform any side effects on the data it receives.
It could be made as a static function, but we've categorized it as a generic class because it works well with DI.
When to use UseCase?
Handling communication
Common processing used across multiple screens
If you write it in Lifecycle, it will be bloated and hard to read
In particular, communication processing is often called from multiple screens, and the processing content is likely to be bloated, so we categorize it as a UseCase.
UseCase should be used in these cases.
For example, the character information acquisition communication is called in multiple screens, such as during in-game transitions, the formation screen, and the enhancement screen. Since the same processing occurs in multiple places, UseCases allow you to bundle them together and manage them as a single class.
Can't I just UseCase everything instead of Lifecycle?
You can UseCase all processing besides communication, but you'll end up with a lot of one-off UseCases that are only used once. This can lead to poor readability and less efficient development.
If we see it being used more than 2-3 times in other common processing, we try to clean it up by UseCasing it each time.
Example code
Below is a sample UseCase for communication. It is written not only to communicate and receive results, but also to include UI display during communication, error handling, etc. Users (such as Lifecycle) can handle communication, including error handling, by simply calling DoConnect.