Is it good to have a use case depending on another use case where the other use case is just forward...

# android-architecture

[Vikas Singh]

Is it good to have a use case depending on another use case where the other use case is just forwarding the calls to the repository ?

[Marko Novakovic]

if it’s the pattern to have usecases that are just delegating calls to repository and you already have usecase that does what you need than it’s ok to depend on it

[Marko Novakovic]

it’s ok for a usecase to depend on another usecase

[K Merle]

I agree with @Marko Novakovic. It's just a high lvl code and doesn't break unidirectinal flow

[Vikas Singh]

What if in future I add a business logic to the usecase which is now just forwarding the calls to repo..

[K Merle]

It depends what kind of logic and in what situation.

[Marko Novakovic]

just don’t duplicate code. if you end up adding code to some usecase that you depend on and it’s not suitable any more for some other usecase, create new usecase or call repository directly

[Marko Novakovic]

don’t overcomplicate 🙂

[Vikas Singh]

I was thinking of not having a usecase just to forward the calls to repo instead directly call the repository
The current usecase
class UseCaseA(val usecaseB: UseCaseB) {
fun execute() {
useCaseB.saveData()
}
}

In the above example usecaseB is just forwarding the calls to repo instead i would prefer to directly inject the repository

[zhuinden]

as always, i'd just remove the repositories and move all that code into usecases that don't depend on each other

[Marko Novakovic]

interesting, why not? if, for example, you already have some non trivial behaviour covered with a usecase, why not use that usecase if you need that exact behaviour?

[ajay meher]

A UseCase can be a meta UseCase and have part of it’s responsibility/task be executed/delivered by other UseCases and work on the result to achieve the final responsibility. But, if it is only about a UseCase delivering some other UseCase result directly then my suggestion would be to use the original UseCase directly. Every UseCase should follow SRP and should have only one reason for change. In your case, you are still going to violate DRY if you copy the same responsibility from existing UseCase.

[Pablichjenkov]

I would make the use case being a custom kotlin flow operator and concatenate them if one depends on the other output.
That way you gain a free coroutine scope already in the flow {} builder

[Thanos Psaridis]

We do that all the time in my company. Our project is heavily modularized and focused on clean architecture.