Refactor: Replace operator invoke with execute in use case classes#2
Refactor: Replace operator invoke with execute in use case classes#2Dev-Pasaka wants to merge 2 commits intoantonarhipov:mainfrom
invoke with execute in use case classes#2Conversation
…rmation in test cases
- Replaced all declarations with - Updated service classes to call instead of - Aligns with review recommendation to avoid unnecessary operator overloading - Improves readability and avoids promoting patterns without clear necessity
|
Thanks again for the feedback! In addition to the recent refactor replacing operator fun invoke with explicit execute(...) methods in the use cases, I'm planning to introduce independent unit tests for each use case. This approach will help ensure that each use case behaves as expected in isolation, facilitating early detection of issues and making future refactoring safer and more manageable. Looking forward to your thoughts on this direction! |
| operator fun invoke(customerId: CustomerId, noteId: Long?, remindAt: LocalDateTime, message: String):Reminder{ | ||
| fun execute(customerId: CustomerId, noteId: Long?, remindAt: LocalDateTime, message: String): Reminder { | ||
| val reminder = Reminder( | ||
| id = ReminderId(value = (1000_000_000..1_899_999_999_999).random()), |
There was a problem hiding this comment.
Sorry for being picky. I think the ID should be generated by the Repository implementation. In real life it would be the sequence in the database, of course, or there should be a generator that keeps track of the values. The random number, even though the probability here is negligible
2 participants
This PR refactors all use case classes to replace
operator fun invoke(...)with a standardexecute(...)function..execute(...)for clarity.invoke()can simplify code when use cases are injected, in this structure explicit methods are clearer and more beginner-friendly.Thanks for the earlier feedback — this should align better with clean DDD examples.