Hi Guys, I need to take decision, and I need exper...

# android-architecture

[Iqbal Ahmed]

Hi Guys, I need to take decision, and I need expert advice, I have read few answers on google, but still I am not satisfied,

Can we inject one usecase in another usecase to avoid DRY ?
for eg: I have a scenario where I have to login, getToken and getProfile, in same screen. I have to perform all this operation,

My understanding is, usecase should not depend on any other usecase and all these operation should be done in presentation layer in my case ViewModel (Android).

But counter question, If I have to change one usecase with another usecase and it’s using in multiple ViewModel so do I have to change in all the places.

Appreciated any suggestions !!

[Javier]

IMO anything related to the token is an implementation detail and not an use case as it is related to the network layer but not the business layer.

[curioustechizen]

My understanding is, usecase should not depend on any other usecase

Do you remember where you came across this advice and what was the reasoning behind it?

Almost every architecture I worked with had the opposite advice: The whole purpose of a UseCase is to depend on as many other UseCases or depend on as many repositories as needed to achieve a single goal.

and all these operation should be done in presentation layer in my case ViewModel (Android).

Again, this in my opinion is misleading. Your ViewModel should only concern itself with presentation logic. Coordinating between multiple "backends" (I use this term loosely here) to get the data needed to display this screen is not presentation logic. It belongs in UseCases (or further down depending on what the logic is as Javier mentioned above)

[Iqbal Ahmed]

@curioustechizen I read in clean architecture each use case should perform only one operation, one use case should not know what other usecase is doing, so we set the boundaries,

[Iqbal Ahmed]

and Is it a good practice to use one usecase in another usecase ?

[Iqbal Ahmed]

@Javier that can be done, but it’s just an example, to explain the scenario, main question is can we use one usecase in other usecase?

[Javier]

I think so, an use case can help to get another use case working as the business logic is not isolated and can be related, not only in code, in real life.

[curioustechizen]

and Is it a good practice to use one usecase in another usecase ?

Good practices are subjective; but in all the apps that I worked on in the past 4 years, we've made extensive use of the pattern where a UseCase depends on other UseCases.

[Iqbal Ahmed]

as of now, I have handled these kind of operations in RemoteDataSource, but we loose usecase validation, but now to avoid these, we considering to do this either in viewmodel or in usecase itself, but if we include mulitple usecase in another usecase, then it’s break SRP, because each usecase can be handled differently in different places. as per software design

[Iqbal Ahmed]

and combining 3-4 usecases inside one usecase doesn’t feel right

[Javier]

can you share more concrete examples?

[Iqbal Ahmed]

For eg:

I have screen where I have to call multiple api’s, returning same model, consider showing the result at a time, not in async manner

so should I create one usecase and include all the usecase insde one, calling composite usecase.

or should I include all the usecase in viewmodel, and combine all the results inside one method. (currently we are doing this)

[Javier]

Can you rewrite your question but thinking about business logic instead of API calls?

[Javier]

a use case can do N calls in order to get the necessary info, for example if you want to get a user profile and you need to do 7 requests because your backend is created so, you are not going to create 7 use cases as your business logic is getProfile.

[curioustechizen]

but if we include mulitple usecase in another usecase, then it’s break SRP

Could you explain this? I don't agree with this.

so should I create one usecase and include all the usecase insde one, calling composite usecase.

This is exactly what I'm referring to. Your smaller UseCases are units of composition. You can compose them into a larger UseCase (like a screen-level UseCase in your example).

The smaller UseCases still perform a single action; they can still be unit tested in isolation and they can still encapsulate some bit of logic (that might change in the future; so all UseCases that depended on it get the change for free).

[Javier]

but if you are using those 7 requests as standalone and necessary use cases for other parts of the application, you could use them in your getProfile use case

[Iqbal Ahmed]

ya it can be use in other part of application, but after reading all suggestions, I think it’s okay to have composite usecase to fullfill the requirement for particular screen. and still I have access of other usecases to use in other places.